Make: Poor man's Minimig ARM Controller

In the last post I presented my findings on using a cheap ARM dev board as a replacement for a MiniMig ARM Controller. I've done some fairly extensive testing and it seems to work passably, so here are some instructions on how to build your own.

Firstly you are going need a board that hosts a AT91SAM7S256 chip and exposes the GPIO in a direct manner i.e. does not have any peripherals attached etc.

Specifically you need to make sure that:

• PA4 - PA10
• PA12 - PA15
• PA24 - PA28
• PA20
• GND
• 3.3V
• nRST

Are available. If this is not the case, you could possibly alter the code to change pin mappings, but that is beyond the scope of this post.

Next you'll need to get hold of a 28 pin DIP socket, preferably the "tulip" kind:

In my case the dev board headers were available as headers with 2 rows of 10 pins:

So I used some crimp connectors and 20 way ribbon cable to connect these up.
Next you'll need to figure out the pin mappings between your dev. board and the pic socket.
To start you need the schematic for your dev board, mine had this for the pinout info:

Then this must be mapped to the relevant pins on the PIC socket. I used the ARM controller schematics as a guide:

and the PIC mapping:

This should get you to something like this:

From there its just a matter of carefully mapping pin to pin with some wire.
I stripped and tinned the relevant wires in the ribbon cable, pushed them into the mapped holes in the DIP socket and then soldered them in.

The observant reader will notice that GND, 3.3V and nRST are not mapped to the dev board header.
There is another header on my board that provides GND and 3.3V and the JTAG header exposes nRST.

And that is all there is to it :)

HTH
-(e)

Prelude: Poor man's Minimig ARM Controller

I have 2 Minimigs both fitted with the replacement ARM Controller boards.
In a recent cock-up I nearly managed to destroy one of the ARM boards by breaking a pin off whilst hastily pulling it out of the Minimig.

Thanks to a $1 DIP socket I managed to save the controller by soldering the pin back onto the board.... and gently plugging the controller into the new socket:

Which thankfully worked pretty well. During this whole debacle I happened to have a proper look at the mcu on the board and saw that it was an AT91SAM7S256. I remembered that I had a cheap dev board with the same chip on it. The dev board cost me $25 when I bought it, as opposed to the near $100 price tag of the ARM Controller, so I began to wonder if it might serve as a cheap replacement.

After some very careful pin mapping and buzzing the dev board out, I came up with this:

And it works 100% (or seems to so far). Whilst the board I used does not seem to be for sale any more, there are alternatives available and even this board ($27 on eBay as of this post) :

(the bigger brother AT91SAM7S512) should be simple enough to wire up and port the code to (if even necessary).

All in all a fairly cost effective hack that also has the benefit of providing JTAG access for devs that wish to extend the ARM Controller firmware.

-(e)

Amiga A500 addon card "fixed"

Well it seems that I've managed to fix the card mentioned in my previous post.
The battery arrived from eBay, I cleaned up the traces (and repaired where necessary) and the miggy now boots with the card in place. I think its looking pretty darn good:

With some identification help from the friendly folk at AmiBay this seems to be an RTC and 1/2 or 1MB RAM upgrade board (seems that the RAM chips are 256KB, so possibly 1MB). Now I need a new FDD or equivalent to test this baby out as I can't get disks to load properly. No one ever said a retro-computing hobby was going to be cheap...

Resurrecting an Amiga 500

 A buddy of mine is emigrating and while going through all of his stuff came across his old Amiga 500 and Commodore 64 which he very graciously has donated to me! SCORE!

I love old computing hardware, already owning an Amiga A1200, Atari, ZX80 and various other bits and pieces so these two machines were a welcome addition to the fold.

The first thing to do was obviously to boot the machines up, so I started with the A500 and was greeted with the 10-short 1-long Blink Code of Death. A little Goolge-fu revealed that this indicates various severe issues, one pointing at a leaked battery and another at a chip RAM issue.

So I did the next logical thing and opened the miggy up. What I found was that (thankfully!) the main board was clean as new but an expansion card had a battery that had leaked (the miggy boots without this card, so another win):

It seems this might be an ActionReplay of some variety. Having a closer look at the problem revelead this:

