Operation Mother

So - finally got my greasy fingers around properly installing the motherboard inside the machine.

Still haven't got my opto's to work but at this moment I'll have to live without them. Will need to debug the circuit and possibly rebuild it separately in the future. 

Like most of the work on this build it's a bit of "one step forward, two steps back" since I was only going to screw the board to the backing plate. But... I forgot that the backing plate was made out of cheap fiber board so screws won't work - and - of course the cables didn't reach the intended position for the board.

So I did what any hobby engineer with(out?) self respect would have done; I cut a big hole inside the frame of the head.

This worked alright, but due to the placement of the intended cut everything turned out a bit crooked. Not that it matters much, since now it's done. But I know my future self will grin at this during any maintenance session, haha...

"Fun fact" - while checking out the playfield, it turns out most of the rubbers have cracked and need replacements. Again. But I guess I kind of was prepared for that and it'll have to wait until the game logic / game rules are completed and the machine is closed up properly.

Other than a few mishaps; the board is now installed and I didn't break anything in the process!

Installed and ready to be developed!

P.S, ignore the double vision display, there's
a small gap between the display and the panel at the moment. 

Holy optimizations, Batman!

Spent a "little" time optimizing the code base, along with actually trying to work out the kinks of why optimized mode doesn't work. I'm not all the way there yet, but the results so far are very nice! 

Note: The flickering apparent in both videos is mostly picked up by the camera only and isn't really noticeable IRL, and the refresh rate can be pushed up further. Just keeping it a bit "low" to avoid confusing myself while debugging the rest of the code in case it causes crashes/erratic behavior etc.

For instance - 

Here's a clip of SD-card videos running as fast as possible in the old code. 

Notice the slow motion (faked by frame-skipping previously, removed here). 

And here's the same clip after optimization. 

Compared to the old version, it's a lot smoother and I'm actually running the videos at 40fps here (faster than original 30). Notice the long blank space between the videos, where the old version barely finished rendering the first one when the second one was timed to start. :) 

Some crude counter increments:

Previous one-second count: 28402

New one-second count: 91857

Quite the improvement! 

Very satisfied with the results so far!

In case you didn't notice, I used two simultaneously running SD-animations (background & fx) during the second video. Works great and allows me to spice things up. #thumbsup 

And the cable mess have been mostly corrected now, all lights tested and working. :) 

A Ferrari-style pit stop!

Got around to do a little tinker on the board the other day!

* audience cheers *

First - had to recreate the development environment on my laptop. Took a little while, but well worth it in the end. And, naturally, the SD card for audio (and the reader) had given up and didn't work. (...sigh).  A purchase of a new reader and a format later solved that. No big deal. But annoying.

Still a bit of wiring to do, but slowly getting there!
Switches, flashers and global illumination is now done, and with a little luck I'm done with the playfield lights in the coming days (or so).

I knew about this before, but I may have to increase voltage for the lights. Currently 5V is a bit on the low side, as lights are quite dim. To avoid using a lot of constant power I also duty cycle the GI, so I figure 12V would be ideal here.

Luckily; there's not a whole lot that needs to be done - either cut the 5V traces and connect the existing 12V line, or move the drive cables to a 12V port on the board. This can be done "any time" so if the board feels too dim during actual play I'll adjust accordingly. :)

Stay safe!

Remembering The Past

Needed the soundboard from the "old system", so I opened up the pinball machine for the first time in a while... And I was actually surprised to see what a mess it was/is! It's a wonder it even worked at all, haha. :D

Anyhow -
It was quite satisfactory to see that where the old setup used tons of different boards, two MCU's and a cabling from hell, the new setup is ultra neat in comparison. And despite having "only" one MCU, the performance is 4x in most cases, but 200x when it comes to I/O. Hardware stability is improved a lot as well! I'm also pleased with the new code library compared to the old, which will make game programming a breeze.

The maintenance mode is always enabled, which gives me detailed input on sounds running, scenes started, sound and input / output etc - so I can see right away if there's a problem. Love it!

1) The old....monstrosity. This is actually HW3.0, if we're counting revisions.
HW4 (current) is seen in the post below, which despite being in development "mode", still looks tons better. 

Mostly Behind The Scenes

