2020-11-23 10:09 AM
According to section 28.9.1 (of RM0091), the spi communications are enabled when register 6 is active (SPE set to 1). According to the rm0091 guide, once the spi communications are active, and register 14 is set to 0 (receive only mode) then the clk pin should start up. But when I pause the debugger at that stage, I can see both those pins be in the correct setting, but sometimes the clock is on and sometimes it is not on. So what exactly starts the clk during spi communications?
I dont know if it matters, but I am connected in half duplex master mode to an spi compatible chip (ssc). I am using an stm32f042k6t6 chip on a nucleo board.
2020-11-25 04:38 AM
I keep reading that people avoid cube/hal. Is it that buggy?
2020-11-25 12:52 PM
It of course has its own share of bugs, but generally I don't think it's more buggy than any other software.
I don't use Cube/HAL - nor Cube/LL or SPL, for that matter - because I don't think it brings any benefit to me. I can read the manual and program accordingly. Would I use a "library", I would need to learn that library - and in the case of problem I would need to learn the real stuff anyway, so that's double work.
With Cube/HAL, there's one more thing which deters me. It tries to be relatively "smart". But doing so, it inevitably limits itself to the "most common usage modes", as it's impossible to be "smart" in every conceivable way a user wants to use the mcu and its features - there are simply too many, as you try to combine the already massive amount of features with the many ways how to use them. In other words, while doing "ordinary" things, Cube/HAL may be an immense help; but as soon as you try to do something "out of ordinary", Cube/HAL may start to be less helpful or even straight get into your way.
YMMV
JW
2020-11-26 07:28 AM
I follow this opinion about HAL.
But I often use LL because the most interesting parts are:
This gives a clearer and practically commented code.