Can’t be worse than x86, can it?
x86 has a BIOS to prepare the system for you, ARM doesn’t
Almost everything (if not all) that BIOS does for ya you want to discard and go to long mode with vm and lapics anyways. Real mode with segments doesn’t quite cut it.
Raspi 3 GPU firmware starts the Cortex running in aarch64 in hypervisor mode on all 4 cores. So i need to set up interrupts and vm. And off i go.
I think you’re missing the point. The BIOS does a literall ton of hardware setup work for you before handing over control. From the basics such as configuring the system PLLs and programming your IO controllers with initial sane values, all the way up to loading microcode into the CPU, memory tuning, initialisation and testing, posting the Video card, initialising the HDD controllers, Ethernet, and programming the CPU MTRR flags which there are literally hundreds. The BIOS does an absolute ton of early initialisation of your hardware that you never see.
You may throw away all the old school BIOS interrupts, etc, but everything leading up to that point is extremely complex and very hardware specific. In essence, bare metal programming.
On the RPi much of that is done for you in the binary blob, which I suppose is a primitive BIOS, but also hides you from all the gory details and as such you never learn about these things.
When you program a full ARM core directly you get to learn about programming the PLLs, calibrating the memory controller and initialising the RAM, configuring voltages, initialising peripherals, etc. The work the BIOS does on x86.
The ARM Coretex-M3 is a cutdown ARM, and is not as complex to initialise which is why it’s a good jumping off point.
1 Like
Nice to see so much activity here. @Shecks just blink some LED 
that’s always what I am starting with. @gnif yeah using vim as an IDE, been there done that, but vsc works nicely almost out of the box (took me less than an hour to get to a stage where i am happy). Since you seem to have some experience with this, might i ask of you’re opinion on HAL. Wether to use or better avoid it? For now I am sticking with it since it seems to be faster to develop and you might find some code online that helps you out. I also just did my latest devlog, although its not that spectacular.
1 Like
Sure, I am happy to use an abstraction library provided it is written well. The ST libraries are total junk and I avoid them like the plague. My favourite at this point is ChibiOS as a RTOS, it’s very well supported, has a good HAL, and is well written, however it’s license is a little restrictive IMO.
Yeah I meant specifically the ST HAL. I might look into ChibiOS but I think for now an RTOS is sort of out of scope for what I am trying to achieve. But who knows, gonna keep it in mind. The license scheme is weird but as I understand you can use it completely with GPL3?
Next DevLog, by the way let me know if you want more details or want to know something specific. Cheers.
Currently I am just stuck… kinda frustrating. I got no clue why my code won’t work.
What’s happening? Where you at?
I was trying to let the DAC do automatic Waveform generation.
The Waveform is stored in an array somewhere in memory and DAC when triggered by a timer (timer6) should request a DMA transfer from the current part of the waveform array and then render it. The waveform array should be accessed in a circular fashion by the DMA. However the DAC isn’t spitting out any signal at all.
I have never done any DMA stuff on a micro before.
Are you using a timer interrupt? If so you could write other values instead to test.
Or is it just timer based and independent of the main thread somehow, since you are using DMA?
As far as I’ve understood it, the timer just triggers the DAC peripheral and a few cycles later it has rendered an output. If DMA is configured on the DAC it should just map that timer onto the DMAMUX (sort of like a request handler) which in turn after further checks wether this should be a synchronized task or not requests the DMA module to shove data over the bus matrix toward the peripheral which has requested it. So no Interrupts used, the CPU is pretty much untouched and can go on with other things which is why I want to get it to work.
Yeah sounds like the way to go. Bogging down the CPU with a bunch of interrupts can be risky. But I don’t have any suggestions, I have never tried to do this…
Still having DMA issues?
Well, I kinda changed the way I wanted to tackle the problem. I found the HAL not working, and since i wanted to get more familiar with the device (and toolchain) I dove in deeper into the rabbit hole that is the 3.3k pages reference manual. I want to ditch the ST HAL and write my own (at least for the module i want to use). The thought is that I probably have a misunderstanding of how the modules are supposed to work and thus try to use the HAL wrongly (has usually been the case for other libraries, I sometimes miss how the data structures and functions inter operate). So diving in usually clears the road ahead for me. But today I had some fun with odd behaving code, compiler optimization and the debugger (everything still just involving the DAC tho). I hope that come next week, I have started with my HAL.
2 Likes