Terminal Madness!

I decided it was time for a proper maintenance terminal function, so I coded up a rather crude but functional terminal maintenance function.

It goes hand in hand with logging boot status and game state changes etc, and will allow for _much_ speedier creation of game rules without actually pressing switches. Commands can also be chained, so I can easily create a sequence of actions to be simulated to properly activate features and modes instead of faking it by turning a specific mode flag on etc. This prevents me from mistakenly forgetting to reset something that might break the game - very handy! 

 

1) UECIDE (how's the new name going, Majenko? ;) ) with a terminal active. Me gusto. 

Now, if only there was a smart and efficient way of handling game code from EEPROM or SD-card. That would be excellent since a re-flash both take a long time and waste a full erase cycle on the Chipkit (a process that eventually will break the board).

It should be relatively easy to achieve, but it must be robust and extensible.

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!

We shall rebuild!

Getting closer...
I've been struggling getting the light matrix to run properly, since all rows are for some reason active at the same time. I'm thinking the ULN2803a is broken, so I've ordered a replacement. The ULN activates by pulling the row TIP107's to ground, which seems likely in case of a short circuit or similar. We shall see. 

On the other hand - input and output are all up and running and running "very often". I haven't crunched the actual numbers, but it should be in the 500-600Hz range at least. The graphics are a rock solid 60hz (or so, there's no noticeable blinking which would suggesting a minimum of 50hz ) and it doesn't matter if the drawbuffer takes 1 second to create itself, it won't affect solenoids, switches or graphics etc. This means I can most likely use several layers of DMD animations, for instance, one background and one foreground. Should be pretty wicked!

1) Here's a snapshot of my Enterprise Commercial Grade Ultra Deluxe Setup 2000. Still, the various shades
does make a huge impact on the graphics. Looking forward to getting SD card animations up and running!

I'm quite satisfied that there's absolutely no delay anywhere in the code. When the DMD is crunching bits into its registers, the MCU is processing switches/lights etc. The result is a nice double buffered screen in 16 shades and super responsive inputs/outputs. The setup even allows for "autonomous" triggering of slingshot, bumpers and flippers with microsecond delays instead of 15-20 ms previously.

Overall I'm very pleased with the progress thus far!

Turtles....

...are faster than me.

But at least they're not doing a million things at once. Or building pinball machines. :)

Since last I've had some issues with the MCP23S17's, and they didn't want to function properly. I think I got the hang of them now though. There were a couple of issues, for instance;

1) One of the MCP's relied on the Max32 to send an enable signal to it, but it seems the pin can't supply the necessary voltage and/or amperage needed to keep it enabled. I temporarily jumpered it to 3.3V and that solved that. I will probably solder this to the watchdog output instead, since that and the other two MCP's relying on it seem to function properly.

2) The switch matrix MCP displayed the status incorrectly on the DMD. I'm still using a temporary DMD "library" that lets me dot pixels for basic trouble shooting. I forgot to add the clear buffer function, so every draw could only add to the screen and not remove. This fooled me to think that the built in pullups malfunctioned and/or the software for it. I've verified functionality with a LED instead and everything works as intended, and has most likely always done so.

3) I've moved away from all fancy MCP-libraries and communicate directly via SPI, and that probably helped a lot in knowing exactly what's going on. Will encapsulate this into functions optimized for the "thread" handling I've planned for them.

Lastly, I've, err, confirmed that the fuses function properly.
While testing the inputs I did something very wrong (i.e voodoo connecting things) and blew the 5V fuse. It's rated at 3.25A so that's a pretty decent amount of current that was blocked instead of frying other components. 

But at least things are moving forward! :)

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.

It's all the mind

The progress as of lately has been mostly theoretical and the new PCB has been untouched.

Been really busy with life in general while the machine has been thoroughly playtested during parties, birthdays and integrity checked by my kids. It holds up, mostly, but there are weird bugs that I believe cannot be fixed in the current state. Weird stuff happens and cross-circuit spikes cause things to trigger wrongfully and what not, and for some reason you can sometimes no longer drain the ball when you're on the second ball. This occurs at random, and when it happens totally unrelated buttons stop working, such as the Start-button, and the debug mode for the lights starts etc. Wiring is alright, but as I wrote, I believe cross-talk or voltage spikes are to blame.

Anyhow;
I'm looking forward to four sweet weeks of uninterrupted work on the machine, which is when the new motherboard will be transplanted. Hopefully everything checks out and I can finish up the new wiring as well. Really looking forward to tidying up everything, getting the new code and video in place and get on with actual game programming!

Thoughts for another day;
Thinking about making the playfield artwork brighter, possibly remaking the artwork. But that'll be done once this playfield has gone fubar.

"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!

PCB's have arrived!

Got the PCB's today - and I'm very impressed by the work of Seeed Studio!
Superb finish and to the best of my knowledge not low-budget in any way. Despite being half the price of Dirty PCB's "cheap and dirty PCB's", they look stellar.