Traces looking a bit dodgy and battery acid has leaked along the traces into the chip (RAM) socket.... oh dear... so I guess its time to clean it all up, but first a closer look at the damage:

Time to whip out the iron and get to work. After a fair bit of struggle (the battery contacts were well corroded and needed to be cleaned before I could de-solder them), the board now looks like this:

Looking not too bad in fact! The traces are intact, its just the lacquer on top that has gone. A really good clean with some isopropyl alcohol and a pretty thorough test with the multimeter indicates that all is OK. Unfortunately the other battery contact point was not so good:

Bit of missing trace there, but easily repairable. So off to eBay to get another battery and to the local electronic supplier to get another socket (why is it that you always have every other chip socket but the one you need!!!).

The battery is in transit and should arrive in a week or two (the joy of living at the bottom of Africa) and the socket I'll pick up this weekend. Hopefully the actual RAM chip is okay and once I've sorted out these two issues the card will work again.

I'll update with info as it goes. Now I have to find a suitable video-out option for the A500 as B&W composite is just not doing it for me, the best looking option is a bit expensive though...

AIR orientation bug follow up

Small update:

If you have used the info supplied in my earlier articles here and here I am happy to announce that Adobe has fixed these issues in AIR3.4 and these hacks are no longer necessary.

In fact, if you want to use 32-bit colour in an Android AIR app, you need to ensure that you don't hack the Activity theme as this will result in forcing the app to 16-bit (something that had me scratching my head for a while!).

So thanks to Adobe for that, now if they can just fix the issues with URLLoader on 3.4+ and the ATF issues on nVidia based tablets then my life would get a lot easier...

If anyone from the Adobe AIR team reads this, please contact me! My team uses your product in ways you probably wouldn't believe and we are constantly pushing AIR to the limits of the technology. It would be awesome to partner with you on the issues we find.

-(e)

Implementing Artcfox's TLC5940 code on an Arduino, Part 3

Well its been a while... Real Life(tm) has been rather busy!
The code for this post has been gathering bit-rot on my drive so I thought it time to just put it up with a a short post (basically just a code dump) which I will follow up at a later point.

In the previous article we got the Arduino setup with appropriate clock fuse settings so that Matt's code would work. Based on this I took the sample code from CH9 and modified it to implement a small RGB pattern using some of the CH9 features, specifically the gamma correction.

CH9 is based around mulitplexing the output. I haven't used this as I don't have the transistors availabe to test it, so basically the output is still a direct drive of the attached LEDs with one colour per output pin on the TLC5940. However there is no reason that multiplexing shouldn't work. If you want to try it out, refer to Matt's original document and wire appropriately. If you apply the techniques discribed previously to the original CH9 code you should be good to go. You can use the attached code as a reference.

Hardware setup should be the same as per the first article. To see the correct visual output, wire each leg of an RGB LED to output pins 0,1,2 (R,G,B) then 3,4,5 etc. for a total of 4 LEDs. Then compile and upload the sketch and you should be good to go. The code will colour fade between each rainbow colour.

The code is available here. Go get it!

Next time I get a chance to get to the local electronics supplier I'll buy some of the appropriate transistors and wire up for the multiplexing capabilities of Matt's library and post up some wiring info and more code.

For questions etc, follow me:

or mail me at: sweetlilmre (at) gmail (dot) com

-(e)

Implementing Artcfox's TLC5940 code on an Arduino, Part 2

In my last post I detailed the basic hardware and software setup for getting Matt's TLC5940 chapter 3 code working on an Arduino. The the code doesn't do too much, but with the hardware and software working we can start to explore later chapters (where the interesting stuff happens).

At this point there is one more hardware obstacle to overcome. Matt makes use of an interesting feature of the Atmega328p called CKOUT. This is a chip level setting that can (according to the 328p datasheet) "output the system clock on the CLKO pin". Matt uses this to drive the TLC5940's GSCLK pin, a very clever way of handling the timing between the two chips.

Unfortunately the Arduino is not configured to support this by default and in order to switch on this feature, special configuration values in the 328p's flash known as "fuses" need to be be set. To do that, you need a chip level programmer.

