Comment by ChuckMcM | Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

I was feeling a bit like the Petunia and thought "Oh no, not again." :-) One of the annoyances of embedded programming can be having the wheel re-invented a zillion times. I was pleased to see that the author was just describing good software architecture that creates portable code on top of an environment specific library.

For doing 'bare metal' embedded work in C you need the crt0 which is the weirdly named C startup code that satisfies the assumption the C compiler made when it compiled your code. And a set of primitives to do what the i/o drivers of an operating system would have been doing for you. And voila, your C program runs on 'bare metal.'

Another good topic associated with this is setting up hooks to make STDIN and STDOUT work for your particular setup, so that when you type printf() it just automagically works.

This will also then introduce you to the concept of a basic input/output system or BIOS which exports those primitives. Then you can take that code in flash/eprom and load a binary compilation into memory and start it and now you've got a monitor or a primitive one application at a time OS like CP/M or DOS.

Its a fun road for students who really want to understand computer systems to go down.

At my school, we did the following project : https://github.com/lse/k

It is a small kernel, from only a bootloader to running elf files.

It has like 10 syscalls if I remember correctly.

It is very fun, and really makes you understand the ton of legacy support still in modern x86_64 CPUs and what the os underneath is doing with privilege levels and task switching.

I even implemented a small rom for it that has an interactive ocarina from Ocarina of Time.

What is your school? I thought it was the London School of Economics, but it’s another LSE.

It's EPITA, in France.

LSE is the System's laboratory of EPITA (https://www.lse.epita.fr/)

This is really neat. So many engineers come out of school without ever having had this sort of 'start to finish' level of hands on experience. If you ever want to do systems or systems analysis this kind of thing will really, really help.

Also, if anyone wants to try it, the whole course is available publicly here (in English) https://k.lse.epita.fr/

No BIOS necessary when we're talking about bare metal systems. printf() will just resolve to a low-level UART-based routine that writes to a FIFO to be played out to the UART when it's not busy. Hell, I've seen systems that forego the FIFO and just write to the UART blocking while writing.

I hope nobody was confused into thinking I thought a BIOS was required, I was pointing out the evolution from this to a monitor. I've written some code[1] that runs on the STM32 series that uses the newlib printf(). I created the UART code [2] that is interrupt driven[3] which gives you the fun feature that you can hit ^C and have it reset the program. (useful when your code goes into an expected place :-)).

[1] https://github.com/ChuckM/

[2] https://github.com/ChuckM/nucleo/blob/master/f446re/uart/uar...

[3] https://github.com/ChuckM/nucleo/blob/master/f446re/common/u...

Yup, I recall Atari ST (68000) and BBC Micro (6502) having unbuffered and interrupt access to 6402 UART - which I used to C/ASM to fire MIDI bytes to and from.

This was my attempt at a minimal bare-metal C environment:

https://github.com/marssaxman/startc

That's awesome. Back in the day this was the strong point of eCOS which was a bare metal "platform" for running essentially one application on x86 hardware. The x86 ecosystem has gotten so complicated that being able to do this can get you better performance for an "embedded" app than running on top of Linux or another embedded OS. That translates into your appliance type device using lower cost chips which is a win. When I was playing around with eCos a lot of the digital signage market was using it.

Does anyone still do it that way?

With AMD64 style chips? Probably not. Multi-core systems really need a scheduler to get the most out of them so perhaps there are some very specific applications where that would be a win but I cannot think of anything that isn't super specific. For ARM64 chips with a small number of cores, sure that is still a very viable too for appliance type (application specific) applications.

This sounds fascinating and absolutely alien to me, a Python dev. Any good books or other sources to learn more you can recommend?

There's always the Minix book!

You can start here, https://wiki.osdev.org/Expanded_Main_Page

Also regardless of what others say, you can have a go trying to feel how it was to use BASIC in 8 bit computers to do everything their hardware exposed, or even 16 bit systems like MS-DOS, but with Python.

Get a ESP32 board, and have a go at it with MicroPython or CircuitPython,

https://docs.micropython.org/en/latest/esp32/quickref.html

https://learn.adafruit.com/circuitpython-with-esp32-quick-st...

Reply on news.ycombinator.com