11/14/2021 – Year End Update and Pintastic on 11/19/2021

What? A year end update in the middle of November? Well, hey, why not. OPP just released a new regression tested version of firmware (2.3.0.0) and with that, there needs to be some celebrating!

First up, I gotta thank Cobra18t because many of the additional features to OPP firmware would not have been done without him pushing me. There’s been some really great things that were always on the back burner, but with his tireless pushing of the homebrew pinball envelope, he kicked my butt enough to force support. Let’s talk about each of the added features, since, well, I haven’t actually updated the blog for six or so months.

1. Fade support added for Incandescent wings. Sorry about how long this took to support, but after all the work on fading done for NeoPixels, it became very easy to support it for incandescent boards. JWilson (PinballMakers website guru) asked me for this years ago, but I was always worried that the processor didn’t have the umph. With the switch to STM32, many things became significantly easier because of the extra horsepower in the processor. Fade support was made “generic” and this was leveraged later in the year for other new projects.
2. Added WING_SW_MATRIX_OUT_LOW wing type which allows active low switch matrices to be supported. This removes the need for MPF users to use type: NC (normally closed) and reverse logic. I think it also forced users to wire hook into the matrix “backwards”, so those dark days are now behind us.
3. Lamp matrices are now supported. I think Cobra even sells a board to do this. Always thought I was going to get around to doing this board, but fortunately Cobra beat me to it. He did all of the testing which made my life even easier. Funny part is that I have actually never seen this board, but yet the firmware is driving it without an issue. (Nice remote integration!)
4. Minor bug fixed that was causing Neopixel processing to stop after a long time. This one was absolutely nasty to find, until Cobra finally found something to reproduce this issue very quickly. As with all these things, once we new the issue, the fix was very simple. This makes Neopixel processing rock steady (and significantly more efficient than FadeCandy). Why buy a $20 board when you can grab a $3 board that does the job a little more efficiently. The main issue I had with FadeCandy was the crappy pixel server that ended up eating a whole core just to run updates. Phoey.
5. Added servo support on wing 1. Any input on wing 1 can now be configured as a PWM output to support a servo motor. Servo outputs also use the generic fade commands so that they can move between two positions without the host processor intervention. That essentially allows velocity of moves to be programmed. (No acceleration support, but should be good enough for pinball toys).
6. SPI LED support (aka SK8922 and APA102 chips). Why not? Krayon wanted brighter LEDs and said the SPI LEDs were much brighter. Boom…support was added after he twisted my arm. (It was actually relatively simple and uses 90% of the same code as the Neopixel code.)
7. PWM the initial kick pulse to reduce initial kick power. Both Jan and Cobra ask for this, but Cobra had some great justifications. He implored, that many homebrew pinball people were digging in the scrap heap (I know I’m one of them), and sometimes get parts that run at various high voltages. While reducing the initial kick pulse length works in most cases, it is actually better to reduce the voltage to the solenoid by PWMing the driving MOSFET. (Wow, that last sentence is wayyyy oversimplifying driving a coil, but I’ll ignore that fact). Well, it is hard to argue with that logic, and so support was added. While in there, the firmware was changed for the hold PWM to use a period of 1 ms instead of 16 ms. This should reduce the amount of drooping seen in machines that PWM their flippers for the hold portion of the cycle. (It also means that the hold will be slightly more powerful, so be careful of that).

Wow, that is a crap ton of new features this year…and that doesn’t even talk about the hardware side. Cobra created an all in one board that now allows people to buy a single centralized solution to drive their pinball machine. He ran a Kickstarter, and kicked some serious butt by getting supporters. He does mention OPP has been around since 2016, but the blog started in 2012, and the first boards were received on 5/30/2012. Wow. Six months from now will be the 10 year anniversary. Back to Cobra and his multiple projects. He also created a Satellite board with 8 solenoids, Neopixels, and 23 direct inputs. But he wasn’t done. Why not an Xpansion board that has an 8×8 lamp matrix, 8 solenoids, and 8 switch inputs. Then he created Neopixel based segment displays. When does this guy sleep? Read about the projects on Pinball Makers. Buy his stuff through his shop if you so desire. He isn’t beating my $60 bargain basement pinball controller, solder itself price, but for those that don’t want the hassle, it is a darn fine way to go. (See Gerry, it wasn’t me that you needed to worry about, it was actually Cobra! I’m too lazy and don’t want the hassles of selling to people). Cobra has also been great at answering questions on the MPF forums, which I rarely do.

