Well thats not quite what I said when I found my bug about 15 mins ago but same sort of general meaning.

We are using the Pi in more and more things and in order to make it easier i’ve been writing our own HAL to make using the GPIO and onboard perhipherals easy to use, wrapping up things that others kinda did, adding new bits and dropping in native support for our hardware. Its been going well hen a few weeks back I hit a reoad block or two.

The first is repeated start, the long answer is that using the IO wrappers for I2c you cant do it. Looking deeper into it the Python lib fudges it too by doing a bulk read so no biggie there. Its no fixable, easilly worked around and in many ways a bulk read is a nicer way to do it.

The second was driving me nuts. I couldnt write a register. I could select it, but the perhiperal always sent 0. After a few hours of head scratching I had to get on with other work and its only today I’ve been able to get back to it.

The long and short of it is that I was trying to be too clever and not thinking about it in a *nix manner. I was opening the bus and then assuming that I could move addresses round as I needed to talk to things, turns out that doesnt work (It may be tied in with the above too). Changing the target address once you’ve set it seems to bugger up the driver and it then sits and sulks. I’m not sure why this should be so but it does. Assigning a new file handle for each device (FPOpen()) and then setting the address works so it looks like thats the way I need to do this. The upshot is that the whole I2C section of the HAL (which to be fair wasnt written) needs redoing. It also points to some issues that were going on with the IMU on the Tezero platform too so its another point in the argument to moving Tezero onto the HAL.

So what does work?
Well GPIO mapping, control and I/O all works a treat. The HAL will map out SPI/UART/I2C pins if the perhipheral is in use. Getting hold of interrupts is hard in Lazarus without scripting bits of Python to do it. The HAL now fudges it by using a thread to monitor the pins. As you assign interrupts to a pin no interrupts = no CPU time used. With all available GPIOs running with interrupts the CPU load doesnt register so thats good. There is a FIFO system in there so a long IRQ handler wont hang the queue.

And to go?
Support ofr specific perhipherals is next. How far I’ll go is uncertain but as the HAL is going down in the Touchdown kits I may go as far as adding specific I2C device support. What is definately going in is support for things like thumbwheels and our TRNet bus system on UART0

Can I have a copy?
Not yet, I’m still testing, but soon 🙂 When its about it’ll be released on http://forum.tswr.co.uk