12/13/2015, Input/Solenoid Code Updated

Spent most of the last couple weeks rewriting the solenoid and input wing board code.  I originally simply ported the code to the new processor and thought I was done.  Then I quickly realized that it would work, but it wouldn’t work as efficiently as it could.  The problem was that the code used to run on two different processors.  Now the code would run on a single processor which is much more capable.  That means that I can use much of the same processing for both the input and the solenoid boards to trigger the solenoids.  Grrr, the only way to be happy with the code was to rewrite it.

The previous processor was an 8 bit processor, and the new one is a 32 bit processor.  That means some of the processing could be made more efficient because of the larger size of the registers.  I now also have registers.  Oh joy.  Before, everything was either on the stack or on the two registers.  (an 8 bit register, and a 16 bit index register)  No more.  The PSOC 4200 is much closer to a “real” processor which has the typical 16 registers for running code.

Next up it was time to start tackling the communications.  This involved rewriting the low level driver.  The code is now receiving commands and transmitting responses.  I’m still not 100% happy because the hardware comes with an 8 byte buffer in the transmit and receive directions.  At this point, it would be more efficient to keep the received data on the internal FIFO and have the higher level driver pull it off as needed.  That’s different than the previous processor which only contained a single byte buffer, and the data had to be pulled off very quickly.  Of course with the deeper FIFO, I’ve increased the speed of the UART to 115,200 bps so I should be able to send and receive a lot more data.  (The old driver ran at 19,200 bps which was plenty for a pinball machine, but more why not move to a 5 x faster rate).

Right now I think that I’m missing bytes every now and then because I’m moving the 8 byte FIFO through a single byte to hand it to the RS232 command processor.  It should be straight forward to leave the data in the receive FIFO and process it directly from the receive FIFO.

The nice part is now there are so many things working that it only takes a little bit of time to fix things.  I’m definitely over the learning curve hump on the processor.

I did find a weird issue with the processor.  In the SCB_INTR_RX register, there is an SCB_NOT_EMPTY bit that indicates that the receive FIFO is empty when set.  It is a write one to clear bit, so I was hitting the bit, and then reading it back immediately to see the status of the FIFO.  It turns out that the hardware doesn’t immediately write back the status of the FIFO, so it seems to confuse the processor.  I’ve changed the code to use the SCB_RX_STATUS register to get the number of bytes in the receive FIFO, but needs a couple more assembly instructions to have it work.

New commands to support the incandescent board have been added to the board interface document.

I’m still on target to have the fully running version of firmware by the end of the year.  I’m almost to the point where it is just testing/testing/testing.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s