Gamepad Test

 

My goal is to play some games on ESP32 hardware.  One step to get there is create a test app to pair with existing game controllers.

Classic (not the newest) ESP32 boards support Bluetooth Classic and BLE.   ESP32-S3, C3, C6 for examples only support BLE.  ESP32-P4 doesn't support wireless directly at all, it uses a C6 as a wireless coprocessor.  Thus it's useful to see what controllers you can attach.

Instructions:

Auto binds to pairing device
gampad activity shows here
and see serial monitoring
for more devices & info

Also see: m5_minijoystickc_gamepad

No name IPS 240*240 ST7789 TFT display with Arduino GFX Library and ESP32-C3 (RISC-V) development board

 

This is an alternative take on the previous article Adafruit ST7789 TFT display with Arduino GFX Library and M5StampS3.   This time with a generic display, and a different MCU (ESP32-C3).  This one has a single RISC-V core (instead of dual core Xtensa).

So excuse the repeated text, the content has been changed only slightly for the different hardware...

---

Attaching a display to a circuit can provide a lot of detailed info and graphical value.  While "a picture is worth a thousand words," an animated display can be entertainment value, textual information can be informative, and add an input device, and the system can be interactive with billions of possibilities.

The tricks in embedded development is choosing the right display, having the right library that supports the display, and figuring out to use it all together with your target embedded system.

Shown above is a minimal footprint ESP32-C3 development board (I purchased one from AliExpress for around two US dollars, very cheap!), with a generic IPS 240x240 TFT display (ST7789 based) I had purchased years ago on eBay.  An SPI interface is utilized for communications using the GFX Library for Arduino.  I am using a solderless breadboard to prototype the circuit.  Later I will implement as a more permanent circuit.

Besides power and ground, there are only 4 connections from the ESP32: SCLK, MOSI, DC, and Reset.  In this sample, the TFT select line is permanently selected by connecting to ground.

#include <Arduino.h>

#include <Arduino_GFX_Library.h>

Arduino_DataBus *bus = new Arduino_HWSPI(6/*dc*/, 7/*cs*/,
   2/*sclk*/, 3/*mosi*/, 10/*miso*/, &SPI,
   true/*is_shared_interface*/);

Arduino_GFX *gfx = new Arduino_ST7789(bus, 11/*rst*/, 1/*r*/,
   true/*ips*/, 240, 240);

void setup() {

  gfx->begin();

  gfx->fillScreen(BLACK);

  gfx->setTextColor(WHITE);

}

void loop() {

  int x = (int)random(240);

  int w = (int)random(240 - x);

  int y = (int)random(240);

  int h = (int)random(240 - y);  

  int color = (int)random(65536);

  gfx->fillRect(x, y, w, h, color);

  if (random(20)==13)

    delay(100);

}

The wiring corresponds to the code of the databus and gfx initialization parameters, specifically lines GPIO02 (SPI CLK), GPIO03 (SPI MOSI), GPOI06, GPIO11 of the ESP32-C3 connected to SCL, SDA, DC, and RES (Reset) of the display respectively.  Also both the VCC and BLK lines of the display are connected to 3V3, and GND is connected commonly between the display and ESP32-C3 board.  MISO and CS lines are defined for use in the code, but wiring them was unnecessary and not possible.

TFT   ESP32-C3

GND   Ground

VCC   3V3

SCL   SPI Clock (2)

SDA   SPI MOSI (3)

RES   (11)

DC    (6)

BLK   3V3

Not sure why triangles are sometimes displayed (maybe out of range data?).  That is why there is a 5% chance of a tenth of a second delay to pause for the viewer.

This is just a demo.  You should be able to find much better uses for the display that these random rectangles.

Build details:

• Arduino IDE 2.3.2
• esp32 boards 3.0.4
• GFX Library for Arduino 1.4.7

Important!  The board I have will only run its flash chip in DIO mode, so be sure to check all the board options in Tools menu of Arduino IDE before flashing, or if you run into trouble.  Also, updating board libraries may reset your options to default so if flashing after a time, check these settings again, and again.

Some models of the ESP32-C3 development board have a serial chip, and some utilize the C3's built in USB support.  Be sure to set USB CDC on Boot settings accordingly, and use the BOOT/RST buttons to put into bootloader mode for flashing if necessary.

