2019-02-05 01:43 PM
Hi
I am using the stm32L433 device and want to use the USB port for communication. I am planning to use it as a CDC class, and to start of with using the cube (then modify it to use registers only). I have read some place that it requires a large buffer when using it, is this correct? I am assuming there will be some overhead for the driver, and then for my application. But I am not sure what this should be set to. Anyone any idea?
Many Thanks
Scott
2019-02-05 03:40 PM
Not sure where some place is.
The default for the stack/heap in the Keil/IAR builds is perhaps too small for proper USB operation and the bloat of the libraries. During connection there may also be a malloc()/free() buried in the libraries.
In fact most most of the HAL examples the stack is unhelpfully small, things like printf()/scanf() have expectations, and a lot of PC code is heavy on auto/local variables. Just be aware of what demands your call trees create and allocate a bigger stack. With GNU/GCC the stack/heap is far cruder, basically the stack is placed at the top of memory, moving down, and the heap at the end of the statics moving up. In that case things have a much more significant margin before going pear shaped.
2019-02-05 08:34 PM
I use two 64 byte buffers (read & write) and it meets my needs. I'm not transferring much data over it. But the HAL API, once you understand it, is reasonably well behaved.
2019-02-08 02:30 AM
Thanks for your reply.
I assume the 64 bytes is the communication side to the connected application? What sort of size did you need to increase the stack too?
Thanks
Scott
2019-02-08 02:34 AM
Thanks for you reply.
Sorry, the place I mean is posts on YouTube.
As I am writing the code on the PC side, and know how much data is going back and forward, I assume this is the only buffer (apart from the stack increase) that is required? I assume (I havent started using the USB yet) I will get an interupt on every character recieved (using CDC interface)? This way I can make sure there are no buffer overruns?
Thanks
Scott