I’m using a TReX with a Basic Stamp. The biggest problem I am running in to right now is that anytime I send the TReX a packet that gives a response, I lose the first byte of the response before my SERIN command can get ready. As an example, If I request the TReX signature,I receive “ReX1.0” (usually). My SERIN command is immediately following the SEROUT command to request data.
I’ve tried slowing down the baud rate to 9600 (and in the meantime learned that this is only possible in Serial mode with the RC jumper removed). I will slow it down more to see if this helps.
I could go with a faster Stamp, but would like to avoid it. My proposed solution is a firmware change to the TReX that adds a Serial Response Delay parameter, which is the number of ms to wait before sending a response. I cannot use an alternate microcontroller at this time due to other design requirements.
Has anyone had any luck getting bidirectional serial communication between a TReX and a Stamp?
EDIT: Slowing down to 1200 seems to get more reliable returns. I can at least now ask the TReX if Serial is in control, which is good. I still think the firmware change would help, since I could then talk to the TReX at 19200.
Hello, I’m sorry to hear about your problems with the TReX. I will look into making the firmware change you have requested. Please let me know if things improve with even lower baud rates.
Unfortunately the TReX’s current firmware takes up the entire available space, so this simple fix will require much more extensive changes. In the meantime, I was able to fit in a hard-coded 1 ms delay between the reception of the last command packet byte and the transmission of the first TReX response byte. Once I have tested the changes I will post the firmware.
I have posted the new firmware under the resources tab on the TReX page. You can find firmware upgrade instructions in the user’s guide. Please let me know if this improves things for you!
I’m impressed with the response time on v1.1 of the firmware. I’ve programmed the TReX (nice procedure in the GUI). I’m doubly impressed that it did not wipe out my channel calibrations (or any other settings)
Communications at 19200 are now rock solid (I was still sometimes missing a bit or two, even at 1200). The Stamp can now talk perfectly to the TReX. This has my project back on track!
Thanks to everyone who posted that (with good description on the web page, even)
This is why I love my Pololu parts. The support is great.
