I tried to narrow down the problem as much as possible. Here’s the code I’m using:
Code dependencies are minimal – only datatypes.hcrc.h from Vedders UART library.
The send_packet function I copied and slightly modified from ESP8266VESC lib.
Then I merely count the received bytes and indicate the status using the Arduino’s builtin LED. If at least one byte is received, there should be one long blink. Otherwise, there are three short blinks.
The RX/TX LEDs on the Arduino do not blink at all, so I suppose this is a HW problem rather? I have read through the discussion here, but it didn’t help me.
As I understood, the TX/RX on the ESCape is 3.3V and thus it may be necessary to use a voltage divider for the RX. On the other hand, @stewii said that “most IO pins on the STM are 5V tolerant” so the voltage divider is not necessary.
Here’s a quick vid showing how things are wired up and how LEDs blink (or not):
Update: It apparently takes writing a long post for one to figure out the problem himself. I’m not updating the count variable in my received_bytes_count function.
After fixing that bug, I’m getting long LED blinks now. Looks like I’m getting somewhere.
Hi @Pimousse, thanks for chiming in. I believe I have the latest FW on my ESCape. I updated it this week.
As I already mentioned in the update, I have probably figured out the problem. I had a bug in my code so it was reporting the communication status incorrectly.
It’s a bit strange since I’ve been struggling to get the UART communication working for a few hours, using both the ESP8266VESC and VescUartControl libraries with no luck. So I’ve been stripping my code sample off as many dependencies as possible to make sure there’s no bug in those libraries. It finally seems to be working now. I still don’t know what I have been doing wrong all the time.
Make sure of the FW version.
Since 3.40, packet length of COMM_GET_VALUES exceeds Arduino buffer size.
There is a workaround which consists into increasing Arduino bufer size, but it s a bit tricky.
@solidgeek wrote a custom library to get rid of this limitation.
Good to know. Thanks. Looking at it now. Vedder has added controller ID to the message. And yes, I do have FW 3.40. That explains why I had no luck getting the VESC data using the ESP8266VESC and VescUartControl libs. I should be able to figure it out now. This is super helpful. Thanks a lot.
@Pimousse Just FYI, I ended up creating my own minimalistic lib for reading data from VESC. It doesn’t require messing up with the Arduino buffer size and it still works with the VESC FW v3.40. I simply ignore the last received byte, which is the termination byte. https://github.com/janpom/davega/blob/master/vesc_comm.cpp
Thank you !
However, I think it can’t work although you don’t CRC check the payload.
Moreover, this is not sustainable if in a near future, more datas are added.
@solidgeek 's library seems to work with 3.40.
I didn’t tested it yet, I’m adding more stuff to it like FW checking.
What do you mean? I do CRC check the payload. We’ll see regarding sustainability. Maybe Vedder does something about it following your issue.
I had a quick look at @solidgeek’s library. It seems to be doing the same trick = it just doesn’t check the termination byte. So I believe it has the same sustainability problem as my lib.
My version is more memory efficient since it parses data from the received packet on demand and thus it doesn’t need a struct to copy all the parsed data into. It also has less features though. Only reading from VESC. There’s no writing into VESC.
