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.

Older LCDs

After the previous post on LCDs, I was reminded that it only covered current displays.  Getting from there to here was, in some ways, something of an adventure.

It is probably worth mentioning that when I say LCD, I am speaking of LCD Character Display Modules.  There are other types of LCD displays, both more and less elaborate, but for 90% of hobbyist projects we use LCD Character Display Modules.

My first exposure to these was an interesting board from B. G. Micro that contained an Optrex 20434 20 character by 4 line display, and a PIC that served as a serial to parallel converter.  This was also part of my introduction to PICs, and may well have served to get me interested.

This display from a standard parts house would have been quite expensive, probably in the $50 neighborhood, but B.G. Micro deals in surplus, pulls and other goodies, so although it was a little expensive with the board, it wasn't horrible.  If I recall, it was in the $25 neighborhood, about what a 16 character LCD would have cost at the time from the typical parts house.

The Optrex had some interesting quirks which probably turned out to be a good thing as it prevented me from being blindsided by later, less obvious, quirks.  You see, most LCDs at the time had 128 bytes of memory for the display.   Line 1 started at address 0, and line 2 at address 64 in that memory.  The Optrex was a little odd in that line 3 started at address 20, and line 4 at address 84.   If you went past the line length, line 1 wrapped to line 3, and line 2 to line 4.  Perhaps more curious, line 4 wrapped back to line 1.

For a long time I pretty much only bought LCDs from B.G. Micro.  They had a beautiful, backlit, 40x1 which made a perfect display for a Morse code decoder.  This was one of my first major PIC projects.  The original code was from IK3OIL, but he used a 16 character display, and he left out a number of Morse characters.  For a long time, improving that code provided many hours of PIC programming experience.

This display had another annoying feature that provided a memorable lesson in LCDs.  It was what was called a "low temperature" LCD.  What that really means was something of a nasty surprise.  You see, LCDs have a contrast pin on which you provide a low voltage, usually through a pot, to control the contrast.  On these "low temperature" LCDs, that voltage has to be negative.  Normally you don't have negative voltages laying around on PIC projects, so this required another supply.  Fortunately, the current demads aren't severe, so a simple charge pump can often do the trick.  Not insurmountable, but certainly annoying.

Back then it was critical that a display had a Hitachi HD44780 controller.  Any other controller and the code was likely to be a problem.  The controller was almost always visible on the back of the LCD, so at a hamfest you could usually tell what you were getting.  More recently, the controllers are potted, so you can't see what they are, but HD44780 clones have gotten a lot better so it is no longer an issue.

B. G. Micro had a cheap 16-character LCD they called a "Medical LCD" as it was pulled from some piece of medical equipment.  They had a plastic bezel in an odd shape that could not be removed without destroying the display (although it could be filed down to something sensible), and the connection was a very obnoxious cable with 0.05" spacing, making it very hard to work with.  But they were cheap.  At the time they were $3.  It is a lot easier to experiment with a three buck part than a fifteen buck part, so they became the display to use for quick experiments.  Although the physical aspects of this display were annoying, it turns out the display itself was quite nice.  B.G. still occasionally has this display, and the most recent price was fifty cents!

When the original PIC-EL came out, it had an 8 character display, quite a nice display if somewhat limited in size.  The display was not backlit - the green color is due to a green reflective background behind the display.

The original PIC Elmer lessons worked within the confines of this 8 character display.  Although a lot of applications require more characters, the limited 8 character display wasn't too much of a problem for lessons, and it did provide an excuse to demonstrate techniques like scrolling.

Quite soon after the introduction of the PIC-EL, the 8 character display was replaced with a 16 character display.  While a lot more flexible, this turned out to be something of a problem.

You see, the Hitachi HD44780 controller could not display a 16 character line.  To go beyond 8 characters required the addition of an HD44100.  This was fairly expensive, although the "cheap" medical LCD contained this addition.  To get around this, many early 16 character displays were actually two line 8 character displays, with the two lines side by side.  This required some programming gymnastics, and of course, code that worked on these displays would not work with a "proper" 16 character display.

Later PIC-ELs had a backlit, 2 line by 16 character display which AA0ZZ was able to get at very attractive quantity prices.  These are quite a bit nicer, and in fact, almost all current LCDs avoid a lot of the quirks of the older displays. Prices have dropped quite a bit as well.  Backlit LCDs, which used to start in the $20 neighorhood, can now be found for around $10, even from the major suppliers.  Cheaper houses like B.G., Sparkfun, etc. often have some very interesting displays for half that.  White or blue backlights, which can look a lot nicer than the traditional yellow-green are often inexpensive and take quite a bit less current than the older displays as well.

