my thoughts are that the more experienced stm32duino'ers can do both tracks, official core + libmaplemrburnette wrote: ↑Mon Jan 13, 2020 8:52 pm
I know it is frustrating working new code.
But it takes a long, long time to sanitize a codebase. One of the reasons I tell every serious programmer of the STM32 to drop Roger's code inherited from Leaflabs and move to the STM Official port is that every user counts. Your work effort will be rewarded with better code. There is a business behind STM Official Arduino codebase, Corporate STM needs to see activity to warrant the costs. Nothing is free.
i found writing codes for the official core may lead to rather neat codes, thanks to the efforts of fpiSTM et.al.
reading mcu temperature literally does so using a minor 'twist' to the same arduino api.
it looked superficially simple, but in the implementation is some quite elaborate codes to read from adc and various ifdefs to make it 'cross platform'
Code: Select all
pinMode(ATEMP, INPUT_ANALOG);
pinMode(AVREF, INPUT_ANALOG);
uint16_t vrefint = analogRead(AVREF);
uint16_t vtemp = analogRead(ATEMP);
the goals of HAL are to go 'cross platform', i.e. across nearly all STM32 mcus, this may inevitably introduce some overheads with IO etc.
it may also have a 'lowest common denominator' effect, e.g. that rather than using a specific mode or feature of a particular mcu, it may target a common feature set instead. I took a look at the HAL ADC codes, apparently HAL really did an effort to implement the 'esoteric' modes as well, hence you're not limited to a common denominator, but it added complexity to the api as well
viewtopic.php?f=62&t=82&start=10#p504
While for libmaple, it is true bare metal programming, the codes mostly if written for one mcu e.g. stm32f103 may not be portable even to say stm32f4. not all cases are non portable though, but those that directly patch and reference mcu registers may be impacted as they are after all different but still when built from source, it likely still work if after all the symbols are the same
writing codes for HAL should aim to use HAL, though one can still reference the registers, but inevitably once the mcu change, there will be ifdefs to accommodate the differences. while i've not really tested it much, perhaps a sketch written for HAL on one mcu may just work across different mcus.
but there still are challenges, HAL may require one to anchor things like NVIC vector tables to point into the HAL stacks. those are apparently left 'open' (i.e. unimplemented), i'd guess as the HAL designers aim for portability. the catch is that in the sketch, it would be necessary to patch hardware level NVIC vector tables to call into the appropriate HAL hooks, the HAL itself literally. this can be different across mcus and it would involve touching the 'core' codes and they are likely different between mcus. i'm not too sure if CubeMX generates codes that in effect patch into HAL. but if it doesn't do that, one would need to patch the h/w hooks manually.
viewtopic.php?f=62&t=82&start=10#p505
