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.