The programmer I use is an USBtiny2 clone that I got off eBay for about 10 USD (search for "usbtiny" or "usbtinyasp" and you should get many results). Alternatively you can use a second Arduino to accomplish the same thing as per this link. Lastly, if you want to support a really fantastic company and get a great programmer with a nice case, please consider this one from Adafruit.
From this point on I will be assuming that you are using the USBtiny programmer, are on a Windows machine and are intending to program the fuses of an Arduino UNO.

At this point I am assuming that you have managed to install the drivers for your programmer. If you are using the USBtiny and are on Windows7 64-bit, this link may be helpful. If not, visit this excellent tutorial at Adafruit and get the drivers installed.


Once you have the hardware, you need to get hold of AVRDUDE. This is the software that will talk to your programmer and allow you to set the fuse bits. As of this article the latest AVRDUDE version is 5.1.1 and can be found here. If you are using an alternative programmer, please check compatibility with AVRDUDE at this page (look for the "-c programmer-id" reference).

Grab the windows archive (avrdude-5.11-Patch7610-win32.zip) and extract to a convenient location. I used "C:\temp\avrdude". Now you will need to connect your programmer to your Arduino.

Arduino ICSP port

Using the supplied 6 pin cable connect the programmer to the ICSP port on your Arduino, making sure you have:

• disconnected your Arduino from USB and any other circuitry.
• correctly identified the polarity and orientation of the programming cable and pin 1 on the ICSP port of the Arduino.

Once you have the cable correctly connected, connect the programmer to usb and the Arduino should power on.

Assuming everything is good to go: open a command prompt, change to the directory you extracted the AVRDUDE software into earlier ("c:\temp\avrdude" for me) and type:

avrdude -p m328p -c usbtiny 

See the advanced notes for additional information.

This command should print out something pretty much like this:

AVRDUDE basic output

If you get this result, add a "-v" to the command:

avrdude -p m328p -c usbtiny -v

which should spew out a whole load of text ending in something that looks like this:

Standard Arduino UNO fuse settings

What we want to do is to change the value of the lfuse from 0xFF to 0xBF to enable CKOUT.

To verify this, open this awesome AVR fuse calculator in another tab / window and check the lfuse checkbox that reads "Clock output on PORTB0; [CKOUT=0]". You should see the calculated value for lfuse change from 0xFF to 0xBF (and back when you uncheck the option).

Before we proceed any further, a word of caution:

Incorrect fuse settings can brick your Arduino!!!

If your fuse settings are not the same as the screenshot above you probably shouldn't proceed unless you are sure you know what you are doing.

Some clarification: You need to know that you have a good fuse read at this point. Your values may be different to mine but as long as they are good values you'll be okay.

Thanks to +Al McElmon who reported his hfuse value as D6 not DE. In the fuse calculator you can see that this is because EESAVE has been enabled. This could possibly be a setting on later Arduino Models?

Finally, if everything checks out and you are 100% sure of this, we are one command away from completion:

avrdude -p m328p -c usbtiny -U lfuse:w:0xBF:m -u

This command will write the value 0xBF to the lfuse and set CKOUT.
For a breakdown the "-U" command above, the command:

• selects the lfuse memory for the operation
• writes (use r for read and v for verify)
• the value 0xBF
• in immediate mode (i.e. write the value specified directly)

"-u" turns off safe mode which should enable the actual write.

And there we have it. Your Arduino should now be in a state where we can move onto the more advanced chapters of Matt's book.

Next time we are going to do exactly that, I hope you've enjoyed this post.
Until then, happy hacking!
-(e)

p.s. If you get stuck, I can attempt to help you out, circle me on G+ and send me a message via Messenger, or post a comment and I'll see what I can do.


Advanced Notes:

Perhaps you have a different model of Arduino? (e.g. ATMega168 e.t.c.):

The "-p m328p" switch for AVRDUDE specifies what chip your Arduino has. The "m328p" value is valid for the Arduino UNO and several other models, but will have to be changed for alternative models.

In this case, when using the fuse calculator please input your values for lfuse, hfuse and efuse into the fuse calculator, ensure that you have the correct AVR chip selected and note the change in the lfuse value when CKOUT is selected. The point here is that we wish to change ONLY this value. You can also confirm default board fuse settings in the "boards.txt" file located in the "hardware\arduino" directory of the Arduino IDE installation.

AVRDUDE has many other switches and supports many other programmers. I would suggest that you check out the command line in the documentation.