Displays

For some time now I have had almost an obsession with LCD displays.  In the past, there was a wide range of displays with a wide range of prices, generally more characters being a little more expensive, backlit displays being very expensive.

The most common backlight was the sickly, yellow-green LED backlight, which not only looked bad, but tended to be a real current hog.  Electroluminescent backlights were available, but they tended to require unfortunate voltages; typically AC and somewhere in the 60 to 400 volt range, not generally what we have lying around on a microcontroller project.

More recently, white LED backlights which are far more efficient have become available.  And, they have become a lot less expensive.  It seems as if a white backlight is often available for close to the cost of a non-backlit display, and while a yellow-green backlight may take almost an amp, the white ones tend to be in the 20 mA neighborhood.

N8ERO picked up some Newhaven negative displays which show white letters on a blue background.  I had seen these before, or something similar, on some FDIM projects, and while they don't look as nice as their pictures, they do look a lot better than the ugly green.

LCDs exhibit two kinds of slow.  The processor on the LCD takes some time to do it's thing, so code either has to delay or read the LCD's busy signal.   Reading the busy signal is kind of a pain, so most hobbyist projects simply wait long enough.  The actual display itself is a chemical change, so compared to electronics, it is very slow.  A result of this is that there it rarely a real penalty for waiting far longer than necessary for the display's processor to do it's thing.

However, in experimenting with different displays, it appears that negative displays are slower, as are 3 volt displays.  In the case of the blue Newhaven display, part of this slowness results in some rather ugly brown artifacts when the display is changing.

I found a blue, positive Newhaven display that was very inexpensive, but 3 volts.  3 volts is pretty handy for PIC24, PIC32, or dsPIC33 projects, not so much for the more common 5 volt projects.  This display is quite small, something that is also sometimes nice.  LCDs tend to take a lot of the panel space, and depending on the project, having a 20x2 display in a small space is an advantage.  However, small also means that the connections to the part are different than most LCDs, and kind of a pain.





Well, with LEDs now available in umpteen colors, and plummeting in price, it couldn't be long before someone came up with a display with an RGB backlight.  I picked one up, the price, while a little high, wasn't crazy.    This display is, interestingly, a 3 to 5 volt display.  Unfortunately, the 3 volt part means it is slow, and the negative display, which looks a lot nicer, makes it even slower.  This is a pretty slick choice for projects that have a display that mostly isn't changing.

More recently, displays based on organic LEDs have become available.  OLEDs have the advantage of very nice contrast, high speed, and relatively low current compared to backlit displays.  This particular OLED display has both the traditional 4 or 8 bit parallel interface as well as a serial interface.  I have to say, I think this one is my favorite.  It is slightly thinner than the LCDs, and the display is extremely crisp.  And it doesn't exhibit any of the shadow artifacts that LCDs tend to show when they are changing.

The one downside is that it appears to require that you use the busy flag.  While this is annoying, especially when using the 4 bit interface, once the code is written and wrapped in a library, that detail becomes invisible.  It is a little more expensive than an LCD, but boy is it nice.

I2C Tinkering

A couple of posts ago I mentioned I2C.  I2C is a scheme for communicating with smart integrated circuits.  It is a bus arrangement where multiple devices are attached to a two wire bus, each device having a unique address.  This is very appealing in that it allows a lot of devices to be connected while using few pins.

Part of the incentive here is to have a fast digital to analog converter.  It seems inappropriate to talk about a microcontroller containing a DSP engine without using the DSP.  Yes, we could do DSP calculations and display the results on an LCD or transmit them to the PC, but really, you would like to take audio from the radio, process it, and send it out to a speaker or amplifier.

Both of the dsPICs under consideration have A/D converters that are plenty fast for our purposes, but microcontrollers tend to be light on D/A capabilities.  In most cases, however, there is a pulse width modulation output of sufficiently high frequency that it can easily be filtered to provide an analog voltage.  This is fine if you want a DC voltage, but after filtering you are left with quite a low frequency AC.  Probably not fast enough for our purposes.

Some years back I had done some unsuccessful experimentation with I2C, but this was done with 8 bit parts which are much harder to use.  So it was time to do some more I2C experimentation to see if we could get an A/D that we could use for audio output.

I2C Test Board

I acquired three I2C devices; an MCP23008 I/O expander, an MCP4726 12 bit DAC, and a MB85RC16V FRAM.  The DAC is obviously what we are interested in, but the I/O expander provides a very simple, easily visible, way to see that I2C is working, and the FRAM, while not especially useful for the 30F series of micros, could be quite handy with the 33F, 33E and PIC24 families.  In addition, the FRAM provided a third device to test I2C and more significantly, from another manufacturer (Fujitsu makes the FRAM, Microchip the other two devices).