How can I give shout outs to people without mentioning Jan. His tireless dedication to MPF and supporting all the random features that I create has made OPP much more accessible to the masses. Jan, you keep moving MPF forward, which most open source projects fizzle away because of a lack of a champion.

So what else is going on? Well, Pintastic moved from a Summer based show to, well, this coming weekend. I think it runs from Thursday to Saturday 11/18/2021 – 11/21/2021. The one event that I always attend is the homebrew forum which is at 3:30 pm on 11/19/2021. The origins of that forum has been going on since like 2015 which was some pretty early times in the homebrew pinball community. We have come a long way from there, and I think there are supposed to be something like eight homebrew machines this year. I’m going to grab a couple games on Sonic Spinball, but it is always interesting to see what else is out there and what unique ideas people have. Hilariously, I have never met anybody who reads this blog. Make my day if you see me. Mention that you have stumbled upon this blog, and maybe it will get me to post updates more than two times a year. (Unlikely, but it is always a possibility).

Maybe something big will happen next year, but maybe not. I hate to make promises that I will never complete, so this year, ha, ha, absolutely no promises for next year. Gives me a 100% guarantee that I will complete those goals.

I’m going to end with a quote by Jan, which made my day when he sent it to me. (I hope he is alright with me sharing it, but he probably doesn’t read this blog either so he will never find out that I posted it.)

Jan says, “OPP rocks! By now it left all independent vendors behind feature wise. Spike still has some additional stuff but OPP is getting close.”

I’m coming for you, Spike you over priced shift based register solution. (Cobra says it isn’t overprice, but, ehhh, let me live in my dream world. Hey Cobra, it is so overpriced if you buy it from Terry and his scalping prices.) On that bitter note, everybody keep on building homebrew pinball machines! Let’s see some of that creativity out there so it just isn’t one fan layout after another.

6/6/2021 – Neopixel firmware fix

For those of you using OPP to drive Nopixels, Cobra18t found a bug in the firmware that was just updated in the repository. After about 2 hours of playing his machine, the Neopixels updates would stop working, but everything else (switch inputs, solenoids, serial comands) worked perfectly. We spent the last couple of weeks trying different things and attempting to make it more reproducible. On Thursday he found that if he shorted PB12 to ground, the Neopixel updates stopped immediately. This was the info we needed to track the issue down to the root cause and found the NSS pin was not being ignored. The firmware was updated to configure NSS as under software control and that has seemed to fix the problems. A full regression test was run and version 2.2.0.0 is now available in the repository. I would suggest updating if using Neopixels and OPP. (I’ve also added verification of serial commands, so malformed commands will simply be ignored. This was one of the guesses of what the original problem might be.)

2/12/2021 – New features are coming

Well it has been relatively quiet over in OPP firmware land, but with the advent of the CobraPin kickstarter, a couple more features were added. Going back into the way back machine, Jeremy from many years ago asked me to support different intensities for incandescent wings. With all of the work that Cobra and Jan put into helping me test the Neopixel features, it seemed that it was time to leverage those commands and support 32 levels of intensities for incandescent bulbs. Just as with Neopixels, a command can be sent to set the intensity of each bulb from 0 (off) to 0xff (100% of its full blazing glory).

The incandescent intensity command is the same as the Neopixel fade command with an offset of 0x1000 to indicate an incandescent bulb intensity is to be changed. So an offset of 0x1003 changes the intensity of the fourth bulb. The STM32 supports up to 32 incandescent bulbs, so the offsets range from 0x1000 to 0x101f.

But wait, there is more! If OPP can support various incandescent bulb intensities, why not also support fading of incandescent bulbs just like you can fade Neopixels on and off. You ask for it (well actually nobody ask for this feature, so let’s start again)…Nobody ask for it, so that’s why it was coded. The OPP fade engine is now generic so it can apply fades and various fade times to individual LEDs within the Neopixels, or incandescent lamps. Just like setting intensities, it works exactly like Neopixel fading except with an offset of 0x1000 for the first bulb.

