12/29/2015, Initial code complete

Screwed up title of last post.  Oh well.  I’ll correct it after I finish this post so people don’t get spammed with two different updates on the same day.  Hopefully WordPress is smart enough not to do that, but who knows.

Joe keeps reminding me that I don’t need to support incandescent bulbs.  The incandescent boards simply support higher current outputs.  A typical incandescent bulb is about 200-350 mA of current (depending on if it is a 44 or a 47 bulb).  The Ablaze 4 SMD bulbs that I have tested are around 80 mA of current.  The incandescent board can support about 350 mA continuous current per bulb.  It can just as easily support LED bulbs, they just have less current per bulb.

So I had to send a bunch of Christmas presents out just before Christmas.  I ended up trying out Ship Gooder. In the US, these guys really rock for low cost shipping.  Even checked out prices of shipping stuff to New Zealand and they were way cheaper than anything else I could find.  Shipped a rather large 16 pound box (16.5″ x 16.5″ x 16.5″) to Pennsylvania for about $10.50.  Stuff got there in about 2 days which is fantastic.  The price was so cheap that I thought it might be a scam, but all packages were received successfully.

Spent far too much time creating a test fixture.  What I thought would take a day ended up taking about 3 days of my hobby time.  For some reason I love creating test fixtures and automated tests for that matter.  Maybe it is coming from a regulated environment and far too many startups.  It also partially comes from my first job of having manufacturing located in the same building as engineering.  When the people on the floor had problems they came up and asked you questions and then you had to go down and fix any issues.  It really taught you to make sure things were working/tested properly so you didn’t get to a situation where you had questionable software and hardware.  (For reference, it is almost always the software)  Of course, I’m not going to run the boards through a heat chamber for 3 days with cycling temperature to verify all the solder joints, but I do remember when that was the gold standard for board manufacturing.

Completed a significant update on the board interface document.  I removed the first generation card information to make it significantly more readable.  Added pictures showing the pinouts of the wing boards.  Added Python example code for generating the CRC8.  Here is a link to the brdIntf document in PDF format.

Still have issue with first neopixel, but haven’t actually taken time to look into it yet.

12/21/2015, Still on track

It’s been a busy couple of weeks with a lot of coding and a good amount of testing.  I’m still on track to finish the initial coding/testing of the Gen2 hardware by the end of the year.  It’s been a pretty big push towards the end of the year to get this to happen, but hey, soon it will be done.  The first version of the code will not support switch matrices or lamp matrices.  They should be trivial to implement in firmware, but making up a good test fixture to test those features will take a lot of time.  (I don’t have the necessary 64 switches or 128 diodes for that matter to test that functionality and it is feature creep compared to what is needed to run a pinball machine.  The only real reason to use those features is that you don’t want to distribute the control system, and want to pull all the cards back up into the backbox.  That would involve more wiring which is what I’ve been working to simplify).

While this has been happening the price of the PSoC 4200 has dropped to $3.75.  After I finish the code, I’ll work up another spreadsheet on the cost of getting a board set to run a pinball machine.  I did one before, but I’m not sure how up to date it is at this time.

So every once in a while a new processor comes out and I wonder to myself, why don’t I use that processor?  Well, this Thanksgiving the Rasp Pi zero came out (at a price of $5 which floors me) and of course I had to read up on all the specs because I’m a geek and absolutely fascinated at the price of cheap cool processors.  (One of the games that I love playing is how many processors in this room or house or car are bigger/more sophisticated than the processors that were used to send people to the moon and how much bigger.  Just so you don’t have to look it up on Wikipedia, it ran at 2 MHz, had 2K of RAM, and 36K of ROM and was a 15 bit processor.  The PSoC runs at 48 MHz, has 8K of RAM, only 32K of flash, and is a 32 bit processor so I’d say the PSoC is about 50 times faster/bigger.  Probably over sharing at this point, so let’s get back to pinball).

Some people might wonder why not use a Raspberry Pi zero for all the processors?  Hey it’s only $5.  Why not use that for the real time controller?

1. First problem is that it isn’t 5V tolerant.  Some FETs have a threshold voltage of 3.3V, so it is easiest to use a 5V output to make sure that the FET is fully on.  If the FET is not fully on, it generates a ton of heat which can cause major issues (and eventually smells really bad because of the smoke coming off the chip.)
2. 5V for inputs gives you more noise margin for noise generated by those pesky solenoids.  It shouldn’t be a problem but any extra margin is helpful.
3. The Pi zero only has about 20 or 24 I/O.  I can’t remember off the top of my head.  The PSoC has 40 I/O which is a major sweet spot.  It has 4 full 8 bit ports for I/O, then the extra 4 pins can be used for communications (2 pins for tx and rx), and 1 pin can be used to synchonizing boards across multiple boards.  Very important if you want all your LEDs to blink at the same time since they are being driven by multiple boards.  It even has 1 extra pin that isn’t currently being used.
4. More difficult to write a real time kernel.  I think somebody has taken the time to do this for the Pi, but the Pi contains a much more complicated and functional chip.  I can’t imagine going through the manual for that guy.  It must be absolutely immense.  The PSoC manual is about 1000 pages, maybe more if you are looking at the technical notes and that is enough to try and wade through.
5. It has a ton of functionality that isn’t very useful in a real time environment (i.e. a GPU so it can drive a HDMI monitor).  That would not be useful at all on boards residing under the playfield.

The Rasp Pi zero might be perfect for the main controller, but as the real time controller, it just doesn’t make sense.  Even as the head end controller, the Rasp Pi A or B might make more sense because it has audio outputs and more USB ports to store extra data.

Finally got a chance to look at the incandescent wing card in more detail.  I was hoping to use the PSoc 4200 pins as open collectors and pulled to 12V so I didn’t need a second FET to step up the voltage.  Turns out that there is a clamping diode in the part (to protect against ESD/over voltage) so that won’t work.  The good part is that the incandescent wing boards will still work as low side switches as long as I swap the orientation of the FETs in the circuit.  The one down side of this is that it won’t work as a lamp matrix because you need to be able to support both high side and low side switching to turn on/off the individual columns.

To support the high side switch I would need a second set of FETs which will not fit on the boards using the TO-92 packages.  So one idea that I started toying with is switching to a SOT-23 package for this card.  This would break my rule of having no surface mount parts, but the SOT-23 package is large enough that it is rather easy to solder by hand.  (I think it might be easier to solder than the TO-92 packages since you need to bend the leads, solder, clip off the excess leads, etc).  I spent a little time this weekend and think that I can create a card that has the high side switches on the top of the card, and the low side switches on the bottom of the card.  Depending on what is needed, the user populates either the top or the bottom of the card.  That seems like the best of all worlds.  The layout is tight, but I’m pretty sure it will work.

Should I support incandescent bulbs fading slowly and quickly?  It would involve PWM’ing the incandescent bulbs, but it would probably be as simple as a little RAM based lookup table to support the multiple levels.  The neopixels support fading in and out, so it seems like the incandescent bulbs should also support that functionality.  I would probably not support that until a later version of code with a new command.

Depanelizing boards is rather difficult so I started to think about ways around that.  Turns out that ITeadstudio will do a groove for free as long as the boards are the same design.  That should be much more accurate than cutting them out with a tile saw.  Running the numbers (because now each of the boards would need to be separated on their own 5 cm x 5 cm design) it adds an extra $10 a set of boards.  Last time I depanellized a group of boards, it took me about 2 hours, so even I can’t seem to justify that doing that myself.

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.