2/2/2016, MPF interface…duh, duh, dun, done!

As I write this, the OPP platform interface to MPF is done.  It went rather well despite simply reverse engineering another platform interface.  A couple new commands were added to the board interface to make talking to MPF a lot simpler.  These include setting all incandescent bulbs as either on or off in a single command, updating an individual solenoid configuration, and updating the color on a single LED.  Easier to add those commands rather than trying to shoehorn the MPF to use the first version of the commands.

MPF works very differently than the OPP pinball framework.  OPP framework gathers all the updates to incandescent boards and configuration changes and sends them down to the card in one single command.  MPF wants to update solenoids one at a time.  This means the OPP framework is a little more efficient on the serial link, but moving to Gen2 the link went from 19.2 kbps to 115 kbps, so that doesn’t seem to be an issue.

I still have a little more work to do.  I need to add support for version 1 cards.  The only people who probably care about this are Cactus Jack, maybe Joe, and myself.  It is mostly for me and updating the SS3 pinball machine.  I’m too lazy to rewire all of the solenoids and inputs, so why not just use the old first generation OPP cards as they are, and simply add one or two cards to support incandescent bulbs.

That would make the upgrade to SS3 that much simpler (and forces me to finish the layout on the low side/high side driver card for bulbs).  Hey…Iteadstudio is currently having a 10% off sale.  That might put a fire under my butt to get it done by the end of the month.

Need to have an easy way to update OPP gen2 cards.  Right now, a user would need to download Cypress’ PSoC Creator, and download new code using that tool.  (That’s a 604MB download).  The bootloader protocol is documented by Cypress.  I found a version of cyflash which is supposed to do what I need, but of course it crashes immediately when trying to run it.  I have also found some C++ windows code that is supposed to implement the protocol.  I’m going to start by basing the updater of cyflash because it is written in Python.  That should be the simplest for people to use across multiple different platforms.

Advertisements

5 responses to “2/2/2016, MPF interface…duh, duh, dun, done!

  1. I think getting your hardware to work with a well known framework (even if yours is more efficient) is going to help sell the project. while the forums on MPF aren’t easily searchable (or aged) as PROC, the initial flipping with scoring and basic lighting / sounds within a couple hours is enticing when compared to PROC (even if PROC has more flexibility), especially with users that have never programmed before. Top that with a low entry price point and you might just get people to jump onto this hardware.

    • There’s that sell word again, Joe. There is no selling of OPP hardware. I give it away!

      I doubt I would have written my own framework, if there was another one available at the time. At the time I wrote that, there really wasn’t anything else out there. Like all software, there are some advantages to my framework, and there are some advantages to MPF. MPF does a lot of the grunt work for you. (i.e. I started up the test machine last night, and it complained that there weren’t any balls in the machine. In the OPP framework, that function has to be specifically programmed.)

      I’m not sure PROC has more flexibility at this point. From the looks of it, PROC provides a driver and an API so you can write code to drive their card. That is the same model that the OPP framework uses. By programming directly through the driver you get much more control over the machine, much better performance, and can do anything. The programmer makes all of the decisions. With MPF, certain things are easier because they are built in, while other things are more difficult because you are trying to work around the platform’s preconceived notions of what you should do. Neither way is necessarily better, they are just different.

      For making a game in the OPP framework you collect the drain events, keep track of the current ball, and when you get a drain on the last ball, the game is over. All those steps are well understood, and you have to write functions to do all that. With MPF all of that is built into the framework. The programmer doesn’t have to worry about it, which for the novice programmer, is a lot easier.

      One nice thing about MPF is that maybe it eases you into the programming. Yeah, you can get your machine running, but you are going to need to program in MPF if you have anything other than a trivial ruleset. The OPP framework (and how PROC seems to work) assumes that you know how to program, and you are comfortable with those concepts. Maybe MPF offers the bridge to help non-programmers get started.

  2. Thats awesome to here. Trying to finish reading my playfield so we should be moving ahead on my end this weekend!!

  3. Yeah, we need to talk a little bit more. I’m going to make another mouser order in the next couple of weeks because I’m out of the little FETs that I use to drive the incandescent bulbs. I can’t finish the SS3 rewire until I get that stuff. I could order your parts at that time.

    I think the only way to really fit the cards on that playfield is going to be to have them vertical. This is definitely one of those things that would be much easier if I could see the bottom of the playfield to see where things could go.

  4. Ok, Ill try to get a picture of it to you, I’m hoping to mount the thing in its new box this weekend

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