Generalise to more hardware

[mickp]

Eventually, we want to support more devices, so I've opened this issue to track discussions relating to this.

I don't think there's any reason why we can't have the same code running on any ARM-based platform. We'd need some description for each platform, but I think this could be fairly simple. Basically, we're setting or reading values at a collection of ports. For each port, we need:

• a base address
• a width
• a mode: read, write, or both
• to determine whether we set/read the whole port in a single operation, or bit-by-bit
• for bit-by-bit ports, any bits in the port width that we can not use (e.g. they're reserved by the hardware)

The single-operation ports are for things like DACs, ADCs or other devices that use parallel comms (some piezo controllers, for example).

The bit-by-bit ports are our triggers and boolean feedback lines (e.g. limit switches, ready indicators on cameras.)

At some point up the chain, we may need to worry about the maximum rate at which ports are or can be updated, but I don't think that's essential for the lowest-level code which just flips bits - it can probably be taken into account when we create an action table.

[carandraug]

Agreed, we should have the same code running in all systems. I can add the autoconf magic to do that once we collect the different data for each board. Do you think it's reasonable to try and automate the identification of the board? I'm unsure if it's worth it since I would expect to be simpler to support cross-compilation.

[mickp]

I would've thought we could use the same binary on a bunch of boards based around the same ARM core, and just pull in the port definitions at runtime.

Identifying the board might be tricky.

We can ID the SoC (e.g. Zynq) from the chip's Main ID register (although that might need a kernel-mode call), or the /proc/cpuinfo Hardware field:

We might be able to get fingerprints for different boards from /proc/iomem and /proc/interrupts, maybe.