You’re probably thinking to yourself that those changes are more than sufficient for all your pinball needs, but no, you wouldn’t be correct. Turns out some people don’t like that the switch matrix is driven using active high logic. So very few pinball machines use active high logic (unfortunately the Bally machine that I implemented switch matrices on was one of them). Because of that, some people had to switch the columns and rows of their switch matrix to make it work. Those days are now over. Change the python wing configuration from WING_SW_MATRIX_OUT to WING_SW_MATRIX_OUT_LOW and badda bing, it is now an active low switch matrix. I doubt if anyone will change the configuration of currently running machines, but future machines may benefit from this change.

One last big non-announcement. A new plank board is being created by Cobra18t. I even heard he ordered a prototype just a couple of days ago. We have been going back and forth with firmware and trying to get everything just right. I cut him a firmware version a day or two ago, and we both agree that it looks like it might be fully working with the limited test setup that he cobbled together. I’m not going to spill the beans and tell you what the new plank is, but I will let him announce it when he is good, ready, and happy with its performance.

So, yeah, I can support more features in the firmware (of course it makes the firmware more complex which some wonder why all the complexity (that comment made me chuckle to myself…hey, why is OPP code so complex, but I’m using all the Arduino framework, and a black pill)) but these features aren’t supported in MPF as of this moment. (Heck, Jan doesn’t even know about them unless he reads the blog). He mentioned half a year ago that it would be easy to support incandescent lamp intensities. I assume that also applies to supporting incandescent fading. The active low switch matrix should be very simple for MPF to support. Hopefully a kind soul will add the MPF support for these features.

1/17/2021 – Cobra’s Kickstarter

Cobra18t on pinside has produced an “all in one” board for controlling pinball machines. OPP was originally envisioned as a distributed pinball controller to reduce wiring and such. Of course, many people have playfields out there that they don’t want to rewire. (When the Dolly Parton machine was converted to Van Halen, all of the controller cards were placed in the backbox so no wiring changes were needed on the playfield).

Many people have asked for a single card solution to control the whole pinball machine that would live in the backbox. Many people have also asked for a solution where they don’t need to solder their own cards. OPP was always meant to be the rock bottom cost-wise solution and people would need to add a little sweat to make it work.

Cobra18t has decided to take a different tact and produce an “all in one” card (the Cobrapin) that sits in the backbox. It has many surface mount components that make it more manufacturable. The project combines what is needed to drive a pinball machine into a single card and it is pre-assembled. It is essentially two STM32 processor cards with six solenoid wings, an 8×8 switch matrix, and two Neopixel wings. (Strangely, it is only now, after writing that sentence, that I remembered he asked me to support a Neopixel solenoid which converts one of the direct inputs into a Neopixel driver. That makes a lot of sense looking at his board). It also adds the bulk capacitors for the power supply filter board (and even a fuse!).

Cobra18t has already spent a lot of time testing the board and has done a really good job of making sure that the parts are robust enough to drive a pinball machine. (I believe he is on his third revision) If you search around, there is a video on his youtube site where he is driving all the solenoids very quickly and he measures the temperature rise to make sure it can handle the thermal load. Great stuff. He and Jan were also instrumental in testing the OPP Neopixel support, including the aggregation of fade commands. At this point, I feel the OPP Neopixel support is better than any other MPF supported Neopixel driver. Without their help and testing, the OPP firmware would not be as robust.

At this point, cobra18t is going to make his goal. (He is currently at $5800 with a goal of $1000). If you are looking for an inexpensive controller that doesn’t involve soldering a whole bunch of wing boards and programming the firmware, this might be a good option for you. Here is the Kickstarter link: https://www.kickstarter.com/projects/1862357036/cobrapin-pinball-controller

11/3/2020 – Loading STM32 Firmware

Well, for a long time, I’ve been referring people to a random YouTube video that tells them how to install firmware on a STM32. That seems both inadequate and relatively lazy on my part. I’ve been meaning to write down a little bit more detailed instructions, so here they are. The instructions assume using a ST-LINK V2 to program the stm32f103c8t6 blue pill board. So without further ado, here we go.

Linux (Ubuntu) Instructions:

