Hi,
.... I tried serrdx [sic] with some results but far from what I'm looking for. ..... The PC program is built with LabView.
In what way(s) did SERRXD not do what you were looking for? But I'm not surprised if it didn't work because SERRXD uses a high baud rate (4800 baud), compared with (and proportional to) the PICaxe's default clock rate (4 MHz). It would be helpful if you could post a 'Scope photo or a Logic Analyser trace of a few serial bytes from the Labview interface (to show the inter-character time gap), but that's probably too much to hope for. Therefore I think that we must assume that the inter-character gap(s) might be quite short. It looks as if you might be quite committed to the 14M2, and also the HSERIN command introduces several "complications", so I think it's worth persevering with
SERIN ..... for now.
The problem with the "normal" serial commands (SERIN and SERRXD) is that they "bit bang" the input pin, so the processor is "Busy" (sometimes referred to as "blocking") whilst waiting for a Start pulse, then during the Start Pulse and throughout the eight Data bits. Therefore the only time that it is available for the PICaxe to "process" the received data is during the Stop Pulse(s) and during any inter-character gap (if it exists). Thus the first thing to try is to use
SERIN ... with the
Lowest baud rate compatible with the appropriate SETFREQ , i.e. 600 baud at the default M4 (4 MHz) through to 4800 baud at SETFREQ M32 (personally I'd try 2400 baud at M16). A quick look at the Labview Serial Interface setup instructions suggests that you can set the baud rate as desired, also set a double-width Stop Pulse ("2 stop bits") and perhaps add a Parity bit, which the PICaxe should just ignore.
Initially, I thought it might be best to Keep It Simples by staying with the EEPROM/DATA memory for now, but there are several problems: The WRITE instruction is one of the slowest executing that I've encountered with a PICaxe, because the EEPROM programming algorithm requires a multiple Write - Verify - Repeat loop. Also, putting the WRITE for each separate byte, within a loop, will cause multiple writes into the same "page", so the memory may wear out much faster than expected. Therefore, I suggest modifying the program to work with data stored in the RAM, for example from byte (pointer) 60 upwards (instead of from zero) and using PEEK instead of the READ keyword. For example, only the following changes may be sufficient:
Code:
init: poke 60 , 11,2,12,1,13,8,6,11,9,12,3,13,2,6,1,9,8,3 ; Test data bytes
for b6 = 60 to 77 step 2
peek b6,b8
; ... ; code as before
peek b7,b8
; ...
next
You will need to plan how to "handshake" the transfer of data from the PC, but the
SERIN instruction has many more useful features than
HSERIN (even in the X2 chips), such as Qualifiers, Timeouts and the automatic parsing of character/bytes into numbers (using the
# prefix). i.e. :
" When the #variable format is used received data will be taken and converted to a number.
All characters received are ignored until the first ASCII digit character is received. A number is then determined until a ASCII non-digit character is received. The value stored in the variable will be number represented by the digit characters received. Note that the #variable will not complete until the number has been terminated by a non-digit character being received."
The PICaxe might be fast enough to put the SERIN within an efficient (For .. Next ..) loop, but SERIN can receive a complete block of data in a single line, provided that the number of variables (not the individual characters) is known and fixed. However, this would probably run out of the "named" variables' space (b0-b27), but this can be solved by using the native byte pointer
BPTR in place of the
b6. Thus the core of the receiving code might be:
Code:
BPTR = 60
SERIN [timeout, address] , pin , baudmode, #@BPTRINC,#@BPTRINC,#@BPTRINC,#@BPTRINC, _
#@BPTRINC,#@BPTRINC,#@BPTRINC,#@BPTRINC,#@BPTRINC,#@BPTRINC,#@BPTRINC, _
#@BPTRINC,#@BPTRINC,#@BPTRINC,#@BPTRINC,#@BPTRINC,#@BPTRINC,#@BPTRINC ; Receive 18 byte variables into RAM
; Note that the line continuation character "_" must not be followed by comment text !
The equivalent code using HSERIN ... (even with an X2) would be much more complex, and used with the M2 chips has two further "issues": An "oversight" in the design of the base PIC silicon means that it cannot receive "Idle Low" signals (i.e. normal RS232) only Idle High, commonly known as "RS232-TTL" (polarity). There is no workaround except to use an external hardware inverter, for example a MAX232 receiver (or a simple NPN transistor and two resistors may be sufficient). There is also a "bug" in the M2 firmware which can prevent even one pair of concatonated characters being received successfully. It's described in
This long Thread particularly posts #1 and #7, but there is any easy workaround ; to use a
PEEKSFR $79 , @bptrinc instead of
HSERIN W1 . It's also necessary to alter the two lines of code which determine whether a character has actually been received or not (since HSERIN does not wait for a character to arrive).
Cheers, Alan.
). 