(Topic ID: 180269)

Announcing Stern SPIKE support for the Mission Pinball Framework


By jabdoa

3 years ago



Topic Stats

  • 93 posts
  • 25 Pinsiders participating
  • Latest reply 89 days ago by jabdoa
  • Topic is favorited by 32 Pinsiders

You

Linked Games

Topic Gallery

There have been 5 images uploaded to this topic. (View topic image gallery).

IMG_20171123_110044 (resized).jpg
IMG_20171112_190516 (resized).jpg
IMG_20171110_143314 (resized).jpg
IMG_20170511_201216 (resized).jpg
IMG_2195 (resized).JPG

There are 93 posts in this topic. You are on page 2 of 2.
#51 2 years ago

That is helpful Jan! Sorry to have so many questions...

Is there a FTDI chip in the black cable?
When you say 2 FTDIs you mean one in the cable and another on the little PCB adapter (HiLetgo FT232RL FTDI USB to TTL Serial Converter)?
Are you switching the RX and TX with the connecting wires in between?

Thanks

#52 2 years ago

Yeah the cable includes an FT232RL and the other one is some random CP232 based usb serial. And yes RX and TX need to be twisted (see: http://docs.missionpinball.org/en/latest/hardware/spike/connection.html#connect-using-two-usb-serial-adapters).

Jan

#53 2 years ago

So what would be a good option to purchase for a DMD or an LCD that would fit a spike machine like KISS? What additional hardware is needed to control the display? Is there anyway to control the native DMD from the PC with an additional controller?

Thanks

Tim

#54 2 years ago

Wow! I just came across this thread. Nice work I will certainly be keeping an eye on the progress of this. Well done

#55 2 years ago

konjurer We could control the DMD from MPF using the SPIKE CPU board. Unfortunately, the serial bandwidth is a bit too low to reach a good frame rate. We should be able to reach about 5-10fps with some tuning. Same applies to audio. We know how to use it but serial is not fast enough.

There are certain options around this but they require more heavy lifting in SPIKE 1:
1. USB client mode (10MB/s+). Hardware supports this. Unfortunately, no driver in SPIKE 1. We did some limited testing with OpenEmbedded but did not fully get it working. But should be possible. Also needs a custom cable because there is only USB A on the board.
2. Native Ethernet. CPU and image support that. However the PHY + Connector are missing. Should be possible to buy but requires advanced SMD soldering skills. Therefore not very practical.
3. USB ethernet. Works in OpenEmbedded (our custom image). Not sure if this works in SPIKE. Might be possible if we find an adapter with the right chip.
4. Crank up serial baudrate. Might work with a FTDI and should be enough for the DMD but not for audio.
5. Run MPF on SPIKE 1. Tried that. Kind of works with our image. Install needs 7h (for pip to install all dependencies). Should work but it is very little fun during development.

SPIKE 2 comes with working ethernet so this should be much easier there. Additionally, the CPU is much stronger so MPF should also run pretty well natively.

There are certain options to control the DMD. One would be to use a Teensy (~$35) with Eli's firmware: https://github.com/ecurtz/RGB_DMD. For Audio you can just use the sound output of your PC. LCD also works. Just use any of your choice. MPF offers a variety of options.

Jan

#56 2 years ago

Spike2 comes with working ethernet?

#57 2 years ago

greatbug afaik yes. From everything i have seen it seems to be populated and the cpu card definitely supports it. I do not have any spike 2 yet so i did not investigate the software side yet.

If anybody wants to get rid of a spike 2, please PM me (or for a good price or borrowed). I would like to play with that and get it fully supported with MPF. Currently this is completely untested on spike 2. We believe that the bus protocol is mostly the same so getting MPF running should not be too hard. But testing and documentation would certainly make it easier for others.

Jan

2 weeks later
#58 2 years ago

Just a small update: With the help of konjurer we worked out a way to get this running without any hardware mods. You need a SD card reader and two FTDIs which can be bought for less than 20 bucks.

Furthermore, we got it working on konjurer's KISS machine. Had to work out some timing issues and improved some of our hardware rules. As a result the timing of the operating system no longer matter (within reasonable bounds obviously) and it also works on Windows where serial and/or USB timings are somewhat worse than on Linux. Thanks to konjurer for finding out how to use it on Windows and testing all the code.

Jan

#59 2 years ago
Quoted from jabdoa:

Just a small update: With the help of konjurer we worked out a way to get this running without any hardware mods. You need a SD card reader and two FTDIs which can be bought for less than 20 bucks.
Furthermore, we got it working on konjurer's KISS machine. Had to work out some timing issues and improved some of our hardware rules. As a result the timing of the operating system no longer matter (within reasonable bounds obviously) and it also works on Windows where serial and/or USB timings are somewhat worse than on Linux. Thanks to konjurer for finding out how to use it on Windows and testing all the code.
Jan

So you're telling me that I can completely re-theme a Stern SPIKE machine with nothing more than two FTDIs and an SD card reader?

Thats awesome! #MacGuyverStyle

#60 2 years ago
Quoted from Compy:

So you're telling me that I can completely re-theme a Stern SPIKE machine with nothing more than two FTDIs and an SD card reader?
Thats awesome! #MacGuyverStyle

You still need a PC to run MPF. You could run MPF on Spike as well but it would be pretty slow and not fun for development at all. This might improve with Spike 2 which has a more powerful CPU. Currently, you can use Spike 1 like a P-Roc in a WPC machine.

#61 2 years ago

Thanks for the kind words jabdoa but you did the heavy lifting! I hope I get a chance to buy you a beer sometime.

Yes, my KISS Pro is flipping from my laptop code and running on the Mission Pinball Framework. Boring as hell to play so far but all of the coils are working and I can play a 3 ball game with crude scoring.

I've already started designing new modes on paper and my brain is buzzing with lots of cool ideas. I'm many months away from anything remotely resembling a complete game.

Mission Pinball is freaking amazing!

#62 2 years ago
Quoted from konjurer:

Thanks for the kind words jabdoa but you did the heavy lifting! I hope I get a chance to buy you a beer sometime.
Yes, my KISS Pro is flipping from my laptop code and running on the Mission Pinball Framework. Boring as hell to play so far but all of the coils are working and I can play a 3 ball game with crude scoring.
I've already started designing new modes on paper and my brain is buzzing with lots of cool ideas. I'm many months away from anything remotely resembling a complete game.
Mission Pinball is freaking amazing!

Which is awesome! So the big question, what are you going to have the cities do?

#63 2 years ago
Quoted from desertT1:

Which is awesome! So the big question, what are you going to have the cities do?

I'm really excited but keep in mind that I'm not starting from the current KISS code. I'm starting from the ground up. Just getting KISS Pro to basic flip was quite a bit of work; although Jan has made great progress for future SPIKE owners.

There are no inserts on the playfield for cities so is it worth pursuing the cities? Not sure yet. I'm planning on going a different direction than the current modes. Right now, it's just a proof of concept. And as a proof of concept, we now know it can be done on KISS and other Stern SPIKE systems! We'll just have to see how far we can take it with MPF. Mission Pinball is a very important tool for the pinball community and I can't thank them enough.

#64 2 years ago

Great news! Is there updated documentation on this detailing what you guys have found? What's the SD card reader for? Or is this just so you can write the software to an SD card for use with the Stern CPU card?

#65 2 years ago

The documentation is still mostly the same. You can find it at link from the first post: http://docs.missionpinball.org/en/latest/hardware/spike/index.html.

Jan

1 month later
#66 2 years ago

Quick update. I've been working with MPF two months in my spare time. I'm still a long ways away from a complete game and solution (audio, LCD etc.) but what you can do with MPF is nothing short of amazing. Some days, it is very frustrating to solve problems with MPF but the guys that develop MPF (Jan, Brian, Gabe and Quinn) are super responsive and there is no doubt that anyone can built a commercial quality game using MPF.

Although I'm not ready to implement these things, my big concern for the future "complete solution" is what computer to place inside the cabinet (Raspberry Pi or PC) and what to use as a display. I think I'd like to put a color LCD in but if I could reuse the DMD, that would be the first option. And then what to do about audio. Again, I'd like to use the Stern hardware but so far that is not an option with MPF.

I'd eventually like to share this with other KISS owners but it has to be a complete solution that would work for everyone. Ultimately, if I could just plug in a Raspberry PI with the software loaded and it used the rest of the Stern hardware, that would be nirvana.

#67 2 years ago

Thanks for the kind words. As for a computer you might use an Intel NuC or any small embedded system. RPi3 might work with some additional tuning but it ain't much fun to work with

I want to play some more with the build in DMD. With a ftdi to ftdi usb cable chain we might be able to get this working at around 3MBaud which should be sufficient for 30fps. Would need some experiments to see if we can multiplex it one the same chain as the bus or if it needs a second chain. But i think this could work.

For sound, we added support for external sound cards in solid state machines (in MPF dev/0.50). This would allow us to implement Spike as an external soundcard as well, put all the sounds on the SD-card and play them on the CPU. However, this interface is very basic and would lack a lot of features such as ducking or crossfade. So while this will work, it would sound worse than our built-in sound system which allows more commercial grade sounds.

Jan

#68 2 years ago

Jan, as a PC/FAST user, one thing I am struggling with is being able to power up and have the PC go straight into the game. I think a Pi would maybe be able to do this, but I am nowhere near capable of finding out. Either way, I think powerup/powerdown might be the only real hurdle an MPF machine has to get on location.

#69 2 years ago
Quoted from desertT1:

Jan, as a PC/FAST user, one thing I am struggling with is being able to power up and have the PC go straight into the game.

There are different solutions for this and they highly depend on your operating system. We can discuss that in another thread or in the MPF forum (https://groups.google.com/forum/#!forum/mpf-users). The installation section of the manual covers RPi3 and Xubuntu currently (http://docs.missionpinball.org/en/latest/install/index.html). There is a window solution for sure and we should probably add it to the documentation as well (Pull Request welcome - you can click "edit on github" on top of every documentation page and submit changes). Probably best to ask in the MPF forum because there is sure somebody using your platform which can help. We can improve documentation afterwards. I guess it would be a good idea to create a section about this in the "Running MPF" page (http://docs.missionpinball.org/en/latest/running/index.html). But please don't derail this thread and create a new one.

Jan

1 month later
#70 2 years ago

If you are a spike MFP user you probably had to assemble a FDTI to FTDI connection using duct tape and chicken wire. Well no more! I've found a company that makes and USB null modem cable. I took a chance and ordered one of these cables in hopes of having a clean, reliable cable.

http://www.ftdichip.com/Products/Cables/USBtoUSB.htm

Just got it in today. At first, no luck and I was worried that I had misspent $50. However, it was just selecting a different COM port than I had been using before. Changed the config setting to COM5 and it works! Looks like a standard USB cable but has an FDTI chip in both ends and the RX/TX connections are crossed in the middle.

Tim

#71 2 years ago

Sweet! According to the datasheet it transfers up to 3Mbaud/s. That should be enough for some DMD frames. Maybe not 30fps but at least 15-20fps. Depends on color depth and some other factors. We can probably really make this work. 3M should also still work with 2 connected FTDIs over few cm. I suspect that your USB adapter can even achieve higher rates in practise (more like 6-10M).

I guess we should add this adapter to the documentation as well.

Jan

#72 2 years ago

That would be sweet to work with the DMD. How would sound work with the spike? Anyway to use the internal audio?

I'll add the FTDI cable to the documentation.

#73 2 years ago
Quoted from konjurer:

How would sound work with the spike? Anyway to use the internal audio?

We know how audio works at the CPU. Basically, it is a ordinary sound card like on your PC. Then there is an amplifier embedded on the board which is controlled using GPIOs and we mostly know how that works. We just do not have the bandwidth to stream audio over serial. It would be possible to put mp3/wav files on the SD card and trigger them over the serial. Similar to how system11 works. Unfortunately, this would also break modern features such as tracks and ducking.

Quoted from konjurer:

I'll add the FTDI cable to the documentation.

Thanks! Merged it.

Jan

#74 2 years ago

I 100% agree with the method of having the core code / framework running on a host controller and then just using a bridge to different hardware. This way you can keep the host environment the same and support endless amounts of hardware with a simple custom bridge. Absolutely the correct way of solving this problem! keeps all your options open! To develop the host to run on the actual hardware would be a complete nightmare (for every bit of hardware) and in most cases not even possible! (even though it is very cool it can actually run on the spike cpu it self)

Regards
Russell

#75 2 years ago

Pros and cons of course. I do want to use a LCD and have other HW options but I would also like to share the fruits of my labor with other spike owners. Therefore it would be nice to make it easy for an owner to who Is unlikely to buy and install all components required to use my code. I'm kind of torn between making a one-off for myself and doing something that is easy for other KISS owners to use.

#76 2 years ago

Reading the docs it could be as simple as just installing a cheap raspberry Pi?

#77 2 years ago
Quoted from russdx:

Reading the docs it could be as simple as just installing a cheap raspberry Pi?

Works but it has limited GPU power. Audio output is not that great without additional hardware. Probably requires substantial tuning effort and maybe even some graphical tradeoffs. RPi3 with just the DMD might work.

Other mini pcs exist for around 100 bucks without those limitations. TNA uses one of those for example.

#78 2 years ago
Quoted from jabdoa:

For sound, we added support for external sound cards in solid state machines (in MPF dev/0.50). This would allow us to implement Spike as an external soundcard as well, put all the sounds on the SD-card and play them on the CPU. However, this interface is very basic and would lack a lot of features such as ducking or crossfade. So while this will work, it would sound worse than our built-in sound system which allows more commercial grade sounds.

I'd personally consider any audio solution that didn't include ducking to be so inferior as to be useless, it's a pretty essential aspect of basic sound design for a pin.

#79 2 years ago

Yes I agree. I'm already using ducking extensively. MPF has a solid set of tools for mixing channels and ducking. Essential for a rock pin.

#80 2 years ago
Quoted from Aurich:

I'd personally consider any audio solution that didn't include ducking to be so inferior as to be useless, it's a pretty essential aspect of basic sound design for a pin.

I totally agree. We will only implement this if somebody wants to use it so probably never for SPIKE.

There might be a chance to run a stripped down MPF media controller on the SPIKE CPU. Basically, one would have to remove all kivy (and openGL) stuff which would not be trivial. We might decouple graphic and sound in a future MPF-MC release because there is only one reason that they have to share one process (that is video audio but it might be possible to stream that between processes using gstreamer). If that happens this will become more straightforward. Still, developing on the SPIKE CPU is not that much fun (because it is pretty slow). So you would probably develop on your PC (like Tim does) and then move it to SPIKE when it is done. Maybe MPF will support that by that time (any contributions welcome).

Jan

1 month later
#81 2 years ago

Started DMD support today

IMG_20171110_143314 (resized).jpg

#82 2 years ago

Images with grayscale are also working. Currently about 1fps at 115kbps. We should be able to get 30fps at 3M which should work fine with the hardware. If we improve the encoding a bit even 500kbps should be enough but some headroom would be better.

IMG_20171112_190516 (resized).jpg

#83 2 years ago

I investigated this with a logic analyser today. Our frames look very similar to the ones SPIKE generates which is good. There are two ways this could work:
a) Using the same serial as the bus at 3MBaud. That will practically allow more than 30fps but also introduce some jitter. With current encoding one frame should take about 16ms so you could miss any switch hits below 16ms. With improved encoding we could push this down to 5-6ms which would be probably fine.
b) Using two USB-Serials. That DMD would be a separate independent serial. This would be the best way but also requires more USB serial cables.

