does sertxd work for word variables?
- Thread starter tennis
- Start date
Andrew Cowan
Senior Member
Yes, it does.
A
Code:
sertxd (#w1)westaust55
Moderator
Well spotted Andrew.
At least the PE syntax check is passed, so looks like another one for Rev Ed to update in the manual.
PICAXE Manual 2 Rev 6.7 page 160 states:
the commands GET, PEEK and POKE for example also needs the keyword "WORD".
But then it is also not consistent with other commands where the keyword "WORD" must be included. For example (at page 191):
At least the PE syntax check is passed, so looks like another one for Rev Ed to update in the manual.
PICAXE Manual 2 Rev 6.7 page 160 states:
The wording (0-255) suggests byte variables only.
the commands GET, PEEK and POKE for example also needs the keyword "WORD".
But then it is also not consistent with other commands where the keyword "WORD" must be included. For example (at page 191):
and at page 27 it is slightly different again but clear that a word variable is allowable:
Last edited:
The manual is correct, you can only output byte data over RS232.
However #w1 is a different scenario, because the # conversion means you are not outputing a value such as 1000 directly, you are asking the PICAXE to output the 4 ASCII byte values "1" "0" "0" "0"
However #w1 is a different scenario, because the # conversion means you are not outputing a value such as 1000 directly, you are asking the PICAXE to output the 4 ASCII byte values "1" "0" "0" "0"
westaust55
Moderator
Thanks for that clarification Technical.
So, for tennis, the answer is if he/she is trying to find better ways to reduce the size of the datafile, then using #w0 will double the data from 2 bytes to 4 bytes.
So, for example, would be better to send variable b0 followed by variable b1 as the LSB and MSB of w0 (thus only 2 bytes required) and "recombine" as a word variable at the receiving end.
So, for tennis, the answer is if he/she is trying to find better ways to reduce the size of the datafile, then using #w0 will double the data from 2 bytes to 4 bytes.
So, for example, would be better to send variable b0 followed by variable b1 as the LSB and MSB of w0 (thus only 2 bytes required) and "recombine" as a word variable at the receiving end.
hippy
Ex-Staff (retired)
It's not clear what application tennis has in mind and it's really a two part problem - getting data to the PC then storing the data in the most appropriate format if it is being stored.
A 16-bit value can be sent to the PC using # and a word variable or it can be sent as two separate 8-bit bytes. Which is better depends on how much data is to be transfered plus the ability of whatever is receiving the data on the PC to deal with raw 8-bit bytes.
Once the data is received and turned into a form which can be internally represented by the receiving application ( which has to be done in either case ) how the data is subsequently manipulated and used is up to that application and again depends on what abilities it has in that respect.
How the receiving application manipulates data received may also decide what best format to send data in. If it's dealing with strings it may be easier and less coding to grab the input as string data rather then have to combine two bytes and convert to string, whereas for numeric processing, re-combination to 16-bit unsigned or 32-bit signed may prove to be better. Programming language used may also be a deciding factor, string to number conversion is easier in some than byte re-combination.
A 16-bit value can be sent to the PC using # and a word variable or it can be sent as two separate 8-bit bytes. Which is better depends on how much data is to be transfered plus the ability of whatever is receiving the data on the PC to deal with raw 8-bit bytes.
Once the data is received and turned into a form which can be internally represented by the receiving application ( which has to be done in either case ) how the data is subsequently manipulated and used is up to that application and again depends on what abilities it has in that respect.
How the receiving application manipulates data received may also decide what best format to send data in. If it's dealing with strings it may be easier and less coding to grab the input as string data rather then have to combine two bytes and convert to string, whereas for numeric processing, re-combination to 16-bit unsigned or 32-bit signed may prove to be better. Programming language used may also be a deciding factor, string to number conversion is easier in some than byte re-combination.
BeanieBots
Moderator
Absolutely Hippy.
I recently got caught out when sending raw data as apposed to sending it as ASCII as per #Var. Took quite a while before I realised that the receiver would 'lock up' sometimes because it was interpreting 'data' as Xon/Xoff commands.
I recently got caught out when sending raw data as apposed to sending it as ASCII as per #Var. Took quite a while before I realised that the receiver would 'lock up' sometimes because it was interpreting 'data' as Xon/Xoff commands.
hippy
Ex-Staff (retired)
@ BeanieBots : Some languages / systems can have problems with any control and non-printable characters less than $20 or above $7E.
@ tennis : Yes that will work, but a single #w0 would probably be better.
Sometimes the best / quickest way to see what will happen and compare choices you have is to try them. Go through View -> Options -> Editor and put a tick next to "Serial Terminal - Open after download", add a PAUSE 2000 at the start of your program to give time for the Terminal to open, download the code and see the results come back.
Or use the Simulator.
@ tennis : Yes that will work, but a single #w0 would probably be better.
Sometimes the best / quickest way to see what will happen and compare choices you have is to try them. Go through View -> Options -> Editor and put a tick next to "Serial Terminal - Open after download", add a PAUSE 2000 at the start of your program to give time for the Terminal to open, download the code and see the results come back.
Or use the Simulator.