Install required software:

1. Install libusb and git: sudo apt-get install libusb-1.0-0-dev git
2. Move to home: cd ~
3. Grab stlink code: git clone https://github.com/texane/stlink
4. Move into stlink folder: cd stlink
5. Build stlink: make
6. Copy binary to /usr/bin: sudo cp build/Release/bin/st-flash /usr/bin

Attaching the debugger and programming firmware:

1. Connect the four pins at the edge of the stm32f103c8t6 to 3.3V, SWD, SWCLK and GND to the pins on the ST-LINK V2
2. Move the Boot0 jumper from position 0 to 1
3. Plug the ST-LINK V2 into a USB port
4. Program firmware (firmware is found at repos/Stm32Workbench/Gen3Images): sudo st-flash –format ihex write OppStm32.2.0.0.6.hex
5. After programming is completed (printing out Jolly Good!), unplug the ST-LINK V2 from the USB port
6. Move the Boot0 jumper from position 1 to 0

Verify firmware version:

1. Plug the stm32f103c8t6 into a USB port
2. Run Gen2Test.py (Gen2Test is found at repos/Python/Gen2Test): sudo python Gen2Test.py -port=/dev/ttyACM0

Note: Gen2Test.py may need to be run a few times to “sync” the serial port because plugging in the USB port may send garbage on the serial port.

Windows Instructions:

Install required software:

1. Download STSW-LINK004 from http://www.st.com: https://www.st.com/en/development-tools/stsw-link004.html
2. Run setup.exe found in the zip file. This will install the STM32 ST-Link Utility

Attaching the debugger and programming firmware:

1. Connect the four pins at the edge of the stm32f103c8t6 to 3.3V, SWD, SWCLK and GND to the pins on the ST-LINK V2
2. Move the Boot0 jumper from position 0 to 1
3. Plug the ST-LINK V2 into a USB port
4. Run STM32 ST-Link Utility
   1. File->Open File and browse and select firmware file (firmware is found at repos/Stm32Workbench/Gen3Images)
   2. Target->Program and Verify
5. After programming is completed, unplug the ST-LINK V2 from the USB port
6. Move the Boot0 jumper from position 1 to 0

Verify firmware version:

1. Plug the stm32f103c8t6 into a USB port
2. Run Gen2Test.py (Gen2Test is found at repos/Python/Gen2Test): c:\Python27\python.exe Gen2Test.py -port=COM3

Note: Gen2Test.py may need to be run a few times to “sync” the serial port because plugging in the USB port may send garbage on the serial port.

Ending Comments:

That’s it. Hopefully these instructions are a little bit easier than doing a bunch of web searches and sussing out which instructions are applicable to your situation.

4/29/2020 – Fantastic new illustrations

So, as stated in my last blog entry, my photos stink.  I apologize for that, and since this is essentially a technical blog, I don’t go out of my way to make them any better than they happen to turn out.  (I don’t have a particularly nice camera, and much to the chagrin of my wife, really don’t care.)

I’m sure that anyone who is a graphic designer cringes at those images.  Luckily enough, somebody was so distraught by the photos that they decided rise to the occasion offer up some help.  My deepest thanks to Adrien A-G for providing these much clearer illustrations.

 

The first image shows the changes that need to be made to support all four wing boards fully.  The second image shows a Neopixel as wing 0 (all unused pins are configured as direct inputs), solenoid as wing 1, input as wing 2, and SM incandescent board as wing 3.  The last image shows a solenoid plank board being used in wing 2 and wing 3 positions.  As noted earlier, plank boards cannot be supported in wing 0 and wing 1 positions because of the USB bus pins that split the two wings.

The only final caution that I need to add is that the serial LEDs usually expect a 5V control signal level.  To work properly, I have found that I need to use a 3.3V to 5V converter on the PB15 pin so that the serial LEDs can be driven as brightly as possible, and the control of the LEDs work perfectly.

Thanks again, Adrien A-G.  I would like to say that I will try to make better illustrations, but let’s be serious, you can’t teach an old dog new tricks, and I’m just too darn old.

4/5/2019 – STM32 Firmware Complete

