UART voltage tolerance

General topics and discussions about the VESC and its development.
dpetrillo
Posts: 25
Joined: 24 Dec 2015, 01:47

UART voltage tolerance

Postby dpetrillo » 16 May 2016, 18:48

Are the UART TX and RX pins 5v tolerant?

I checked the spec sheet of the micro and my conclusion in no but I wanted to ask if anyone else has done it. I want to communicate to the VESC from a 5v Arduino Pro Mini.

Dave

vitormhenrique
Posts: 16
Joined: 30 Dec 2015, 19:02

Re: UART voltage tolerance

Postby vitormhenrique » 16 May 2016, 19:18

I don't know if the pins are 5V tolerant, but you can still use the arduino pro mini (even the 5V version) powering it using 3.3V... It will run at 16MHz but slightly overclocked (out of spec).

I did that for my custom controller, but ended up using a teensy-lc (3.3v and 48MHz) in the end, it is cheaper, if you add the ftdi board and has more serial ports so I can comunicate with other stuff (xbee + vesc on hardware UART).

ViennaTom
Posts: 41
Joined: 21 Apr 2016, 13:06
Location: Austria/Vienna

Re: UART voltage tolerance

Postby ViennaTom » 16 May 2016, 19:43

hi !
as stated in the datasheet almost all IO pins are 5V tolerant (PA4 and PA5 not) when not uses as analog inputs.
maybe use resistors (1 to 10K ?) in series to lower the stress.
for the receiving side a diode in series or a voltage divider might make sense too but the STM32 seems to be a robust powerhorse ;-)
Greets, Tom

dpetrillo
Posts: 25
Joined: 24 Dec 2015, 01:47

Re: UART voltage tolerance

Postby dpetrillo » 17 May 2016, 19:20

I've gone ahead and used the 5V pro mini at 3.3v supply from the VESC and that works, mostly.

I'm having trouble getting smooth operation from the VESC when giving it commands via UART. It acts as though I'm sending it commands to start and stop very quickly. I debugged my arduino code and I'm not sending conflicting messages to start and the release current. I'm sending just a stream of setcurrent messages back to back as fast as I can.

Has anyone else experienced this choppy operation when using UART?

I am on hardware 4.11 and firmware 2.16. The motor is a geared ebike hub motor that is running in FOC with Hall operation. When I restore defaults and run FOC detection, and detect the hall sensors and apply everything the motor runs very smoothly using 'no app' and the keypad or using ADC input. If I change the app to UART it starts the very choppy operation. I can go back to no app and it's smooth again.

The repo used to send the uart commands is: https://github.com/erwincoumans/Arduino ... r/VescUart

ViennaTom
Posts: 41
Joined: 21 Apr 2016, 13:06
Location: Austria/Vienna

Re: UART voltage tolerance

Postby ViennaTom » 17 May 2016, 22:57

@dpetrillo
I'm not quite sure but i think the idea was to send "keep alive" messages to the VESC on a regular basis because otherwise the timeout_thread will unlock and break the motor:

static THD_FUNCTION(timeout_thread, arg) {
(void)arg;

chRegSetThreadName("Timeout");

for(;;) {
if (timeout_msec != 0 && chVTTimeElapsedSinceX(last_update_time) > MS2ST(timeout_msec)) {
mc_interface_unlock();
mc_interface_set_brake_current(timeout_brake_current);
has_timeout = true;
} else {
has_timeout = false;
}

chThdSleepMilliseconds(10);
}
}


So maybe you setup an idle loop feeding the VESC with alive messages and provide commands when necessary. this way the motor will stop if something goes wrong with your arduino or the connection is lost ?!

dpetrillo
Posts: 25
Joined: 24 Dec 2015, 01:47

Re: UART voltage tolerance

Postby dpetrillo » 18 May 2016, 17:42

If the timeout_msec is the same one that is set via the BLDC tool then mine is set at 1000 ms and shouldn't be causing the issue. I did some more testing and thought maybe I'm sending messages too fast, and added various delays to my arduino code to space them out more. I'm not sure how fast they are being sent ultimately. But when I add a few ms of delay to my arduino program the problem gets a little better. If I add a ton of delay, the result is that the choppiness is a lot better but now the throttle response is chunky/delayed and unusable.