What is up, Internet!?

Most of the work at the moment isn't very visually interesting, but I'd thought I'd share a little snapshot of the current (messy) state of the debug screen. What I'm verifying here is that the various conversion and positioning functions are functioning properly. Which they are.

On top of this, I've fleshed out the switch callback handling, which includes buffered and queued switch hits. This allows the best of both worlds; the interrupt routine can register switch hits as fast as it can detect ( 1000+ > Hz per switch) while the game loop is chugging along at 40Hz. So no switch hits are missed, and the response for each hit is a maximum of 25ms late. Certain switches such as flippers, slingshots and bumpers are allowed to trigger the corresponding solenoid immediately and allow the sound and gameplay events to happen "later". It might be possible to queue sounds right away since the serial out is asynchronous, but I have yet to test this. What ever decision is made has to manage up to 8 simultaneous switch presses so each response must be pretty tight. I don't want the machine to run fine during single ball and crash during multiball etc. :)

I've enabled printing a copy of the internal switch matrix and the current animations, lights and so on in the console maintenance mode, which is guaranteed to be correct at all times unlike an offline version in Excel, for instance. On top of that I have started work on the state machine for modes and various scenes, so things are progressing nicely, albeit slowly!

1) Development board with debug options enabled on the DMD. I've also created a "overflow" function for scores,
so that any score larger than 999 999 999 will be visually divided by 1000 and rendered correctly. I believe this is how newer tables by Stern work, unless I'm mistaken.

Weirdness and wetness!

Spent some more time with the code and got dual animations on a single SD-card up and running!
It's an unlimited number really, but limited to two for performance. The theory is simple, since I'm not using a file system I simply load raw sectors and can grab any frame at will.

For simplicity and synchronicity's sake, I've decided to load SD-card animations with a blocking approach (as opposed to interrupt driven). This greatly simplifies things as I can keep the main loop/scene rendering to a single function instead of spreading out across several frames and wait for various inputs to complete etc. Since switch inputs and all I/O in general is moved outside the main loop, it doesn't matter really. I've locked the main loop to 40Hz which should be plenty for updating animated text, verifying animations and other non critical reasons. 

1) Basic render "geometry" examples with background animation, textlayer and front animation (layered above the text-layer).
The lower left are status flags for SD card, MCP, ULN etc. All 8 should be lit for a 100% functional machine.

The extra FX-layer really spice up the DMD, since I can overlay smoke, sparks and what not at will. I could also use two background layers, or two front etc.

I've also found a way to successfully detect if ULN and MCPs are functioning correctly, and can alert and disable features accordingly. I've completely lacked this troubleshooting feature previously, so this is a major leap forward.

I've also had the "joy" of realizing that the flash-burning sometimes fails, and that verification fails. It has been like that for a while, and I never knew why and it has "always" worked. But this weekend some simple code started to fail seemingly randomly and it basically boiled down to 'if verification fails, the upload isn't correct' after all. Usually a reboot or reselecting the toolkit in UECIDE allow me to upload successfully. As long as I know about the issue I can work around it. It wasn't exactly a straight path trouble shooting it though, since I both suspected that the DMD was broken. I took a rewrite of the routine in a new sketch to see that it was indeed working correctly. A new screen is _not_ something I want to buy at this stage...

But on the plus side the 13h+ troubleshooting made me rewrite SD card and DMD rendering routines, further optimizing them and avoiding unnecessary variable writes and operations. The downside is tough-to-read code, but once in place they won't change often (at all?).

So - three steps forward, one temporary step back.

ULN2803A!

1) Fully populated board with everything up and running. Since this is my first circuit board ever made
and my first venture into advanced electronics, I'm very proud to see it functioning properly!

Yes!
It was a broken ULN2803A that was the problem with the light matrix.
Very satisfied with that little bit of knowledge, as this now means that all parts of the hardware has been checked and verified. Now it's simply a matter of fine-tuning everything and create, solder and connect the final cabling.

Exiting times to say the least! :D 

DJ SD is in the house!

...SD card loading is in! 

The graphics library is still in its infancy, so there's no shadows etc. But all-in-all I'm pleased with the results!

