Im a bit Lost here ( NEW USER / DEVELOPER )

[ag123]

i'm trying to transit to cmake, accordingly it is 'better' & Raspberry Pico uses it in the SDK.
and accordingly platformio uses something even more elaborate which is
https://scons.org/
a thing about platform io is that it lifts the STM core from a 'clone' of the original repository, so it may get out-of-sync


On another note the new typescript(javascript) Arduino IDE isn't quite that 'smooth' a usage and is huge, I last remembered an install footprint of some 800 megs or so. I'd guess it is 'under development' so it'd take time to be better. There used to be an issue about code reference lookups that affected codes with stm core (something to do with arduino-cli returning an error during compile) and the symbol references are not generated. so things like goto definition fails for any of the symbol lookups. The issue probably needs to be fixed in arduino-cli, but I'd think it is still outstanding as the developers seem busy with other priorities.

[ag123]

As for 'libraries' not 'everything' works, even if it is well written, they may target a different platform e.g. atmega328. You'd not know till you dig into the codes. more likely codes that target stm32 won't be portable to 'most other chips' if any of those hardware registers are referenced.
And things like HardwareTimer may be a design native to stm32, other platforms/chips may not do things the same way.

[javier]

i'm trying to transit to cmake, accordingly it is 'better' & Raspberry Pico uses it in the SDK.
and accordingly platformio uses something even more elaborate which is
https://scons.org/
a thing about platform io is that it lifts the STM core from a 'clone' of the original repository, so it may get out-of-sync


On another note the new typescript(javascript) Arduino IDE isn't quite that 'smooth' a usage and is huge, I last remembered an install footprint of some 800 megs or so. I'd guess it is 'under development' so it'd take time to be better. There used to be an issue about code reference lookups that affected codes with stm core (something to do with arduino-cli returning an error during compile) and the symbol references are not generated. so things like goto definition fails for any of the symbol lookups. The issue probably needs to be fixed in arduino-cli, but I'd think it is still outstanding as the developers seem busy with other priorities.

That sounds like advanced wizardy to me, and i wish you the best.
The only thing i wanted to know was what the hell is Arduino actually compiling when you press that green button. Aaand where to look for that code.
Because i want to be able to "port/merge" my cubeMX generated progects/library into arduino.

This gave me a overall clue of the process: https://arduino.github.io/arduino-cli/0 ... d-process/

This show me how is the startup hidden boilerplate code defined https://github.com/stm32duino/wiki/wiki ... figuration
i know now thanks to you that all important clock and peripheral definitions can be overwritten by adding this file in the sketch folder:

hal_conf.png (46.08 KiB) Viewed 5130 times

But i still dont know what format or where is Arduino making those #defines effective

mx periph init2.png (32.33 KiB) Viewed 5125 times

Is arduino CLI calling this function?It looks important, and very startupy.
But i still dont know.

systeminit.png (46.36 KiB) Viewed 5127 times

[ag123]

The arduino api is here
https://www.arduino.cc/reference/en/
it probably has roots in wiring api
http://wiring.org.co/reference/
which borrows from processing
https://processing.org/

the idea is to simplify the interfaces so that it isn't so intimidating for those who touched microcontrollers for a first time.
hence the 'famous' abstraction

Code: Select all

void setup() {
 // initialization codes goes here
}

void loop() {
  // runs forever
}

for all the rest you can look for codes in main() etc.
the *duino() api become an 'industry standard' as it turns out it is rather feasible to use same/similar api across vastly different mcus.
But that there are lots of limits if only the api is used.

most of things that leverage the platform, e.g. hardware timers and the specific features do not conform to the arduino api and it is questionable if other mcus provide the same implementations of those pheriperials.

---
cmake and scons
they are 'ahead of time' i.e. uses 'dependency injjection'.
in the 'ideal' world, you define configurations and build modules
then you can simply configure what you want click build and you get your firmware
cmake, scons is a step closer by injecting the relevant dependencies / modules
stm32cubeide is pretty close to that as a commercial solution.

arduino-cli is half way there
but has some of those features as it lets you swap the core and the boards for the same sketch

[javier]

The arduino api is here
https://www.arduino.cc/reference/en/
it probably has roots in wiring api
http://wiring.org.co/reference/
which borrows from processing
https://processing.org/

I understand that but doesnt give me any clue of where the init code is taken from.

for all the rest you can look for codes in main() etc.

This has been mentioned before but i dont understand, where can i find that "main()"?
Are you referrig to a function/file/folder...?

the *duino() api become an 'industry standard' as it turns out it is rather feasible to use same/similar api across vastly different mcus.
But that there are lots of limits if only the api is used.

I could imagine the challenges of making a trully compatible multi-mcu API.
Yup im facing a limit right now, i just want to control what peripheral is initialiced and when, as i am able to do with STM32cubeMX

most of things that leverage the platform, e.g. hardware timers and the specific features do not conform to the arduino api and it is questionable if other mcus provide the same implementations of those pheriperials.

I want to make a DMA+PWM custom library for example, im only interested in a particular mcu

cmake and scons
they are 'ahead of time' i.e. uses 'dependency injjection'.
in the 'ideal' world, you define configurations and build modules
then you can simply configure what you want click build and you get your firmware
cmake, scons is a step closer by injecting the relevant dependencies / modules
stm32cubeide is pretty close to that as a commercial solution.

arduino-cli is half way there

So you say i need to learn my way into how arduino-cli injects/sticks firmware modules together if i want to know what am i compiling.

[ag123]

to find main() an easy way is to do a text search in the core

maybe codes you'd see is

Code: Select all

void main() {
	setup();
	while(1)
		loop();
}

everything else is platform specific. and because of that, codes or 'libraries' would likely break when simply they are used on a different platform.

[javier]

Jeeeesus that is exactly what i was looking for, sorry for all the fuzz.
Sometimes is hard to articulate what you dont understand yet.

Now i just need to look inside that premain()
I think i can work from here, thanks for your patience

main.PNG (66.64 KiB) Viewed 5097 times

doll poop.jpg (75.4 KiB) Viewed 5022 times

hw_config.png (61.99 KiB) Viewed 5019 times

Things initialised automatically before setup() by arduino that i know of :

• HSE 8Mhz xtal and internal clocks

• USB device if chosen in Tools/USB support:

[ag123]

if this is 'confusing' then dependency injection is worse.
i.e. cmake, scons etc
as in theory, u'd just configure modules & compile
everything is loosely coupled

[mrburnette]

...
everything is loosely coupled

... ummm ... like a circus contortionist in a Jar:



Just a thought:
ag123: maybe viewtopic.php?f=2&t=301 needs to have a link to a WiKi summary of this thread? At this time, STM32duino under Arduino sub-2.x is unlikely to change anything discussed here.

[javier]

i guess they both look happy because they dont know the existance of cmake