The STM32 firmware is now fully functional, tested and complete.  Special thanks to both Jan (for MPF support) and Cobra18t (for helping test).  Both helped immensely during the change from the PSOC4200 to the STM32.  The firmware is released at version 2.0.0.2.

An added bonus is now MPF is able to use serial LEDs (Neopixels) driven by OPP, and in any configuration such as GRB, RGB, GRBW, RGBW.  This should be a much cheaper alternative than the FadeCandy option if you are trying to build your own low cost homebrew machine.  From my non-extensive research, the OPP serial LED support should require much less processing than running the open pixel server.  OPP supports over 230 LEDs per STM32 board.

The information on how to attach wing boards to the STM32 was scattered over multiple posts in forums, so I’m going to try and aggregate it here so I don’t have to keep searching for it when I need it.

These pictures are great examples why I should never be allowed to take pictures.  Look how blurry!  I guess nobody subscribes to this blog because of the desire to see the crispest pinball photos.  Hopefully they get the point across.  There is a lot of good information on these two pictures.  They show the positions of each of the wing boards with respect to the STM32F103C8T6.  Note in particular the two pins that are left blank between wing 0 and wing 1.  These two pins are used by the processor for USB communications.  This is why plank boards can not be used on the wing 0/wing 1 side of the processor.  The picture also shows that a wire must be added between PA13 and wing 0 pin 0 to fully support the wing 0 board.

Jumping to the back side, wing 2 requires the most aggressive modification.  The VB pin (battery voltage) has a trace that goes to the top right pin in this picture.  That trace must be cut.  When I cut traces, I make two separate cuts in the trace, then use an xacto knife to remove the copper trace between the two cuts.  That is very easy to do in this case, and it guarantees that the trace has been fully cut.  Last thing is to add a wire from PA14 (SWCLK) to the top right pin.  Now the wing 2 is fully supported.  The second picture shows the wing 0 modification from the bottom.  I chose to do that modification on the top of the board, because it was easier with my soldering skills.

One final note.  When using wing 2 and wing 3 as a switch matrix, wing 2 must be the switch matrix output (i.e. control signals to drive the switch matrix), and wing 3 must be the switch matrix inputs.  This is because of the LED (attached to PC13) which is populated on the board.

Keep your social distance by building your own personal pinball machine.  Keep safe!

1/12/2020 – Wayyy Too Lazy

Mostly my fault, but I just haven’t felt like writing anything on the blog lately.  Every once in a while, I think to myself that I really need to update the blog so people know things are occurring, but then I decide to go work on something else, and the blog is forgotten again for another month.

Here is the current status:  OPP firmware has been moved from the PSOC4200 to the STM32 and everything that MPF supports is supported by the new firmware.  Regression tests have been run, and so all past functionality has been verified including switch matrices.  (Those were the tall straw that ended up taking the longest because the newer processor is significantly faster and thus the capacitance of the inputs for a switch matrix needed a little help.)  All the new code is in the repository so version 1.0.1.3 should be fully qualified.  Thanks for the big help from cobra18t for helping me test the switch matrix stuff.

After finishing that up at the beginning of January, I started talking to Jan about what is the best interface to support for MPF and Neopixels.   After a little bit of discussion, I feel that I have a small efficient interface that should work well with how MPF wants to send updates to a pixel controller.  That is work that is on-going, and even if I finish the firmware, it will still be a couple of weeks until the interface to MPF is finished.  (OPP PSOC4200 boards supported Neopixels, but I never wrote the interface necessary to make it work seemlessly with MPF.  I’m now making a concerted effort with the STM32 because I feel it has the bandwidth necessary to make that interface work well.)

The STM32 processor is cheaper than the PSOC4200 processor boards, and all of the wing boards work with the new processor without any modification to the wing boards.  (That was one of the main design goals).  The plank boards can only be used on the left side of the processor because the USB to serial port takes the center two pins on the right side.  Cobra18t has boards that can convert from a STM32 to the same form factor as the PSOC4200 so those small breakout boards could be used.  (Contact him on pinside if interested.)

Here are the two main threads in the MPF user group discussing the updates to OPP, testing, and where it is going next:

https://groups.google.com/forum/#!topic/mpf-users/QVQsO6JjID8

https://groups.google.com/forum/#!topic/mpf-users/MCgyK–Hfpk