SPIKE DMD Support is in latest dev/0.50 and 0.33.39. Give it a try.

Jan

#84 2 years ago

Very cool. I'll give it a try this weekend.

Thanks Jan!

#85 2 years ago

Forgot to mention that you also have to pull the latest mpf-spike-bridge. Otherwise the CPU will not understand the commands from MPF. Consider this a bit of a PoC. We probably have to enable flow control and use a separate sending thread in MPF when sending at 3M.

Jan

#86 2 years ago

Sorry for the noob question, but does the spike system use a standard RGB LED matrix display, or is it a stern specific display? (typical signals for RGB LED displays are R1, G1, B1, R2, G2, B2, A, B, C, D, Strobe, and clock). I bought a bunch of those displays for the kids for christmas and accidentally (hehe) ordered an extra that might find its way into a pinball machine at some point. I also know somebody has written some sort of MPF to that type of interface, but haven't really dug into it yet. (It is about 20 projects from the top of the pile). I have absolutely no idea how MPF interfaces with displays in reality. Thanks in advance for any info.

#87 2 years ago
Quoted from openpinballproj:

Sorry for the noob question, but does the spike system use a standard RGB LED matrix display, or is it a stern specific display? (typical signals for RGB LED displays are R1, G1, B1, R2, G2, B2, A, B, C, D, Strobe, and clock).