1) DMD with SD-card loading (and displaying) demonstrated. The 16 shades shows the possibilities pretty good here,
with a dark big text in the background, several layers of graphics etc. Once shadows are in place it will be killer!

Get the jig' with it!

Not a "proper" update, really, but I've attached the PCB, screen and PSU to a spare piece of plywood which allows for easier handling and development. All necessary connectors are reachable as well, so I'll be able to hook up I/O and even solenoids to test things as well.

Since I am developing outside the box (no pun intended) this will help a lot to keep things tidy.

1) Piece of scrap plywood with components attached. Not much to say really. ;)

Pixels be rollin'...

It is with immense satisfaction the first few pixels has been drawn with the new motherboard!

Everything is very basic and the frame is currently hardcoded in 8 shades, but runs well in 16 as well (it's slightly difficult to see without having a proper image though). But it is running the new render routine with interrupt transfers and as a CoreTimer service.

1) Motherboard and DMD, sitting in a tree... The "pulsing" effect on top and bottom rows are simply
8 different shades being drawn. The timing of each color has not yet been adjusted and the screen overlay
is not in place either, which dims pixels and thus make each shade more pronounced.

I'll have to redo the main project file as well, as the one I did the PCB-tests on no longer works. I don't know why and haven't really investigated - now I can implement each section properly and without any guess work instead.

Next I'll get some basic DMD functionality in place before going on to other components.

"If normal at first, measure again"

So...
The board didn't work.

Or at least it didn't before.

My previous post was a false positive and everything started to behave really weird, with negative voltages and what not, as soon as something was connected and plugged in. The power switch was controlling a MOSFET, which in turn disconnected or connected all power lines to GND. For some reason the current flow was really wack because of this. For instance, inserting a LED in the 5V line really shouldn't reroute power from the 3.3V line and vice versa. This was a real pain to troubleshoot, but after butchering the board quite badly (#sadface) I ultimately found the problem (#happyface).

The solution simple enough - just bypass the MOSFET by shorting the drain and source. I really wish that I'd found this simple solution before massacring all capacitors. Now things are finally working correctly with the exception that I cannot turn power on and off with the switch, as I've hoped to do. But it's a minor issue and was more of a nice touch anyway, as it wouldn't be used in production.

1) Everything's looking dandy! For real, this time...

A major give-away, which I can't believe I overlooked, was that the status light previously didn't light up. It's directly connected to pin 13, so it should have blinked during boot. The fact that it never once did (before) would have told me that current was going the wrong way - or was insufficient. But I was simply assuming that I was shorting stuff when in reality it's perfectly fine to measure where and how I did. The wonders of stress...

Another issue leading to "premature optimization" was that I'm using an old Chipkit, which of course had some pins enabled that are now used for MOSFET control. This lead to having the light rows being always on for instance, but since they turn off during reset of the Chipkit they work perfectly fine.

Lesson learned? Don't put in untested parts in the schematics on the basis that "it should work, right?". The power switch was a last minute addition and a huge pain the Arizona.

Capacitors... Crap-acitors?

After investigating I think that the board actually might be working correctly after all (why do I sound surprised?).

A couple of issues -

* I have only tried to power the board via another ChipKit, since I haven't got a spare PSU. The only one I have is in the machine itself.

* The capacitors are "huge" and store a ton of energy compared to it's current consumption, which is more or less nil in its current state. This led me to think that the circuit was powered when not, and also the other way around - turning them on takes a while and is not instant.

* The SD-card reader draws quite a lot of power, and when it was connected (or possibly due to its connection with the ChipKit). Whenever the SD card was inserted, the 3.3V lane "died", i.e all power went to the SD card. As I said, it could also be that the ChipKit is trying to power itself from the SD card data lines etc.

* When attempting to read voltages I must have created a connection with the multimeter and supplying current instead of simply reading it.

So - I removed the SD card (temporarily) and powered up 3.3V and 5V simultaneously with a 3V battery pack. (not ideal, I know). And viola;

1) The connected power lines are active! #celebration
The LED's are protected with resistors for each voltage, so the 5V LED naturally looks dimmer. The green LED's are also diffused instead of clear, and of less brightness naturally than the power and status LED's.

The board look correct and both lines get power. Removing the SD card only instead of the whole connector also works, so there's no short circuit either.

