To the people with LL and STM32 cube workflow. - Page 1
Forum section: electronics / general

author: lawrence11
author_rank: Frequent Contributor
timestamp: November 25, 2019, 07:23:46 am
content: I hear you and share your feelings about it being bloated.Can you all describe in detail how you set yourself up, I dropped the ball on eclipse for more than a year.For stuff like USB, you guys use the registers only and all is that correct? Thats intense...I'm at the point where USB is just byte hacking with beagle12 and such.If registers are like PIC than I am more of a register type of guy, LL type of guy.As long as eclipse doesnt give me trash with the debugger I should progress. I had some buggy experience with Atollic.

author: mark03
author_rank: Frequent Contributor
timestamp: November 26, 2019, 03:48:56 am
content: For USB I found a lean-and-mean library that I like, dmitystu's libusb_stm32:https://github.com/dmitrystu/libusb_stm32Doing all that from scratch would be a significant project.But for most other things, I don't think rolling your own is significantly more difficult than using Cube. I know some people who like the LL "drivers" but I've never understood the benefit. They are just an abstraction layer on top of the register interface, in that most of the LL functions read or write a single register. Not only does this not add anything, AFAICT it is actually worse than direct register access, because the register names and bitfield names are extremely well documented, while the LL stuff is essentially undocumented.

author: lawrence11
author_rank: Frequent Contributor
timestamp: November 26, 2019, 04:06:44 am
content: Well I dont have time to get caught up in marketing gimmicks either.I thought it was more than just device abstraction, but class specific, from M3 to M7.Lean mean register calls.

author: Bassman59
author_rank: Super Contributor
timestamp: November 26, 2019, 10:00:05 pm
content: Quote from: lawrence11 on November 25, 2019, 07:23:46 amI have done several USB designs, and in all cases, I've used the vendor's provided USB stack. Writing one from scratch is a significant undertaking.

author: rounin
author_rank: Regular Contributor
timestamp: November 27, 2019, 03:20:42 am
content: I started my own usb stack because of some issues with ST's library and desire for better C++ and FreeRTOS integration. It is still very a WIP, CDC works on linux and Win7 but not Win10. Interrupts don't work for some reason. The core part of the standard isn't that bad, the device drivers are a lot of work and where all the pain has been for me. I still have some deps on ST's HAL, which I'll slowly remove.I used dmitystu's libusb_stm32 that was linked earlier as a reference for some parts of this. That library also had some issues co-existing with C++ code. In retrospect I should have tried harder to fix that, but I wanted to do it....https://github.com/jacobschloss/libusb_dev_cppEdit:As far as dev environment, I use Atollic's toolchain with an out-of-band cmake toolchain and project file setup, and program and debug with openocd/gdb/stlinkv2. If I was using an older part I'd probably use the arm compiler that ships with Ubuntu instead. I've never been happy with anything eclipse based. Getting VS Code to use my CMake toolchain files actually is better for me, but I usually don't bother.

author: lawrence11
author_rank: Frequent Contributor
timestamp: November 27, 2019, 04:46:41 am
content: And where does hacking/stealing hex via beagle 12 play into this workflow?Cant this all be put to the wayside?