mtiberia
There is an issue when sending ASCII code through the UART ports. For some reason the ASCII code is getting lost in the translation. It is hit or miss, some codes make it through fine and some don't get sent at all. Error saying that the expression is not in quotes. If the code is sent the received transmission shows a question mark. I have included an example with the ASCII code 255, it gets sent but RX is a ? and not the y with two dots above it.
If you can correct this issue with the scripting you would have me sold on the EZ B.
Great platform and fun to use.
Thanks DJ
Start 1: UARTInit(0,1,1000000)
7: $handshake=GetAsByte(255) # ASCII code 255
8: UARTWrite(0,1,$handshake) # not all codes will be TX
10: Print($handshake)
ÿ # symbol that code represents
14: Sleep(1000)
16: $x = UartAvailable(0, 1)
18: print("Bytes in buffer: " + $x)
Bytes in buffer: 1
20: $TX_DATA = UARTRead(0, 1, $x)
22: print("Received: " + $TX_DATA)
Received: ? # RX Issue or TX issue
25: Print ("done")
done
Thanks
I'll take a look at it tomorrow when i'm at the office - in my tests, I was pushing 255 with the uart without any issues - and receiving 255. But, i'll take a look to make sure there isn't something I have overlooked
What do you think about the new Variable Watcher? Now that you can view Hex values?
I have tested this and confirmed mtiberia findings.
Here is my Test Bed.
This is my results
I hope this can help.
Could the issue have to do with 7bit and 8bit as 7bit can count only to 0-127 and 8bit can store 0-255? <- Just thinking....
I think you may be correct. It's only when using the UART through the EZ script because EZ B can communicate with the dynamical servos that need the 8 bits to represent values from 0 to 255.
@DJ Sures what do you think?
this should help you: string change
YESSSSSSS Awseome thanks DJ !
Now you can give Masimo Banzi a run for his money. I'm surprised he hasn't made you offer you can't refuse.
Forget about it.
Thanks
@mtiberia ...
In a couple years it will be the other way around....