Flipping the power switch to off yields this:

2) Everything is off!
Side note: The yellow capacitor on the SD is not connected to 3.3V and CLK, but 3.3V and GND. It just looks that way. :)

Which is exactly the way it should be - all lines are off!
When putting a LED in the 5V + GND sockets ("unconnected" test-areas) it properly lights up and turn off when supposed to. Only putting power on either line when the switch is off does not power up the LED over +5V + GND, just like it should.

So I'm thinking the capacitors are the main culprit, along with insufficient power to boot the board properly?

I guess the next step would be to arrange a PSU and proper power and take it from there. I'm still taking baby steps since I don't want to fry any components, worst comes to worst. :)

Trouble in paradise!

Still waiting for the final parts... but...

It seems there might be an issue with the power section.
It would seem that current leak from 12/5V into the 3.3V and more or less turn on the circuit even if there's just a single voltage lane (that should be off) active. It could also be that the debug ChipKit I am using, an old broken one, could be outputting current on the power status connection (which will be an input later) enough to open the gate.


As always with electric and digital troubleshooting, the hardest part is usually finding the error. In this case, most likely a well placed diode will remedy the issue. I will look into this tomorrow, but I'm pretty sure it's a minor detail.

On a side note - 
I'm certain the end result will be worth it, and there's really no other way to do it properly than to remove all the old "gunk" and re-do it piece by piece. Properly.




But.
So close, almost there - only to be torn apart again.
It's a bit scary to dismantle the machine...

Quick update from the land of PCB's!

Almost done with the circuit board!

Just the ATX connectors that needs salvaging from other boards and the power sockets that I've forgot (?) to order. Other than that, it should be ready for a check and conversion from old to new.

I'm especially proud of the big capacitor "UPS" for the ChipKit and the accompanying power sense circuit, meaning that the board will run for a few milliseconds after the power disappear, just long enough to save data to the EEPROM and shutdown things neatly. The watchdog will still kill any lingering solenoids, but it won't hurt to properly turn them off.

1) Almost fulled assembled. Sorry for potato quality picture!

Order's placed!

Fingers crossed - board is ordered!

But not from DirtyPCB's - from Seeed Studio instead. Half the cost as well, which is nice.
Minimum order was 5 so I'll have to spare in case I mess up!

Something like this will be what I'm getting:

1) Should be rounded corners, but the preview doesn't show. Either this manufacturer doesn't allow it
or the preview doesn't show them. Probably the latter since it allows for quick re-theming of the colors,
leading me to think it's simply a color rectangle slabbed on top. 

I also created and added a small PCB-adapter to push all random left-over pins into a single connector along with 5V, GND, serial and I2C for possible future add-ons. 

Wish me luck!

Putting Boards In Perspective...

Ok, so maybe I've gone a bit "home blind" here.
Just measured the board extremely scientifically by holding up a Max32 in front of the screen.

Turns out the board is a lot more compact than I thought when designing it.  :|

1) It's all in the details. In the fine, fine details.

Soldering this... should be interesting!

Easy Peasebee.

This one feels pretty much "there", actually.
Just some minor tweaks and a good walkthrough of all pins and connections (and a final testing of each circuit again) - then I'll be ready for ordering!

1) My first PCB ever manufactured! Or designed, rather. Measuring in at 26x15 cm it's more or less the size of two experiment PCB's. Only this time everything fits on one card. 

2) Flip side. Since I'm not perfect I've designed all Chipkit pins to be accessible while it's attached. I've also added a
couple of "experiment" areas for IC's and additional things I may have forgotten or in case I add, stuff breaks etc.
The pads on the ATX connectors that are slightly smaller are unconnected, but I'll solder 'em on for support.

I think it turned out rather nicely actually. Pretty proud if I may say so. Let's just hope it works! ;)
Also... routing by hand beats automatic routing in aesthetics every day!

Pesebee Rev A!

I've tried and tested all (I think) variations of the planned circuits, and they seem to work perfectly. So I've gone and started with the PCB layout.

1) Simple "everything at once" picture. This is 100% autorouted, so it's not the most aesthetically pleasing routing,
and I'll probably try to route at least the output elements before letting the autorouter fill in the gaps.
I think that the 48V traces needs to be bigger as well, at the moment they're 2.54mm wide.  