I found it necessary to unplug and replug the ESP32-C3 board to get the graphic demo to work.  Your mileage may vary.

Adafruit ST7789 TFT display with Arduino GFX Library and M5StampS3

 

Attaching a display to a circuit can provide a lot of detailed info and graphical value.  While "a picture is worth a thousand words," an animated display can be entertainment value, textual information can be informative, and add an input device, and the system can be interactive with billions of possibilities.

The tricks in embedded development is choosing the right display, having the right library that supports the display, and figuring out to use it all together with your target embedded system.

Shown above is a minimal footprint ESP32S3 in the form of an M5StampS3 from M5Stack connected to 2.54mm pins, with a rounded corner ST7789 based 280x240 display from Adafruit.  An SPI interface is utilized for communications using the GFX Library for Arduino.  I am using a solderless breadboard to prototype the circuit.  Later I will implement as a more permanent circuit.

Besides power and ground, there are only 4 connections from the ESP32: SCLK, MOSI, DC, and Reset.  In this sample, the TFT select line is permanently selected by connecting to ground.

(The Adafruit display used in this example also includes a MicroSD connector and SPI connections for that as well.  Support for SD is beyond the scope of this article, and would require additional changes to the circuit and code.)

#include <Arduino.h>

#include <Arduino_GFX_Library.h>

Arduino_DataBus *bus = new Arduino_HWSPI(1/*dc*/,

  GFX_NOT_DEFINED/*cs*/, 7/*sclk*/, 5/*mosi*/,

  GFX_NOT_DEFINED/*miso*/, &SPI, true/*is_shared_interface*/);

Arduino_GFX *gfx = new Arduino_ST7789(bus, 3/*rst*/, 1/*r*/,

  true/*ips*/, 240, 320);

void setup() {

  gfx->begin();

  gfx->fillScreen(BLACK);

  gfx->setTextColor(WHITE);

}

void loop() {

  int x = 20 + (int)random(280);

  int w = (int)random(300 - x);

  int y = (int)random(240);

  int h = (int)random(240 - y);  

  int color = (int)random(65536);

  gfx->fillRect(x, y, w, h, color);

  if (random(20)==13)

    delay(100);

}

The wiring corresponds to the code of the databus and gfx initialization parameters, specifically lines 1, 3, 5, 7 of the M5StampS3 connected to DC, RT (reset), SI (serial in), and CK (clock) of the display.  Also the displays V+ line is connected to 5V, and both TC and G (Ground) are connected to ground common to the ESP32 S3.

TFT   StampS3

V+    5V

3V    NC

G     Ground

CK    SPI Clock (7)

SO    NC

SI    SPI MOSI (5)

TC    Ground

RT    (3)

DC    (1)

CC    No Connection

BL    No Connection

It appears there is an overscan issue, beyond the rounded corners.  The gfx object is defining 320x240 display instead of 280x240, and the position and sizes of the rectangles are also interesting here.

Not sure why triangles are sometimes displayed (maybe out of range data?).  That is why there is a 5% chance of a tenth of a second delay to pause for the viewer.

This is just a demo.  You should be able to find much better uses for the display that these random rectangles.

Build details:

• Arduino IDE 2.3.2
• esp32 boards 3.0.4
• GFX Library for Arduino 1.4.7

Extremely small emulated C64 and C128

 