Now I just have to wait for the rest of the parts to arrive.
Agonizing...

1) PCB's. Turned out even better than I hoped for. Hopefully it's not five giant coasters...

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! :)

Revision Revised

I was wrong about the voltage in the last post.

Turns out I had connected rows and columns wrong (swapped really), so the lights were always on and stuck on the very first row. Doh... 

After a night of frantic coding, I've managed to do something really weird.
With an input voltage of 12V, I get; 12V out. Despite duty cycling at 1:8.
What.

I measured the voltage without anything connected, between P-channel output to N-channel input, it's rock solid at 12V when active. If I put a light there and measure the same way, it's around 1V since the bulb is stealing the rest of the voltage. The light turns on and off as I rotate the active light in software, so it's not constant on either. I am using pull-ups for the P-Channel MOSFET's, but it does feels a bit too good to be true.  :)

1) Chipkit driven by 12V wall wart, 12V out to P-channel TIP107's via the Vin-pin. The meter says 12V, but my senses says it couldn't really be. But it's bright enough to shine through a very dark smoked glass candle thingy.

Square One?

Feels a bit like I'm back to square one doing these kind of things again... ;)
Only this time I actually know what I'm doing. Which sure is a plus!

I'm especially proud over the new code and setup.
The lights update at a very high refresh rate and gives a solid 3.01V when fed with 5V (duty cycled 1:8) and 5.04 at 9V. Presumably I'll get roughly steady 6V out of 12V too, which is perfect. Light rows and columns are all part of the same PIC32 port, thus the cost of updating all lights is the same as updating a single pin.

1) I/O expander MCP23S17 and micro SD in action. Super awesome toggle switch as input. 

2) Darlington transistor array ULN2308a driving TIP107 along with TIP102's.
Very nice combo, although not entirely logic level they are bipolar transistors
and react similarly to input. No "ramping up" here - and - no flickering at all! :)

I've also decided to give GI and flashers their own dedicated lines controlled by TIP102's and a MCP23S17. Flashers due to the voltage requirement to duty cycle them and GI for - worst comes to worst, a little flicker on a blinking light is no biggie, but flickering lights that shouldn't be, is.

I thought my old code was pretty optimized but take the old render routine, for instance. It performed a single row update in 100uS, and now I'm down to 50uS including updating all lights, all switches, all cabinet inputs and solenoids.... AND twice the amount of colors.
Overall, everything is high frequency SPI, direct port writes, updating other parts while one part is busy and maximizing use of hardware features and interrupts.

*pats himself on the back*

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!

Status Machinima

Due to popular demand, here's a short update. ;)

I've more or less abandoned Fritzing.
For designing small circuits the program was fine, but the software became quite slow and unresponsive once the number of components increased. The program is nice, but needs maturing and it's officially not out of beta yet, so I'll hold no grudge. :)

I have since reached out to the good folks at Diptrace, who nicely enough supplied me with a non-profit license that allows me to build the board(s) I inteded. Very nice! I will most likely build a main board and a power board (I/O board, if you wish). That allows me to swap or update and avoid creating a totally new board in case of disasters...

On top of that, I've learned that the I/O pins on Chipkit Max32 are heavily shared, so I've needed to come up with some voodoo to make it all work out with the aid of I/O extenders. I've ordered a bunch of IC's to properly test this before designing the circuit based on the new circuits, including buffers, EEPROM, darlington transistor arrays and resistor networks. All fun and new components!

So, that's that for now...
Until next time - game on! 

Big plans for this year!

Happy New Year!

This year will be about finishing the machine.
It's so close I can basically taste the highscores already!

But...  (unexpected, huh?)  ...I will also be remaking the motherboard.

I feel I've finalized all functions enough to create a proper PCB of the features needed. I will also add a few backup functions such as additional ports and other features that aren't necessarily used for this game. You never know...

I've tried several (trial versions of) different PCB softwares, including Eagle, PCB Express, DipTrace and one other I can't remember the name of - but the one that got my interest is Fritzing. Very easy to use, and perfectly fine for my purposes. It even has a breadboard and code layout in addition to the standard schematic and PCB-layout features. The production prices aren't the cheapest, but neither are any of the other software's license costs...

Read more about Fritzing here.

While creating the new motherboard, I will also transplant the location of the board into the head instead of the body. This is common practice in consumer pinball machines, and I can see why. It's basically impossible to service the machine without moving the glass, board and what not. It's also more or less impossible to troubleshoot hardware errors. On top of that, I'll rewrite most of the code as I now have a better understanding of the programmatic requirements of a pinball machine (which wasn't there to begin with - never seen the innards of one before starting this project! ).

I've played quite a few games now, and man - it's a difficult game! No risk of completing the game without proper practice, that's for sure...

1) State of the machine as of 2017-01-01. There are a few plastic signs missing here though, that have been broken in half during the years. But overall - it's looking very good! :)