A GPS adjusted clock

We recently got a new cable box.  The new box has a clock that is a little smaller than the old one, and my wife has a hard time seeing it. We had an LCD clock with huge letters but there just isn't enough light in the place we want it.

So, NE06 GPS modules are getting pretty cheap. Why not get some huge seven segment LEDs and build up a clock based on a GPS?  Turns out large LED displays are fairly hard to come by, and pretty expensive. Plus, all that wiring to all those pins is a pain.

Then it hit me: I have some TFT displays, not huge, but plenty adequate for inch or inch and a half high digits.  If I used the TFT, I wouldn't even have to build the board; I could use my serial graphics terminal board.

First step was to see if I could make huge letters without too much hassle (the largest font I have is only about 3/8" high).  The first whack isn't too bad. It will work, although I might yet do some prettying up of the font.

So, on to the GPS.

I started with my serial terminal code, which may have added more complexity than I needed, but it works.  This code fills a circular buffer with serial interrupts from the GPS and the mainline has to process the contents of the buffer. This makes missing characters less likely but it does mean the mainline is futzing with trying to understand whether there are characters in the buffer and identify the start and end of the GPS data.

Parsing the GPS data is tedious, but not especially difficult.  With the PIC32MX150F128B there is plenty of memory, so I can be pretty aggressive with my code.  Most of the code is the TFT library so the stuff I'm working on is pretty small anyway.

At this point I can get the time and coordinates (which I don't need).  I am displaying all sorts of values which eventually won't be used.

Next up is to get the date, and go through the tedious business of determining whether it is daylight savings or standard time. The correction is trivial but knowing when to apply it is a pain.

Following that I'll get after the PIC's real time clock calendar.  Supposedly the PIC can maintain the time to within a third of a second per month.  I'm not convinced can actually accomplish that, but adjusting it from time to time through the GPS should keep the time always correct.

Since even in the basement with overcast skies I can still see 8 to 11 satellites that might be overkill.  If I have too much trouble with the RTCC I might just skip that, but the next priority is the daylight savings time thing.

The code is currently partial, and pretty rough, but as always I keep everything in git and the current code is in gitlab:
    https://gitlab.com/PIC32MX/gpsTime.X

The board hardware is at
  https://gitlab.com/PIC32MX/tft-board-pcb

And the TFT library code at
   https://gitlab.com/PIC32MX/TFT.X

They will be updated as time goes on.

170807:
OK, so some code cleanup, and slightly larger digits, but still significant work to do:

The digits are actually a tan color, but it doesn't show in the picture.

170824:
And yet another little tweak.  After seeing the clock it occurred to me it would be a nice addition to the shack, too, providing it showed UTC as well as local.

Sooo.....

 Time to get on to making cases, perhaps.

The dsPIC-EL-GM

It has been a long time since I wrote about the dsPIC-EL-GM. This thing has turned out to be a very successful tool for me.

Over the past couple of years, this has been the platform for dozens of projects.  In some cases the entire project was done on the board plus a shield. In others, it became the prototype for a purpose built board.

The choice of the dsPIC33EV was a good one.  Besides being 5 volts, meaning inexpensive displays work with it, it is fast, available in a variety of memory sizes (32-cheap, up to 256-huge), has a huge range of peripherals, and PPS.

The decision to put connectors for shields on the board turns out to be critical. Most projects need an LCD.  Hand wiring all those pins from the PIC to the display, plus power and programming (which I seemed to always get wrong) tended to present a barrier to starting new projects. With the shields I can just grab a shield and get started, and all the tedious stuff is behind me.

Plus, by having a standard part, standard display/LED/button pinouts, I have built up a number of libraries that make getting a project started easier and faster.

There are a couple of features that turn out not to have been so useful.  The jumper allowing me to use PIC24EV parts hasn't gotten used very much. I was attracted by the low price of some of those parts, but the 33EV32 isn't all that much more expensive, and it has more memory and way more speed.

Also, I had added a connector offset slightly from the shield connectors to allow me to plug in standard perfboards. But the extremely low cost of custom prototyping boards made that less useful. The demise of Radio Shack also shoved that feature into obscurity.  It was a significant advantage to be able to run down to the corner to get a perfboard. Now that it has to be mail order, I just keep an adequate supply of prototyping shields on hand.

I have been tempted to build another PIC-EL for one of the PIC32s. The PIC32MZ series offers blinding speed, crazy big memory, and even floating point. By having a flexible platform, the need for a DIP package is mitigated, and the price of the MZ, while not cheap, isn't really crazy. I had a lot of fun doing a graphics card with the PIC32MX250F128B, so I feel like the PIC32 isn't that alien of an animal.  But that is a project for another day.

I am not trying to sell dsPIC-ELs. However, needed information for building your own is available on gitlab:

• Gerbers for the dsPIC-EL-GM are available here.
• And for the proto shields here.

We did kit a few for the high school electronics club, which necessitated creating detailed construction instructions:

• Build instructions here.

Should you build your own, let me know how you did in the comments below.

Serial Graphics Terminal

It has been a while since I last posted here, and there have been a number of fun projects under the bridge.

One of the more fun, with more work still planned, is the development of a serial graphics terminal.

Most PIC projects use an LCD for a display. It is cheap and easy, but it has pretty limited real estate, and it uses a bunch of pins.  For quick little test projects, you often spend more time hooking up the LCD than you do on the rest of the project. Serial LCDs are expensive, and don't solve the problem.

More recently there have been some relatively inexpensive TFTs available. Fairly small 320x480 displays have tended to be among the least expensive, but they take even more pins than the LCDs, and quite a bit more code.

Suppose we could connect one of those things up to the serial interface.  That would allow a competent display with only one or two pins.  If we put a lot of smarts into the terminal, the performance might be decent, and we might even end up with a small software footprint on the host project.

Unfortunately, there are relatively few PICs available in 40 pin DIP, and those that are tend to be pretty slow or have limited memory.  I wanted a fast PIC with gobs of memory in a DIP package that I could prototype easily.

By using the MCP23S17 I/O expander, I could get enough I/O to handle a TFT, and selected the PIC32MX250F128B.  Turns out that the PIC32MX150F128B is the same for this purpose, and cheaper, but at the time I could get the 250 quicker.

So I breadboarded up the thing, mounted on my breadboard dsPIC-EL as a test host, and the thing worked.

I developed first text terminal code, then graphics terminal code, and decided that a custom PCB would be worthwhile.

The serial performance, even though limited by the I/O expanders, is quite good.  I developed a graphics library for the PIC32 that the terminal code builds on. The board is capable of the things you would hope such a terminal would do.

One of the things that is a real pain is drawing decent graphs.  All the piddling around in getting the axes and legends straight is a major hassle, so I decided to put a graphing feature into the PIC32 so that a small host application could draw decent graphs.




The TFT library makes it tempting to do projects directly on the TFT board. Unfortunately, there are only a few pins left (which are brought out to a connector), but a simple logic analyzer was irresistible:

Although the performance is quite good, and for most things, even with a serial connection, speed is not an issue, there is one place where the performance falls down, and it is a common one: drawing a continuously varying graph like a strip chart recorder.

A strange thing about this particular TFT controller is that it takes as many commands (and as much time) to fill a rectangle as it does to draw a pixel. When drawing lines at odd angles, like a graph, each pixel must be drawn individually. In this case, the MCP23S17, even though SPI is running at 10 MHz, simply can't keep up.

A large buffer in the PIC32 mitigates this problem for finite lines, if you want to continuously monitor a variable at some point you overflow the buffer.  Even with a huge buffer, at some point it fills.  I have done some experimenting with XON/XOFF, but this requires more complex code in the host.


The next step will be to prototype something with the PIC32MZ1024EFH100 (the 100 pin part is necessary to get all the pins in a single register). If the prototype can substantially improve performance, then I will look at a PCB for that part.

Again, I have no plans in marketing this, but everything needed is in GitLab. PCBs can be cheaply made and all parts, except the TFT, are available from DigiKey. The TFT is a SainSmart 20-011-918.

Project Components (all gitlab projects except document):

•  PC Board
•  PIC32 Graphics Library
  
•  Graphics Terminal
  
•  Description of terminal protocol  (pdf)
•  A host library for the PIC24 

The following is a little video to give an idea of the performance of the serial terminal:

chipKIT

I recently picked up the chipKIT Max 32 and Basic I/O Shield.  My main interest was seeing whether we might possibly take advantage of the Arduino ecosystem.  There are literally hundreds of "shields" for Arduinos. The idea is that the board with the microcontroller has relatively few peripherals, and the experimenter can plug together a number of simple boards each with its own set of peripherals.


chipKIT Max32

chipKIT Max32

The Max32 has a PIC32MX795F512L which is quite an impressive part:

• 80 MHz
• 512K FLASH
• 128K RAM
• 16 Channel 10bit A/D
• USB 2.0 OTG
• 6 UART
• 4 SPI
• 5 I2C
• 2 CAN
• 10/100 Base T

The Max32 board also includes a USB to serial converter, 3 and 5 volt supplies, and 5 LEDs: 1 for power, 2 for USB send/receive and 2 connected to PIC digital I/O pins.  Power can be provided through the OTG USB connector, through the PICkit connector (not populated) or through a coaxial power connector.  Power provided through the connector can be regulated 5 volt or unregulated 9-15 volts.

83 PIC I/O pins are brought out to connectors on the board.

The Max32 connects to the PC via an OTG USB cable.  This has a standard Type A USB connector on the PC side, and a mini-USB on the Max32 side.  The mini-USB looks annoying similar to the ubiquitous micro-USB commonly used for cell phone chargers.  It is more or less standard for OTG USB, however, and is the cable used for the Beagle Board and PICkit, among others.


Basic I/O Shield

Basic I/O Shield

The Basic I/O Shield connects to the Max32 (or the smaller Uno32 or UC32 boards) through 4 connectors.

LED connected to OC1

The board includes 4 pushbuttons, 4 slide switches, 8 LEDs, a 32x128 pixel OLED display, a potentiometer, a temperature sensor and an EEPROM.  4 of the PIC32's output compare pins are brought to screw terminals on the board edge.  Another 4 screw terminals connect to those same OC pins through FETs.  A final two screw terminals connect to board ground and power for the four FETs.  A jumper allows for the Max32's power to connect to the FETs instead.

I2C connection

The EEPROM and temperature sensor are I2C devices.  The Basic I/O Shield's I2C connections don't line up with the Max 32's I2C connections, apparently because the Max32 matches the Arduino Mega format.  This means to use the temperature sensor or EEPROM the user must add two wires for the I2C connections.




Programming with MPIDE

MPIDE

 There exists an Arduino compatible programming environment, MPIDE, which can be used to program the PIC32 without the need for an external programmer.  The PIC32 comes preloaded with a bootloader which communicates over USB to MPIDE.

The environment is a clone of the Arduino environment, and most Arduino sketches run without modification.  MPIDE also includes a serial monitor, so serial data may be sent from the PIC and observed within MPIDE.

There are libraries for the various Basic I/O Shield peripherals in addition to the standard Arduino libraries, so using the temperature sensor, EEPROM or OLED display is a simple matter of making the appropriate library calls.  Of course, the switches, buttons, LEDs and potentiometer use the standard read/write digital or analog calls.

The compiler is quite slow, apparently because libraries are compiled on the fly.  Programming over the serial connection to the bootloader is also relatively slow, so development is relatively slow business.  In addition, there is no in-circuit debugging capability, although the readily available serial connection relieves this somewhat.

Although the environment uses normal Arduino calls, standard PIC references are available as well.  Of course, this would mean that the sketch would not be compatible with an Arduino.  But instead of
  digitalWrite( PIN_LED1, HIGH);
one could say
  _LATC1 = 1;
This doesn't seem like much of a difference either way, but consider setting several pins of a port to outputs:
  pinMode( 17, OUTPUT );
  pinMode( 38, OUTPUT );
  pinMode( 58, OUTPUT );
  pinMode( 59, OUTPUT );
versus
  TRISA &= 0xfff0;
(the Arduino commands reference pin numbers on the board, rather than anything related to the port).


Programming with MPLAB-X

PICkit 3 and Max32

PICkit clearance

The Max32 includes pads for a PICkit connector.   This is a simple, 6 pin, 90 degree header.  When this is installed the normal MPLAB-X techniques may be used with the board. 

This is considerably faster and allows for debugging.  If the developer wishes to return to using MPIDE, the bootloader must be reprogrammed using the PICkit, a rather simple process. When using the PICkit, there is not enough clearance to use either the OTG USB port or the coaxial power connector, so the circuit must be powered by the PICkit.



Programming Comparison

 It isn't clear to this writer that programming with MPIDE is any easier than with MPLAB, however, the small size and lack of features of MPIDE make the process less intimidating.  This is emphasized by the small size of the boards and the simplicity of simply having the board connected to the PC with no power cables, no programmers, no external additions.

In MPIDE, the user provides two functions, setup() and loop().  The main() function is provided by the frameworks.  While this fits the overwhelming majority of applications, it is somewhat limiting in some situations.  Nonetheless, it does provide some structure for the new developer.

Although the documentation claims that the environment uses C, there are some C++ features.  Some libraries, for example, are provided as classes so the user must instantiate the class in order to use the library.   Most of the standard functions, tho, are C functions, so attempts to use other C++ features could result in unnecessary complication.

The IDE places the user projects, or "sketches",  in a "sketchbook".  The sketches are easily available from the menu, making it quite convenient when small number of projects are available.  Many examples are also available from the menu, so it is easy to find examples when the programmer doesn't remember how some function is used.


Hardware Compatibility

The shields connect together through standard, wire wrap 0.1" spacing sockets.  However, the power connector is offset slightly from the other connectors, making it inconvenient to use standard 0.1" protoboards.  There are shield protoboards available, but that adds significantly to the cost of experimentation.

The PIC32 is a 3.3 volt device.  Most Arduinos are 5 volts.  All of the PIC32 pins are 5 volt tolerant, but the outputs probably won't provide sufficient voltage for most Arduino peripherals.


Overall Impressions

The Max32 is a very nice development platform.  The PIC32MX795F512L is an amazingly competent part with stunning speed and huge memory.  Programming is virtually identical to the dsPIC/PIC24 families.  The Basic I/O shield provides a range of peripherals that allow for significant experimentation, and the FETs allow for connection to motors, relays or other high energy devices.

However, the 3.3 volt format limits access to many devices, especially most Arduino shields.  The graphics OLED is a very nice (if tiny) display to play with, but in a purpose-built circuit the experimenter will almost certainly prefer an LCD, and there is no facility to learn this peripheral.  The particular display chosen does not seem to be widely available so that option is probably closed to the developer as well.

The cost, however, is attractive.  Including the OTG USB cable both boards plus cable come in at under $90 at the current time.  Most of the benefit could probably be gotten with the Uno32, saving about $20.  The Uno has considerably less memory and fewer I/O pins (42 vs. 83).  The Uc32 provides an intermediate step, combining the smaller size and fewer I/O pins of the Uno with the large memory of the Max, for an intermediate price.

All in all, a fun development environment, and not a bad way to break into microcrocontrollers, providing the user recognizes the limitations.