This "portable" Commodore 64 and 128 emulator (m5 source code branch) is my work in progress, one in a series of minimalist emulators ported to different hardware targets. Only text (on LCD) with background, foreground, border colors, keyboard entry via USB serial tethered web browser, and general 6502/6510 and C64 memory management emulation is present (no, won't play games, make sound, or do bitmapped graphics) with some D64 emulation [added 7/2/2023].

(Update 7/28/2023) Now with GO 128 command.

GO 128 command

Even my son asked, "Why do you need to do that?"  Well, he has a point.  I wanted a C64 that fit in my pocket or even on my wrist.  And targeting new hardware platforms with my emulator is part of my hobby.

How does it work?  Check out my highly technical drawing.

Now I already here you asking why I didn't connect Bluetooth to the M5Core, because certainly it has Bluetooth as well, and why didn't I use a USB keyboard connected to CoreS3, because it includes USB Host.  But I've had trouble tracking down examples of HID Host examples for M5; client examples are prevalent, but host?

Pictured here is a phone is running Chrome with a custom copy of the html/javascript keyboard adapter including web-serial-polyfill because mobile Chrome doesn't directly include Serial API support.  A Palm Pilot foldable keyboard has a Bluetooth adapter, paired with the phone.   HID keystrokes are captured by the web page, converted to C64 key scan codes, and a list of the active key scan codes (or 64 when keys released) is sent over USB Serial to the M5Core device which is running the C64 ROMs which are tricked into thinking a real keyboard is attached; keystrokes are processed by the C64 KERNAL IRQ as normal.

The M5Core is being powered by the phone.   Why M5Core?  Because it's a polished packaged solution.

Yeah, we could just run a Commodore 64 emulator on the phone, but this way, I could have complete control over the keyboard emulation, what keys are present, how CTRL and Commodore keys work, etc.  And it's just because I can, not because I should.

Why the Palm Keyboard?  Because it folds in my pocket!  And because I had one from back in the day.  Any keyboard you can attach to a phone or computer should work.  And this Bluetooth adapter just makes it so cool, and easier than a tethered keyboard.

The next step is to merge this solution with my Commodore 128 keyboard adapter to completely reject the portability feature.   That would look really cool hooked up to my phone!  Update (7/31/2023): check out YouTube for connection from ItsyBitsy/keyboard to Core Port.A.

C128 Keyboard Adapter Breadboarded Prototype

7/23/2023: PCB prototype keyboard adapter w/ ItsyBitsy

I am excited about my nonsense crazy adventures. Even if only I enjoy them.

=====

Update (7/2/2023): D64 support is currently working with Core2 only (Basic Core doesn't usually have the additional SPI RAM, but not yet sure why CoreS3 is failing to attach SD).

Update (7/3/2023): Got CoreS3 working with SD switching header to M5Unified.h for that target (was M5Cores3.h) and adding special definition, override logic for SD_CS to use GPIO_NUM_4 instead of default.  See updates to M5Core.h.

Update (7/28/2023): Commodore 128D extended keyboard working with UART connection to Port.A of Core, and Commodore 128 emulation is ported as well.

=====

mbedR3uino: mbed adapter for Arduino shields

The mbedR3uino is a vertical shield adapter for the mbed prototyping platform.  It provides compatibility with standard Arduino shields including the pins added to Arduino Uno R3 to make shields more independent between main boards.

This is the project I wanted three years ago.  Finally the need, inspiration, materials, and dependent projects converged.  The ability to easily add pluggable hardware to the mbed had been demonstrated when I created the In-between Shield for mbed which plugged into the mbed workshop board adding flash memory to the mbed which plugged into the shield. 

 

I have developed a number of prototype shields for Arduino using a ProtoShield that have been compatible with my various Arduinos, Netduinos, and other development boards providing plug compatibility with Arduino shields.  With the addition of the new R3 pins: SCL, SDA, IOREF some more platform independence has occurred allowing the shield (or at least its I/O) to run at the same voltage as the target platform, and a standardization of the location of the I2C pins.  The SPI pins which were originally reserved for ICSP or initial programming of the Arduino also became a standard.  I opted to skip the SPI/ICSP pin compatibility and stick with the Uno SPI pin layout for simplicity; a future version should include the SPI/ICSP pins in their expected location.  An R3 version of the ProtoShield was found here and I had seeedstudio build the PCBs.

The mbedR3uino is named because mbeduino was already taken.  Inserting the R3 in the name gives it some uniqueness while expressing its meaning.  The adapter consists of two pluggable pieces.  The first plugs into the workshop board above the mbed providing a footprint identical to the mbed.  Components were added to the ProtoShield to plug it into the first piece, and wire the connections to the Arduino R3 headers.  The result is that Arduino shields can be connected to the mbed.

Standard height 0.45" header pins were used to connect the ProtoShield to the above mbed adapter.  The above mbed adapter used taller 0.7" header pins so the PCB barely clears the height of the mbed, only touching the mini USB socket.  Since my prototyping boards have solder terminals only on one side, and to keep them clean looking I try to solder only on the bottom, hidden from view, I used needle nose pliers to push the pins so the plastic is flush with the top of the pins, and then carefully solder the pins from the bottom of the board not getting them too hot or the pin could waver out of place.  Once all the pins are soldered into place they hold very securely.

Note that the mbed workshop board or equivalent is required.  It already provides SD, Ethernet, and USB connectivity.  I have a revA board which pin 9 is held high to 3.3V (intended for SD card detect?), so to allow it to be used for the UART, I cut the trace on the workshop board.  An alternative to using the workshop board would be to have dual row headers and connect the columns for all pins 1-40, as done in my mbed Text LCD development board.  It is relatively easy to also solder a USB B connector, and an Arduino shield can be used for an SD card.  Connecting an Ethernet jack directly to the mbed can be done using a breakout board.

All the available pins on the mbed are either connected to the Arduino headers, or a few are broken out for additional expansion: since the workshop board already uses pins 5-8, they were left as an expansion; CAN and battery lines are implemented as jumpers for expansion.  Analog pins and power pins are where they should be, one UART is wired to D0/D1 for Arduino compatibility, and one SPI is wired for original Uno compatibility (D13-D10).  One pair of I2C pins are in the new R3 location, and the same pins are also wired to the same location as done with the Leonardo: D2/D3.  The remaining D14 and PWM pins are wired to the remaining Arduino header pins.  The schematic below shows how I chose to map the pins between the boards.

Schematic - Click on image to view larger

3V-5V Switchable I2C Real Time Clock Shield

This is a prototyped Arduino shield that is 5V and 3V switchable.  The real time clock (RTC) is a DS1307 running at 5V, with a backup battery to keep time while not plugged into another power source.  It connects with an Arduino or similar board via I2C, but using a voltage translation (level shifter) circuit using FETs (reference: Philips) to isolate the RTC chip that always runs at 5V from the Arduino CPU which can be running at either 5V or 3V.  This provides support for 3V Arduino format boards such as the Arduino Due which can be damaged if 5V is applied to its lines.  Jumpers are provided to select the voltage (red), the I2C lines used (D3/D2 or A5/A4), and whether 3.3K pull-ups are used on the microcontroller side of the circuit.  Note the RTC always has its pull-ups in place.

Note that due to USPS regulations, Lithium batteries cannot (without meeting specific conditions) be shipped via US airmail so my Digi-Key order that included the FETs and crystal was revised to eliminate the batteries.  These are available cheap in bulk from many distributors, but to save immediate costs including shipping I ended up purchasing a single one at the local drug store.  Next time I may use ground shipping for such items, but I also found a local electronics supplier that has a decent price.

 

The DS3107 chip was purchased overseas via eBay as it was available much cheaper than domestically.  Hint: look for free shipping.

Schematic

A different 3V RTC chip could also be used, such as a surface mount chip, and then the level shifting circuit (FET drain/source) needs to be reversed per the original circuit recommended by Philips Semiconductors because the low/high sides of the circuit are reversed when the RTC is running at 3V and the microcontroller is running at 5V.

For prototyping the FETs ordered are in package TO92-3.  I ordered two different FETs and ended up using the more expensive ones with a higher Vdss rating (200V).  A cheaper FET in SOT-23 packaging with a lower rating of 50V was also sourced but not tested.

Adafruit has a tutorial including an Arduino library for use with the DS1307.  I tested this library on the Arduino Leonardo and Duemillanove running at 5V.  For the 3V Due, I used simple raw I2C (Wire library) commands to talk to the DS1307.  Only SCL1/SDA1 worked for me on the Due (had to jumper these as the ProtoShield is pre-R3 and doesn't have dedicated SCL/SDA pins).

(I had meant to publish this article in February but due to some bad soldering on my part and challenges with the Due, this prototype wasn't working properly.  Took multiple re-visits to fix everything.  Now I am very glad it is working now.)

I2C EEPROM Shield and Platforms Roundup

 This I2C EEPROM shield was built to study I²C communications.  This two-wire bus involving bidirectional clock and data lines was invented by Philips (now NXP) to support a single master and multiple slaves.  A concise explanation and pseudo code is available on Wikipedia.   The shield is composed of a Microchip 24FC1025 which is a 1024 megabit (128 kilobyte) EEPROM, and supporting circuitry of jumpers, sockets, and resistors.  The jumpers provide options for the implementation to support a variety of platforms. 

 

Note: there is a strong advantage to using the I2C 24FC1025 over its SPI cousin the 25AA1024 that I highlighted in another EEPROM Shield article.  The I2C version has a simple API: write the address, then read/write bytes.  The SPI version has a complex API including erasing the whole chip, erasing a page, writing a page of memory, etc.  While the SPI device adheres to some JEDEC standards allowing for interoperability and has faster protocol speeds (20MHz) than the slower I2C device (100 kHZ, 400 kHZ, or 1MHz), using an I2C EEPROM is much faster to develop for time to market when engineering from scratch.

 

 

The form factor of the EEPROM shield supports the original Arduino such as the Duemilanove.  This also makes it compatible with a variety of other Arduino boards, and boards that are compatible with the Arduino shield form factor.  I have access to quite a few boards that are either directly compatible with this shield, or easily adapted.  Testing these boards with the EEPROM is summarized in the following table:

 

Board	Type	VCC	Pullups	SDA/SCL	Solution	Notes
Arduino Duemilanove	arduino	5V	internal	A4/A5	Wire.h
Arduino Leonardo	arduino	5V	external	D2/D3	Wire.h
chipKIT Max32	arduino	3.3V	external	D20/D21	Wire.h	1
chipKIT Uno32	arduino	3.3V	external	A4/A5	Wire.h	2
Netduino Mini	netmf	3.3V	on board	9/10	I2CDevice	3
Netduino Plus	netmf	3.3V	external	A4/A5	I2CDevice
Netduino Plus 2	netmf	3.3V	external	SDA/SCL	I2CDevice	4
Panda II	netmf	3.3V	on board	D2/D3	I2CDevice
FEZ Cerbuino Bee	netmf	3.3V	external	D2/D3	SoftwareI2CBus	5, 6
Netduino Go Shield Base (Standalone)	netmf	3.3V	internal	A4/A5	SoftwareI2C	7

 

Notes:

1. jumpered D20/D1 pins to D2/D3

2. JP6/JP8 jumpered to RG3/RG2

3. custom board used to adapt the Mini to Arduino form factor

4. jumpered SDA/SCL pins to D2/D3 or A4/A5

5. hardware I2C pins on Cerbuino not available to shields so using software method

6. WARNING: RESET/A1/A4 are not 5V tolerant on the Cerbuino.  I could have damaged the Cerbuino if I had used different SDA/SCL jumper settings on the EEPROM shield.

7. waiting on a fix from Secret Labs so can use I2CDevice

 

I was able to successfully access the EEPROM using all of these platforms.  The Arduino and chipKIT boards use Arduino and Arduino compatible IDEs.  The .NET Micro Framework (netmf) boards used either the included support for the I2C hardware lines, or in a couple cases had to use either included or added software drivers.  The upside of the software drivers is that the wiring is more flexible and can use CPU internal pullups, but the downside in this case is the software drivers are slower than hardware drivers.  It is recommended to use the hardware drivers if you can, but there are also software drivers available that work for all these platforms (Arduino and netmf).

 

The circuit was designed on the fly to quickly get up and running with I2C.  There are a few changes I would make to improve this circuit.

1. Remove the 3.3V pullup options.  These were not needed.
2. Add jumper for switching the entire circuit between 3.3V and 5V.  The EEPROM can run at lower voltages, and this would allow the shield to be compatible with non-5V tolerant platforms like the Arduino Due.
 

Schematic

EEPROM Shield

This shield was created to help learn SPI (Serial Peripheral Interface).  The hardware consists of an empty prototype shield for Arduino with a Microchip 25AA1024 EEPROM, jumpers, sockets, LED, switch, and discrete components.

This shield allows an microcontroller to store and retrieve up to 128K bytes of data using SPI at up to 20MHz speed.

The target platform was Microsoft .NET Micro Framework 4.1 as shown mounted on the Netduino Plus, and also demonstrated to work on the FEZ Panda II.  Source code for the project is posted at github in the form of a class library DLL and test application.  Note this code requires Microsoft .NET Micro Framework APIs and will not work on a standard Arduino.  Many others have written libraries for this chip for Arduino and other platforms.

The large array of jumpers allows configuration of the chip select line to one of digital pins 2-10.  The hold pin is pulled high and socketed to allow for future use, but is not wired to any of the microcontroller's pins.  The WP (write protect) pin is jumpered to allow it to be pulled high (disabled) or pulled low (enabled).  The circuit for the LED and reset switch was already present on the prototype shield.

A possible revision to this circuit would be to add a jumper for choosing 3.3V or 5V operation if it needs to be used with a board that is not 5V tolerant.  The boards I used run at 3.3V but are 5V tolerant. 

Future revisions to the source code could include supporting a wider range of EEPROMs from Microchip, SST, and other manufacturers, and/or porting the code to other platforms including mbed, chipKIT, PIC, and Arduino.




EEPROM Shield Schematic

Under belly of the shield

Individually Addressable and Dimmable Christmas Lights

This project was inspired by a Radio Shack print advertisement or similar article showing how to make a strand of Christmas lights using LEDs and an Ethernet cable connected to an Arduino controller.  I stole the idea and created the rest from scratch.



Christmas LED Shield

I found some large 1cm diameter LEDs that look like jelly beans at a local surplus electronics warehouse, and swapped out a black Ethernet cable that was in use in my house.  Having just completed assembly my Arduino Duemilanove kit, and being the middle of December, assembling Christmas lights seemed like the logical next project.  Originally I was going to place the LEDs 11 inches apart to use up the entire length of Ethernet cable, but my wife talked me into having them closer together, so after making cuts in the outer covering at 11 inches, I made additional cuts halfway between them, now every 5.5 inches. 

Curtain Rod Installation

The point of using an Arduino is addressing the individual LEDs.  As the Ethernet cable has eight wires, that could accommodate seven LEDs (seven lines of power, one common ground), so the original plan was to include seven and the Christmas Light Shield shown does support seven LEDs.  But the Arduino Duemilanove supports exactly six PWM (pulse width modulation) outputs at D11, D10, D9, D6, D5, and D3, so I settled on a six LED strand.  Each light can be individually dimmed to a resolution of 256 values (0=off, 255=bright).  This allows the lights to chase, flash, dim, and perform other light patterns.  Two inputs (in addition to reset) were added to the shield to control the nine patterns of the lights programmed into the Arduino.



The shield was built on a empty prototype PCB, with an attached RJ45 jack and corresponding breakout board.  The lines of the Ethernet jack were wired to the PWM ports using 500K resistors.  The switches were wired to inputs at D2 and D8 with 18K pull down resistors, and those circuits are wired to 5V when the switches are pushed.  The RJ45 jack turned out to be a great way to connect and disconnect the wires.

Merry Christmas!

Learning Surface Mount Soldering by Experience

Soldering together this Duemilanove (Arduino 2009 model) was my third attempt at surface mount soldering (first was FTDI232RL, second was PIC32). 

This was a roller coaster ride as it included a number of successes and failures.  Is it pretty? Not so much, but it works!  In the end it has been a success as the board works and I learned a lot. 

What exactly did I learn?

1. Dab some flux to the solder pads and tin them.  Heat the fluxed solder pad and apply a light coat of solder.  The flux and heat will suck the solder quickly so be careful to use little solder.

2. Use less solder, get the soldering iron hot enough, use a fine solder pitch, and a fine solder iron tip.  This board is a mess because I applied too much solder and many of the solders look horrible probably due to not enough heat.

3. Be careful desoldering.  I tried to clean up some messes with desoldering braid.  I wasn't very careful and tore off some solder pads.  This required three reworked lines.  You can easily see two, and a small one is in the top middle.  Using a continuity test mode of my multimeter and comparing a bare board with the board under test was very useful in isolating problems.

4. Order the right parts.  Double and triple check parts.  I ordered the bare Duemilanove PCB boards from Hong Kong via eBay, ordered most of the parts from Mouser, and some I already had on hand. 

But I ordered the voltage regulators in the wrong package size (8 pin instead of 3 pin), and ordered the corrected part from DigiKey.  But on the second try I had recorded a fuse part number for DigiKey, and ordered it blindly, and it turned out to be the completely wrong part - wrong value and wrong size.  I still don't have the right fuse.  And I never figured out the right diode.  It would probably take three or more orders to get the right parts.  In the end, I shorted the fuse and diode pads with bare wire, determining these are optional in this circuit design.  Also, I didn't realize I was out of USB sockets and had to purchase some locally. 

5. Order the correct quantity of parts.  I had three PCBs, and ordered most parts in quantity of five just to have extras.  For resistors and capacitors I ordered in quantity 100 to get the good price break and have extra stock on hand for future builds.  But the LEDs I bought only 10 and each board uses 4.  After losing one LED, and soldering one to a test board, I was short 4.  On my second parts order I splurged $8 to get another 100 LEDs.

6. I was able to use 20-pin breakaway sockets found at a local surplus warehouse to create the 8-pin and 6-pin sockets.  I had breakway sockets that already had indents per pin (not smooth), but those ones didn't match well with the standard ones.  Reading comments on SparkFun's site I learned that the standard sockets are created from the 20-pin ones even though they look smooth.  The only caveat is you lose one pin when you cut them (I used the cutter on my wire strippers), and if not done correctly you are unlocky and lose one of the pins you wanted to keep.  I was lucky this time.  Part numbers from DigiKey are also listed at SparkFun at the above link if you want them to cut them for you.

7. Reviewing the Arduino Duemilanove Eagle schematics and gerbers were indispensible for identifying parts and performing the assembly.  I was able to export the BOM from Eagle, but had to research most every part.  Also finding a high resolution picture of an assembled unit helped identify where to place the parts.

8. Soldering the FTDI part (FT232RL) was tricky to remember how to do it well.  It is a 0.65" pitch 28-pin device.  That's a lot of pins in a fairly dense package.  In the end, what worked best was dabbing just a tiny bit of solder on the tip of the iron.  Very very tiny dab.  And then applying the hot iron to the end of the fluxed pin.  Do every other pin, to let the hot solder cool before revisiting.  If I tried soldering consecutive pins or didn't have a steady hand, then the pins could short.  There still might be some shorts, but this design doesn't use every single pin, so I got away with a sloppy job again.

9. The Duemilanove can use an Atmel ATMEGA328-PU instead of an ATMEGA328P.  Since I ordered five CPUs, this saved me 68 cents per, or $3.40 total.  The difference internally is some additional low power idle statements yet doesn't appear required for Arduino programming.  To load these CPUs with the bootloader I had to follow some additional steps in addition to the standard tutorial on loading the bootloader.

10. Buying pre-built boards is much cheaper and efficient. It took me a week to build and test this, and multiple orders. Justing buying an existing board would have been much easier and cheaper.  But the experience is priceless.

11. I can do this!  Even with a cheap 30-watt Radio Shack soldering iron and a coil of lead-free solder.  Though I am considering purchasing a much higher quality iron.

12. Next step is to design my own PCB with a combination of through hole and surface mount components to balance physical size, price, and ease of build.  That will be another learning experience!

It works!  Shown with my thermometer board

USB PIC24 and PIC32 SPDIP Arduino

PIC24FJ64GB002 shown

Microchip has just released a SPDIP-28 PIC32.  This chip is pin compatible with the PIC24 which I have been developing for, and my latest toying has been with Arduino style boards, so I was determined to combine the two.

In the last week I have developed a prototype USB Arduino format board using a PIC24 or PIC32 as its CPU.  The Arduino format consists of the standardized 8 and 6 pin headers for I/O and power.  This was accomplished starting with an empty Arduino shield prototype board and building up as a PIC single board computer instead of a shield.  Now standard shields can be attached to this board.

The two CPUs I am targeting to support with this board are PIC24FJ64GB002 and the recently released PIC32MX220F032B.

The power circuit, ICSP (on left), and USB have been tested.  The PIC24 running a CDC (Serial over USB) project is recognized by the host PC.  Next step is to test the FTDI serial connector (on right), and all the analog/digital pins.  Following that is to add a crystal and capacitors to get USB support for the PIC32 (I wonder if I can do that on a shield?). All pins are exposed via the Arduino shield interface, so it is super expandable.  The red LED is for 5V power, and the green LED is for 3V3 power.  The button is the reset switch.  No user I/O are provided, must be accomplished by add ons.

The missing piece is the Arduino development environment support for PIC24 and this low end PIC32 chip.  That's a pretty big missing piece.  For now I can develop using Microchip's MPLAB 8 and MPLAB X.  I am hoping to use the chipKIT Arduino Development Environment for this board soon as it would be nice to program with Arduino sketches and C++. 

PIC32MX220F032B shown

Underbelly