I built up a board with a dsPIC30F4013 and the three devices for testing.  If the I2C communications works out to be straightforward enough, I could put it on the "dsPIC-EL" and the loss of debugging capability for just I2C experiments might not be too high a price. (see the November 8 post, http://elmer166.blogspot.com/2012/11/decisions-decisions.html)

DAC on adapter board

The DAC was in an SOT-23 package, a mere 1.5 by 3 millimeters, which made soldering it to a FAR Circuits adapter board a bit of a challenge.  Worse, the adapter I had was for an SSOIC which has slightly wider pin spacing than an SOT-23, but close enough that it could be fudged.

After some initial struggles, I got the 23008 working and was able to use the same basic routines for the DAC with no drama.  The DAC was kind of interesting in that is is the simplest of the devices, but had the fattest datasheet.

The FRAM caused me some consternation.  The I/O expander can be tested merely by putting some LEDs on its outputs, and the DAC with a voltmeter.  But the only way to see that the FRAM was doing it's thing was with the debugger and initially, it wasn't.  Eventually I discovered that I had a cold solder joint on the FRAM, and once that was corrected, it behaved as expected.

I put all the tests in a git repository (https://gitorious.org/elmer166/ztest-4013-i2c-tests) with a branch for each test.  After moving the I2C routines into a library, I made separate folders for libraries and include files.  I need to come up with some sort of convention for "local" libraries and includes; putting them into the xc folders risks loosing them on upgrades, but most other possibilities seem to have rather ugly paths.

So, on to more considerations.  After all this, it appears that the I2C DACs aren't going to be fast enough, either.  The MCP4726 can take I2C at up to 3.4 MHz, but it requires extra bits to go beyond 400 kHz, further slowing the device.

I've avoided SPI because of the extra pins, but it does look like an SPI DAC is going to be the answer.  Microchip's SPI DACs are cheap, and have a very compact protocol, and can take data at up to 20 MHz.  Whether we can actually pass 20 MHz data on an ugly, hand wired board is another question.  On the other hand, SD cards also take SPI, so that might lead to another interesting set of experiments.

So it looks as if the next move is to order some SPI DACs, probably MPC2822s or something similar.

git

Years ago, back in the late 90's, I built a CW decoder designed by Franceso Morgantini, IK3OIL.  It may be that this project actually got me interested in developing on  microcontrollers.  Not being able to let well enough alone, I made a  number of improvements (IMO) to Francesco's work.  And I reported it on my amateur radio web page.

I have always been a proponent of revision control systems.  Over the years I have found I often want to ressurect old code for some reason, and having an RCS not only made it easier to find old stuff, but also to understand what it had been through, something especially helpful if you intend to hack it up.

Back in the late 80's, it was PVCS on DOS and later Windows.  PVCS, it turns out, was a proprietary port of the ancient RCS to DOS.  Eventually the repository format changed to something more proprietary, and I began developing on more platforms, so I ended up moving most of my old PVCS repositories to RCS.

RCS stayed with me for years and years, through DOS, Windows, OS/2, Linux.  VMS had it's own system, CMS, which was actually pretty good so while I believe I ran RCS on VMS a little, it was never bread and butter on  that platform.  RCS had many, "better" descendants, CVS, SVN, etc., but RCS stuck with me since it did the job and  was available on every platform known to man, much like my beloved Emacs.

Somewhere around 2004 I realized that my PIC code really needed to be in a repo, so I reconstructed as best I could the history of my major PIC projects into RCS.

The PIC development platform, MPLAB, underwent many changes over the years, but the change from MPLAB 5 to MPLAB 6 was pretty major, and I wasn't able to reconstruct the links between those lines of development, so I made separate repos for MPLAB 5 development and MPLAB 6, 7 and 8 development which I prefixed with MPLAB_5 and MPLAB_7.

A few years ago I discovered git.  git has a few regressions from RCS, but it is so much easier to use that the incentive is to use it more.  So all my repos got converted to git.

Unfortunately, at the time, I hadn't yet learned the beauty of branches.  Recall that on RCS and it's descendants, branches are a major pain, so it took me some time to warm up to them.

But when I converted my repos to git, the independent repos from RCS got converted to independent repos on git.  With the MPLAB 5 vs. 7 stuff, it would have made much more sense to have branches, but I didn't know that at the time.

Circling back to the CW reader, from time to time I get a request for that code, especially since Francesco's original code has apparently disappeared from the web.  I recently got a request from a ham in Scotland, and when I grabbed the code for him, I realized I had been sending out the old MPLAB 5 code, which probably made life difficult for folks wanting to use it.

So, I duplicated the MPLAB 5 repo, and made a branch for the MPLAB 7 stuff, *AND* put it all in github, along with a rather elaborate README, so that folks could grab the code from there and if they needed some earlier variant they could see the genesis of the thing.

All this came just as I was struggling with getting a dsPIC30F4013 to talk to an MCP23008, and had just had the aha moment that even though this is a hack and of no permanent value, it still makes sense to put it in a repo and commit like a man posessed, so when the change to make B work causes A to quit, I can easily go back and see where I shot myself in the foot.

git is great!

Which brings me back to Elmer 166.  It is clear to me that anyone who thinks he can do serious development without git is either brain dead or a masochist. So it looks like something I should cover.  On the other hand, it is kind of off topic.  And the folks likely to take the course are probably somewhat unlikely to warm up to it, unless I can present it in a really appealing way.

So, more decisions.

Decisions, Decisions

Although I view the choice of build/buy as somewhat open, we have been proceeding on the assumption that we would build a dsPIC-EL, and that it would involve some sort of 40-pin dsPIC30F.

We initially chose the dsPIC30F4011for a number of reasons:

• It had the largest memory available in a DIP package
• It had a complete set of peripherals, especially including a large number of output compare ports which can be used for a flexible PWM
• It had a fast A/D

 But as we continue to look into the experiments we would like to run, we see an issue - the I2C and SPI pins are shared with the programmer.

This means that we either cannot use the debugger with I2C, or we need to provide some sort of jumpering mechanism or an additional programming connector in order to do in-circuit debugging.  Even if we provide the extra hardware, its use would be clumsy at best.

It would be good to have a lesson on I2C in the first place, and even better, the addition of some sort of I2C DAC might make for some interesting digital filtering experiments.  SPI is used for SD cards, so that also holds some promise for logging experiments.

The dsPIC30F4013 does not have this problem.

However, it has a slower (although higher resolution) A/D.   For the kinds of use we envision, the higher resolution isn't much of an advantage, and it takes very careful hardware design to effectively use all the resolution, so that A/D isn't much of an advantage.  Using the higher speed of the 4011's A/D does take a little care in the software, but it really isn't so burdensome.

The 4013 has the same memory as the 4011, and other than the A/D, a very similar set of peripherals.   One annoying feature; on the DIP dsPICs, there are no ports with all the pins implemented, and in the case of the 4013, PORTB is the only one with at least 8 contiguous bits.  Of course, the programming pins have to be on PORTB making it difficult to use all 8 bits.

However, there are no plans to actually need 8 bits of a port, even though it seems as if that is something almost necessary.  It would be nice to use an 8-bit interface for the LCD, thus simplifying the LCD code, but there is really no advantage besides a few lines of code. 

So, still more stuff to think about.

Moodle

I've been doing some tinkering with Moodle as a way to deliver the course material.  Moodle has some cool features, and it could be quite good for this sort of thing.

Some of the Moodle advantages are:

• Assignments like "Write a program to ..." can be made
• Each segment can have an associated quiz
• There is a forum in which students can have discussions about the course
• There are mechanisms to provide fedback to users
• Users can easily see their progress through the course
• The course developer can see what is working and what isn't

But I also see a couple of significant deltas:

• Users must be online to follow the course. Most likely a significant fraction of the intended audience has dial up or pays per connected minute.
• It is significantly more work
• I haven't found a reasonable way to be able to put up a sample on my LAN and share it outside for comment.  I can have one or the other.  This seems to be a common problem among FOSS packages. In theory, I could put it on elmer166.org, but I'm reluctant to do that.

So yet another decision.

dsPIC-EL or Explorer 16?

Back in June, I walked through a sequence of exercises with another amateur, W8LSS, on the dsPIC33FJ256GP710 using Microchip's Explorer 16 Development Board.

More recently, my thoughts have been along the line of building a "dsPIC-EL" board for the student.  But in organizing the various repos of code associated with this project, I got to wondering if perhaps the Explorer 16 might not be a better choice.

There are two main disadvantages, and one more minor, to using the Explorer 16 instead of a purpose built board:

1. Cost - the Explorer-16 would cost the student about $50 more than the estimated price of a dsPIC-EL, perhaps a little more.  Since the dsPIC-EL is estimated to cost more than the PIC-EL and does not include a programmer, the project cost to the student is already fairly high.  Adding to it seems to be a poor plan.
2. The Explorer 16 uses 3.3 volt parts.  The intent with the dsPIC-EL is to use a 5 volt part which is somewhat more hobbyist-friendly.  Also, although dsPIC33's and PIC24's are available in DIP, students seem reluctant to move past the part they learned on, so that could be an impediment to later experimentation.
3. The LCD display on the Explorer 16, although it uses more or less standard code, has some features that are lacking in typical LCDs.  This could mislead the student.  Worse, not all Explorer 16s have the same LCD.

But there are advantages, too:

1. The Explorer 16 is available already.  There is no design work needed, no new circuit board to be developed.   Part of our thinking is that we might talk AA0ZZ into building and marketing a dsPIC-EL.  Although he seems receptive to the idea, we still haven't heard that he is actually willing. (In fairness, we haven't pressed, either, preferring to have more content available before moving ahead).
2. The Explorer 16 comes with both a dsPIC33 and a PIC24, giving the student the ability to explore both families.
3. Microchip provides low cost "PICtail Plus" prototyping boards, giving the student the opportunity to haul out the soldering iron and add his own ideas.  In at least one of the experiments I did with W8LSS we did just that.
4. Because of the large pin count format, the board has more peripherals to play with.
5. Microchip provides a number of additional PICtail Plus boards for a variety of purposes which might interest the advanced experimenter.
6. I already have a pretty good series of exercise programs in place and tested with W8LSS.

I think I'm still leaning toward the dsPIC-EL idea, perhaps because it seems like a logical follow on to the original PIC-EL, which was amazingly successful.  But at this point there is still nothing cast in stone.

Web Presence

For a few weeks now, I've been sending content to N8ERO for comment by placing in it in a directory deep inside another site.  This generates ugly URLs, uncertainty about what is what, and questions about why it is that way.

So, it was time to get an elmer166 domain.  For the time being it is simply a place for "stuff".  There isn't anything terribly polished there, but it should make it a lot better for finding things and sharing with others besides Earl.

Making Progress

With the help of N8ERO, I have been making some progress in sorting out some of the content.  Although I am capturing it in the form of a book, I'm not so sure that  will be the final format.

It might be nice to publish an actual book. I suspect a lot of folks would still like to see actual paper.  But I would also like for people to be able to access it free of charge.  Jared Smith has published books licensed as CC-BY-SA, which is how I would like to do this course.  I need to touch bases with him.

The Elmer 160 course was released as a series of PDFs, one for each chapter.  That might not be such a bad plan for this one too, but it makes things like cross references and indices somewhat problematic.

It might even be preferable to release it as a series of YouTube videos, or perhaps on online course on Moodle.  even if it is released as a document or documents, I think a few videos in support would be a good thing.

At this point, much of what is there is somewhat fragmented.  I have a good set of screenshots and prose around creating a project in MPLAB-X.  I have an initial program.  The plan is to do a simple blink a LED, but in multiple steps:

• Write  a loop that toggles the LED pin.  Run that program through the MPLAB-X simulator and see the port change.
• Run the program in the dsPIC-EL.  Observe that the LED stays on.
• Recognize that the LED is blinking too fast to see.  Insert some delay loops to slow things down.  This is an opportunity to introduce functions and refactoring.
• Instead of delay loops, use the dsPIC timer.
• Instead of hovering over the timer, use an interrupt.

I also have the beginnings of a quick intro to C, and a number of tables that required research.  There are lots of details folks might ask like "where are these include files?", "what are all the data types?", and "what are the differences between the different PICs?".  All of these require digging up the associated data.

Elmer 166?

I am considering an Elmer 166 course, possibly including a “ds-PIC-EL”

The Elmer 166 course would introduce the student to using the Microchip 16-bit PICs programmed in C.  The focus would be on the dsPIC30F series of parts, but the entire range of 16 bit parts is quite consistent from a software perspective.  The 30F series is a 5 volt part, making it a little more comfortable for hobbyists. (The other 16 bit families are 3.3 volt).  the 30F runs at up to 30 MIPS, making is quite fast for most control projects.

The proposed dsPIC-EL would utilize the dsPIC30F4011 which is a 40 pin part which includes 48K of Flash, 8K of RAM, 30 I/O pins, 2 UARTs, 1 SPI port, one I2C port, 4 CCP/PWM ports, 6 motor control PWM channels, a quadrature encoder interface, 5 timers, and a 9 channel/1ksps A/D converter.  With the commonly available 7.3728 MHz crystal, the 4011 will run at just over 29MIPS.  The 7.3728 MHz crystal has the added advantage of dividing directly to most common serial baud rates.  The dsPIC30F4011 currently costs $5.70 quantity one from Microchip Direct.

The image at the right is a partially completed prototype.