That’s all I have for tonight.  Just got the DMA running properly to update the NeoPixels, but haven’t verified the output yet to insure the pixels are being lit properly.  That will probably happen in the next few days.  Hopefully in the near future OPP can provide a cheaper way to use pixels without the expense of the current offerings.

9/6/2019 – Discussion on future of OPP

A discussion topic on the future of OPP and what the next steps are has been opened in the MPF User’s forum.  It was opened there because my guess is that the majority of the people using OPP to build pinball machines are also using MPF.  If interested in adding to the discussion, here is the link.  The discussion focuses on whether it makes sense to transfer the firmware onto the STM32F103 processor and continue to be a distributed solution, or would does it make more sense to create a more centralized solution.  All pertinent comments are welcome.

8/27/2019 – Oh no…the Fatal Flaw

Alas, there was one fatal flaw that could deal a harsh setback to the OPP project.  What could it be you may ask?  It is simply that the PSOC 4200 developer boards that OPP requires stop being manufactured.  As you probably know, OPP uses the CY8CKIT-049-42xx development board as the main processor.  Cypress, without notification, seems to have discontinued manufacturing the development board.  Let’s look at this quick link from Cypress that was updated on 6/26/2019, yet fails to mention that the boards are not going to be produced anymore.  Mouser lists the board as obsolete.  There are a couple available on Ebay, a couple available on AliExpress, but as of this moment, I can not find a “supplier”, i.e. a person that could sell ten of these on demand.

The most annoying part of this is that I was not notified by Mouser, Cypress, or the different distributor channels.  I get a few emails every year saying that this part has been changed, this part has a last time buy, etc.  There were absolutely no notifications received about the developer board going obsolete.  (It might be because Mouser only notes obsolescence with individual chips, and not developer boards, falsely assuming that projects are not using the whole developer board as part of a larger build.)

So first things first.  What if somebody gets caught out without having the PSOC cards that they need to create their dream pinball machine?  At this point I have six CY8CKIT-049-42xx in the stock room (i.e. my basement).  Contact me if you need a board and I will get it to you until my supplies run out.

Going forward, that won’t work, so what is next.  Somebody pointed out that I should look at the STM32F103 development boards that came out a couple years ago.  After a little bit of research, it seems that the boards are already being produced in China, and the Arduino code base has been ported by a few people.  Arduino only really matters to me because I feel it will guarantee that the board will be produced for a longer period of time.  I don’t want to be caught in the lurch again trying to move all of the firmware to yet another processor.  (That would be the third because OPP originally started on HCS08 based processors, then moved to PSOC 4200, and now it looks to move to STM32 based processor).

A quick look at the pinout of the stm32f103c8t6 board (hellishly known as the “blue pill”, don’t search on that), it seems that I can come up with a way to support the wing boards without any modifications.  There at least seventeen inputs/outputs on the left side, and fifteen inputs/outputs on the right side so I may need to describe moving a wire for an input from the left side to the right side.  (That is unless I can figure out a way to make the NRST a generic input/output pin which may be impossible).

There are some good points to the new processor.  The stm32f103 supports a USB virtual com port.  That will significantly increase the bandwidth for communications to the board.  It should remove the need to daisy chain boards, and a simple USB hub should suffice to talk to multiple cards.  While that increases wiring between the main processor and the individual controlling cards, it will make communication much simpler.  The processor itself is much faster, and has much more memory.  The USB stack will eat up a good portion of that extra memory, but on the balance, there should be plenty leftover for pinball.  Last change is that the outputs are only 3.3V as opposed to 5V.  Shouldn’t be a problem for solenoid control since the threshold voltage of all the MOSFETs are well below that level.  Switch matrices should work properly, but that would be what concerns me the most.

Two weeks ago, I bought a couple of the STM32F103 boards, and installed all the tools to start programming the boards.  I got three boards, and the ST-LINK V2 programmer for $11.49 from a guy out of Ohio.  It was a buck or two more than from AliExpress, but got here in about a week as opposed to a month or two.  The STM32F103 boards go for about $1.70 on AliExpress which is significantly less than the $4 price that the CY8CKIT-049-42xx used to be.  As I progress and move the OPP code over to the STM32F103, I will post updates.