Unconventional baud rates in USBizi and Fez

[realiser]

That is true. I just somehow always seem to hit the 1% nobody else need to worry about in my projects

This was a very strange set of circumstances. To summarise for those interested, here’s why every “standard” avenue turned into a dead end. I’m pretty sure this isn’t the case with most other modules, but an interesting learning experience none the less. I’m not going to detail again how I got to these conclusions - just take this as simple lessons learnt…

1. You can’t read asynchronous data with the USART module if the data stream isn’t properly framed with a start bit and a stop bit. NETMF allows for a Zero stop bits setting, but the LPC2388 doesn’t support it.

2. You can’t use interrupts to capture signals changing faster than about 100uS (10kHz). This is just an estimate based on my experiments.

3. You can’t “bit bang” capture a signal faster than about 10kHz either. In other words it doesn’t help sitting in a tight loop recording bit transitions. A read/store cycle takes longer than 50uS - more like 150-200uS depending on what you’re doing. Interrupts actually worked better than brute force.

4. You can’t use the built-in NETMF SPI class for bit rates below a couple of hundred kHz because it hardcodes the prescaler value and overwrites the register every time Write() executes. I had to use registers to get to a “low” bit rate of 65uS and pretty much write my own SPI class from scratch. The Register class is my new best friend - thanks GHI!

5. The SSP module is a wonderful thing. It can be used for things unrelated to SPI and is very flexible. I’m glad I learnt this one. Read the section in the LPC23xx user manual.

6. However, you can’t wait for a low to high transition on the MISO line and then start clocking in data under about 80 - 100uS. NETMF is too slow with a “while(!SCIO.Read)” and there’s nothing in the hardware to do it. Unfortunately this is how the module signals to the processor that there’s new data and you need to respond fast. This is not standard SPI.

7. Finally, you can’t get SSP to output a constant, uninterrupted clock stream (and capture data at the same time). Not even with DMA. It creates a small delay between every 16 bits. I couldn’t find a workaround to this.

I cannot think of a reason TI chose to implement this very non-standard and difficult to use protocol, but it’s been like that since the 90’s. The bottom line is that sometimes you just need a different tool for the job. Where most jobs are easily done with C# and NETMF, this is one example of something best done with C and inline assembler on a dedicated processor.

I’ll let you all know how it goes with Plan B. Thanks for all the help and support so far.