It is a LED matrix (not RGB). They still stick to the old WPC Plasma DMD interface. At least the physical wires are the same. However, timings and maybe also signals are slightly different than WPC. Nevertheless, that does not matter for MPF because we just feed a Cortex M0 on the Stern CPU board from the CPU via SPI. The Cortex M0 drives the DMD for us and we only need to send it the right frame format.

#88 2 years ago

So is it a simple bit per pixel framebuffer, and then to get grayscale they oversample? So it is 128x32 resolution = 4096 bits of raw data per frame. Assuming 32 fps it is 128kbps. Stern says it is 16 shades of grayscale, so assuming you can correctly time it is 2 Mbps for the raw frames. If the Cortex M0 keeps the last framebuffer sent to it, and just replays it, it would take significantly less bandwidth. (It would be even better if they just encoded 4 bits of grayscale into the framebuffer, and then it would only take 16384 bits for a whole frame.) Of course, that would never be backwards compatible to the old DMDs that don't have a microprocessor on them which is probably the real case. Thanks for the info.

#89 2 years ago

Spike generates four frames (4*4096bit). Brightness increases exponentially for the four frames and thereby realizes 16 grayscale (4bit not 16bit). Different brightnesses are signaled by different pulse length on the enable line. Very similar to how DMDs worked previously in WPC and SAM. The Cortex M0 buffers those four frames. For 30fps we need roughly 500kbit/s (four frames are 2kb).