Any other ideas?

ViennaTom
Posts: 41
Joined: 21 Apr 2016, 13:06
Location: Austria/Vienna

Re: UART voltage tolerance

Postby ViennaTom » 19 May 2016, 15:33

yes the thread i meant uses that configurable timeout.
how frequently do you send commands and why not only send changes ?

i consider the packet.c communication as being not very sophisticated. frames should be acknowledged or rejected and using ieee floats in m2m interfaces is also not very elegant. for high speed transfer of realtime data and experimental stuff it might be good enough but i suggest to write a more robust bidirectional command interface not to fall off your board ;)

But maybe the "choppiness" is resulting from something very different - i'm just a VESC beginner !

pf26
Posts: 305
Joined: 28 Mar 2016, 14:37
Location: FR Valence

Re: UART voltage tolerance

Postby pf26 » 20 May 2016, 12:20

I think sending command frames every 20..50ms is enough. Commands like COM_SET_DUTY, COM_SET_CURRENT.. will automatically reset the timeout. (no KEEP_ALIVE needed).
Which command are you using ? Are you sure there is no little bug that may sometimes corrupt the value to be sent ? (you may want to try to just keep sending a constant value)

benjamin
Site Admin
Posts: 280
Joined: 15 Dec 2015, 08:38
Location: Sweden
Contact:

Re: UART voltage tolerance

Postby benjamin » 23 May 2016, 08:28

ViennaTom wrote:yes the thread i meant uses that configurable timeout.
how frequently do you send commands and why not only send changes ?

i consider the packet.c communication as being not very sophisticated. frames should be acknowledged or rejected and using ieee floats in m2m interfaces is also not very elegant. for high speed transfer of realtime data and experimental stuff it might be good enough but i suggest to write a more robust bidirectional command interface not to fall off your board ;)

But maybe the "choppiness" is resulting from something very different - i'm just a VESC beginner !


There are no ieee floats sent, they are converted to fixed point and the scaling has to be done manually. There should be no undefined behavior regarding floats or endianess in the communication. The packet data is fully defined and can be decoded from any language on any platform without relying on what the compiler implementation does.

Regarding acks, that can be done on a lower level if desired. For example, when using the nrf24l01+ interface with commands.c, the built in ack of the nrf can be used, which is done in hardware by the chip and thus much faster. Adding acks for frequent commands in commands.c would slow down the nrf communication quite a bit. For now I have been assuming that USB, UART and CAN rarely or never drops packets, but some kind of acknowledgement could be added as optional for some higher level commands. There already are acks for write configuration, since those packets are big and not sent that often since that would wear out the flash.

Regarding the communication link and/or USB freezing, that has only happened to me while I had hardware problems. HW3, which I never published since it wasn't working well, would freeze in weird states frequently while driving a motor under load. The watchdog did not help much either since it seemed like certain blocks of the CPU (such as USB) could get into undefined states while the core was still running. After fixing the electrical issues the software and communication has been rock solid for me. I have been running motors for days on my bench with random commands while logging data at high rate over USB and CAN without any problems at all. The earlier versions of FOC had some issues where most of the float state would en up as NaN under some conditions, but that is fixed in the latest firmwares. So if you have problems with freezing and/or the communication, it is most likely hardware related.

ViennaTom
Posts: 41
Joined: 21 Apr 2016, 13:06
Location: Austria/Vienna

Re: UART voltage tolerance

Postby ViennaTom » 23 May 2016, 10:18

benjamin wrote:... it seemed like certain blocks of the CPU (such as USB) could get into undefined states while the core was still running. After fixing the electrical issues ....


that's how it appears to me too and maybe i will add some more capacitors to my prototype design to improve supply to the MCU.
of course the electrical 'infrastructure' must be fixed before improving protocol designs in my case. i will report on changes after testing with the PX4 flight controller and CAN interfaces.

thank you !

p.s: IEEE ... sorry i did not look at buffer_append_float functions


Return to “General”

Who is online

Users browsing this forum: No registered users and 2 guests