Hello hello,

First of all I was thinking that some of the experts around here could actually start an exhaustive discussion about peripheral driver development for newbies or unexperienced, such as yours truly. I find that theory is in many places, registers of classic peripherals are found also, but never a theoretical way of writing them... That's for you psters in whom I trust :) and admin to whom I suggest it.

Now back to me...

Not newbie to C but still newbie for very low embedded C development.

Here's the situation. When developing firmware, the project I'm on uses ARM models, GNUARM libs etc. And I'm looking into UART. There was already a very cute and simple driver , registers are acccessed super rapidly (through some arrangemnt with HW?) through

(*(volatile uint32_t *)(addr))

So no worries, there are uart_write/read isr and some other functions in the driver, looks so damn obvious once reading the registers that are normally in UART controllers in peripherals.

BUT, a new microprocessor will be used . Communication is going to use SPI, 3 wire (+ a 4th for slave selection but not important now) 1 clk one out one in.

I have the datasheet of the microcontroller, I can see the in and out pins which are used, but normally HW cares about that right?

My problem is how do I write a good driver, which is going in the firmware (unless my embedded skills are that low to imagine that to be wrong too) and who will act right when somebody on the PC send something through SPI to the board with the MCU?

I wonder if you see it though my eyes but... anyway, general advice for drivers is always useful...

A, and there is a compiler for that MCU, do you think there are special.. header files for register access (in case it should be like the ARM more or less)?

Thanks for anything,


At a guess, you need two drivers
- one to talk to the bus (bash the bits back and forth)
- one to talk to the device at the other end of the bus.

The first is fairly general, it can be used to talk to anything on the SPI.
The second is rather more specific to the device(s) attached to the bus.