Older DMDs also needed some controller to refresh them constantly. Guess this did not change much with LED DMDs. If you want to drive your panels you can have a look at Eli's RGB.DMD project (we support it as smartmatrix in MPF): https://github.com/ecurtz/RGB_DMD.

#90 2 years ago

Now I understand. I drive my RGB LED panels using a raspberry pi zero, and end up using this project: https://github.com/hzeller/rpi-rgb-led-matrix. (Of course, that isn't for a pinball project, it is simply for panels that display pictures). With your bit rates and explanations, it made it much easier to understand how DMD displays are being driven underneath the covers.

#91 2 years ago

Quick chime in that I put my GB next to my road kings p-roc project so I can start messing using the one CPU while I experiment! Thanks mpf!!!

IMG_20171123_110044 (resized).jpg

#92 2 years ago

I tried flow control with Spike. Definitely makes it more robust (otherwise the bus sometimes desyncs because of transmission errors). For this you have to connect RTS to CTS and CTS to RTS on the FTDI/USB serial. This is currently enabled in dev (should work without but with errors). On the Spike it has to be enabled in inittab (i will update the documentation). I guess that those null modem cables have those problems pins connected.

Let me know if you got this running. We can then increase the speed and get it working at proper baud rates. There is a lot of room for improvements in software so don't worry if it is lagging right now.

Jan

2 years later
#93 89 days ago

Just a small update: Spike System 2 (Firmware 0.49+) also works in MPF (0.53/dev) now. We also added steppers and servos in the meantime. Overall, everything got a lot more efficient and should not lag anymore on a fast serial (tell us if it does for you). On Firmware 0.49+ we support variable debounce times and coil priorities. Let us know if you miss anything.

Promoted items from the Pinside Marketplace
Wanted
Machine - Wanted
Cortland, NY
$ 25.00
Cabinet - Other
Pin Monk
There are 93 posts in this topic. You are on page 2 of 2.

Hey there! Got a moment?

Great to see you're enjoying Pinside! Did you know Pinside is able to run thanks to donations from our visitors? Please donate to Pinside, support the site and get anext to your username to show for it! Donate to Pinside