2) Since all my sub-boards (Chipkit, SD card, WAV Trigger) are red - and it's a nice color - I'll most likely go with red.
This is taken from another stage in development, so it doesn't match up with the drawing above.

I'm not entirely satisfied with this, and I missed a few items.  It's 23x14 cm large at the moment and probably needs to grow a little to accommodate the larger 48V traces.

So there's probably a few more revisions until I send it to DirtyPCB's for manufacturing. The Diptrace license I got was 500 pins, so it doesn't give me a whole lot of wiggle room - but I'm not complaining; Diptrace is an excellent software and pretty user friendly! :)

All Things Start Small

For the past days, I've been able to test most of my planned circuit board on a breadboard, along with some very basic rewrites of the libraries.

I'm happy to say that I've encountered no problems with the design or code so far, which is in no small part thanks to Majenko on the Chipkit forums for supplying a very readable overview of the I/O pins of the Max32. Of course, this information was available in the datasheet, but he simply presented it in a way the Digilent people really should have done from the start. Super awesome and did indeed explain why I had some trouble in the past! 

1) Image courtesy of Majenko, hopefully it's alright to post it here. Red/orange buttons with white labels are non-exclusive pins and will conflict with the others if used. Green are alternate names and purple ones are unique. Interrupts, SPI and I2C are shown as well.  

As for code, I've designed both DMD and SD reading to run via interrupts, meaning that while the DMD is receiving data or the SD card transmitting the MCU is free to process other stuff.

For me that means I can handle I/O and solenoids at the same time as a row is being rendered (most likely with a ratio/factor since there's no point in updating switches at 14KHz). It also means I can process SD card data simultaneously as I'm building the render buffer instead of waiting for data to be ready, locking the game loop until done, and then building the frame...

I'm thinking that since the hardware will most likely be rolling a lot of thumbs now, I've upped the artwork to use 16 colors instead of 8. I also did a few tweaks to the Python scripts that generates the artwork and found a lot that could be optimized, leading to some pretty nice results:

2) Top: Old generator.  Bottom: New generator.

The old version didn't really under perform here, but there are way more troublesome images in the library. Like this one:

3) Top: Old generator. Bottom: New generator.

Some videos and images will probably need to be handled separately (i.e with non-default options) but ultimately this means that material that was about to get removed might now be inserted instead.  It all depends on how it looks in the machine of course as previews are good and all, but if it looks like crap in the machine it's got to go. :) 

I haven't hooked up the screen to my breadboard, so I cannot test it for real just yet - but in theory it should run at very acceptable refresh rates since the SD card load only increased 25% (3bit -> 4bit and has been heavily optimized now) along with the fact that the rendering doesn't block the MCU anymore.  

Awesomesauce!

Code-bumping

I've installed the sound board and light board now (light cables are still not done thou).

There's a slight ghosting issue present, hopefully it won't be disturbing with the proper lights as I've seen commercial machines do this as well, if you look closely enough. The problem is caused by the weirdest error ever - the lights are running perfectly when connected to a computer and receiving serial input. But when connected to the Chipkit it just goes bonanza. Naturally I suspected the Chipkit first due to recent interrupt changes, but the sound board worked fine on different serial ports and speeds so there's no problem with the serial ports, of that I'm sure.

I realized I was using a rather long (with delayMicroseconds()) interrupt routine on the Arduino and this caused problems with the serial input - but only when connected to another microcontroller... I shorted it down and now it works with the Chipkit, but is instead plagued with ghosting. Which it really shouldn't be doing. It's pretty weird, but for now this "workaround" will do great, but I'll  revisit this in the future if it turns out to be a proper problem. 

I've also programmed highscore saving/loading as well as proper settings saving/loading and a hardware alert routine during boot. The servos started acting up as a result of the interrupt driven display so I replaced the interrupt servo routine with a software based one instead. Seems to work well, except for an occasional servo "tick" now and then on the first out of two servos. This can probably be avoided by doing some magic in the library-code, as I suspect it's dropping due to a timer reset or similar. Quite possibly a dummy servo can be configured to take the hit instead...

Overall the machine is starting to feel really slick now and the software is bumped up to version 0.85!