Dual-core development board

So a while ago, I discovered the dsPIC33CH family of dual core digital signal controllers (dsPIC33CH128MP505).  I did considerable tinkering with the proto board I was using, and it was becoming clear that this is a nice part. I took it being a 3V3 part as kind of a downside, but there are more and more 3V3 peripherals, which is one reason I kept hacking up that proto board to try yet another thing.

So my dsPIC-EL-GM solved that problem for the dsPIC33EVxxxGMy02 parts (and some PIC24 parts, too).  I've probably done hundreds of experiments with that board because the shield makes it so easy to start a new project. In spite of custom shields being a fraction of the price of commercial proto shields, I still tend to tack on project after project, and have found it necessary to label the shields so I don't get frustrated with the wrong connections.

Custom Proto Shield

So the idea of a experimenter's board for the dsPIC33CHxxxMPyzz was born.  Problem is, the 33CH isn't available in DIP. I'm not frightened by the prospect of soldering a TQFP, but laying out the PCB was another thing entirely.  My original thought was to design for the MP505 (48 pin) part. But I didn't have a TQFP48 footprint, and I wasn't real confident I could make one.  With the 64 pin part, I could populate all the Arduino headers without sharing pins with onboard peripherals.

But it isn't all sweetness and light. The dsPIC33CH512MP506-I/PT is in a 10 mm package, which means there are a whole lot of pins real close together. By itself that wouldn't be a real big deal, but you need to DO something with those pins. And that means you are going to need vias, and vias take space.

Vias

As I got the board laid out, I got lots of errors that the foils were too close, but in many cases, there didn't seem to be a lot I could do about it. Eventually, I got the first attempt at the board laid out.

PCB image from layout program

It had been a while since I had a PCB made, and in the interim, my favorite manufacturer quit making custom boards. And then another couple of surprises.  Many fabricators won't make boards with traces a tight as I had, and many of those that would charged a premium. Another surprise; it used to be that I could get a board made stateside for about twice what a Chinese board cost. I could have it in about a week, as opposed to three weeks for Chinese. Since then, Chinese prices dropped a little, Chinese fast shipping got more realistic, and U.S. prices exploded.  Stateside boards now cost more than ten times what a Chinese board cost.

I did find that JLCPCB would do my board without a premium, and I could get shipping for a sane price. I could get a board shipped from China in one day longer than it used to take for U.S. boards, and half the price that the U.S. boards used to cost. To add insult (to the U.S. fabricators) to injury, they have a nice web site that lets you watch the progress of your boards through the manufacturing process, and they have an apparently very thorough board checking before it goes to manufacture. It took me several cycles to get it right, and more than once they emailed me with questions; once I did something odd but meant to, another I had an error and was able to correct it before the board went to manufacturing.

Completed Dev Board (no shield installed)

Since much of the challenge was getting the traces routed, I actually laid out the board without a schematic. Yes, there were a couple places I shot myself in the foot, but all in all, it wasn't too bad.  I figured I should have a schematic too, and got to work on that. Turns out the schematic for something with all those legs is almost as fraught as the PCB.

Schematic

I don't know if I'll think of other things that need to be done to this board.  A version of my Serial Graphics Terminal that avoids the use of I/O expanders has been on my radar for some time, but that requires the use of a TQFP100 part. This board may well give me the confidence to go ahead and attack that.

For now I have some playing with 3 volt gesture sensors I want to do.

As always, the gore is in gitlab.

An improved dsPIC-EL-GM

It was way back in 2012 when I first started thinking about a dsPIC-EL, but it was 2015 when I finally broke down and sent a PCB to production.  Since then the dsPIC-EL-GM has been the foundation for dozens, maybe hundreds of projects.

Recently I find I am dealing with many more 3 volt parts, and I often end up building a 3V3 supply on whatever shield I am making at the time.  The basic board has plenty of proto space which I never use, so why not sacrifice some of that for a 3 volt regulator?  The Arduino shield has a pin for 3 volts, so that wasn't a big deal.

3V3 supply

Turns out to have been a pretty simple change, and I was running out of boards and probably would need to order more anyway.  The one disappointment was that I paid extra for DHL shipping, and due to customs delays, Chinese holidays, etc. the board took almost as long as free shipping. Well, that and Maker Studio no longer makes custom boards so I had to search out other suppliers.

Things have changed over the past few years. The price of Chinese boards has come down a little, but the price for U.S. made boards has exploded. It used to cost less than three times as much for a U.S. board over a Chinese board. Now it is more than ten times. Plus, I can get Chinese boards just as quickly as U.S. boards, so even paying a premium for fast shipping, they are still a lot cheaper.

One minor annoyance in the old board was that the contrast pot for the LCD couldn't be adjusted when a shield was in place. I tried drilling a hole in the shield, and even laid out a new shield PCB (but never ordered it).  It occurred to me that I could fit a vertical pot under the LCD.

New contrast pot location

With that change, I could now adjust the LCD contrast without messing with the shield.  (Yes, I know, how often do you need to do that. Well, I play with various LCDs, kind of a fetish I have, so I probably twiddle that pot more than the average bear.)

While I was at it, I decided I would change the bypass caps out for SMT caps. Don't know why, I have hundreds of 0.1 and 0.01 monolithics in the parts drawer, but it seemed like the thing to do.  What I didn't do is change out the resistors, which I probably should have.

dsPIC-EL-GM full board

The other thing I really should have done is used SMT LEDs. The 5mm LEDs sometimes get in the way. On one instance I did tack SMT LEDs on to the through hole pads, and that worked quite well.

I'm pretty pleased with this board. Although there are a few things I would like to change, nothing is really pressing, so probably this will be the last change for a while.

As always, the PCB file, Gerbers, etc are all in gitlab. This version is in the Rev2 branch.

dsPIC33CH128MP505

Why?

So back in June, AB Pearce mentioned on the piclist that Microchip had introduced some dual-core PICs.  Apparently they had been out for some time, and talked about in the Microchip forums, but I hadn't been aware.

So I did a little exploration, they look reasonable, checked out the pricing on Newark and Digikey, and ordered a couple dsPIC33CH128MP505 and a dsPIC33CH128MP506. I didn't really have the time to play with them, but I figured might as well have them on hand for whenever I did find the time.

Of course, the bright, shiny things kept calling, so more important things got pushed out of the way to play with the dual-core dsPIC.

Description

For my testing I selected the dsPIC33CH128MP505; with only a few LEDs and maybe later something else, there seemed to be no reason for the 64 pin dsPIC33CH128MP506.

The dsPIC33CH128MP505 is a 48 pin part, I ordered it in TQFP because I had some TQFP adapters that would work and there were no DIP parts.  The master core is more or less as expected, 128K of flash program memory, 80 MIPS so a tad faster than my favorite dsPIC33EV.  The slave core has 24K of program RAM, and at 100 MIPS is slightly faster still.  Obviously, since the slave program memory is RAM, the slave program has to be loaded by the master, so it needs to be stored in the master flash.

Each core has its own set of peripherals, slightly different from each other.  All input pins are accessible to both cores, but outputs must be assigned to one core or the other. Like other dsPIC33's, the peripheral complement is huge.

There is the typical set of PRI, FRC, LPRC oscillators, with or without PLL, shared by both cores. Each core can select the oscillator and has its own PLL chain. The PLL chain is slightly different from the dsPIC33E, but conceptually similar.

One interesting thing is that the datasheet indicated that the outputs can drive LEDs without the need for current limiting resistors. On my test board I used them anyway, because that's what I do.

Test board

In order to do something, I built up a simple test board. I generally power my PIC projects with a cell phone charger which provides 5 volts, so my board needed a 3.3 volt supply. A connector for programming, some assorted caps and resistors, and a few LEDs were all that I needed to hack together something to play on.

I am generally a little cavalier about bypass caps on prototyping boards, but in this case, the processor wouldn't run until I sprinkled a few around in obvious places. That is actually the first time I ran into that.

Programming the master

Getting the master to blink an LED was no big deal. The only surprise was that there are an incredible number of configuration bits. The bits are shared between master and slave. Many apply to both, but there are some that are specific to the core. All are provided in the master core's program.

Besides the fuses you might expect, every pin has a fuse to assign it to either the master or slave. There is a data direction fuse for each of the mailbox registers. There are also bits to enable each of the mailbox protocol blocks and to assign them to a mailbox register. Each of the four sets of alternate registers can be assigned to an interrupt level. The master and slave can each have independent ICD communications pins.  All in all, an intimidating set of configuration fuses.

Once you get past the shock of the configuration bits, programming the master is unexciting, as long as you are only programming the master.


I did set up the master and slave program projects as subdirectories of a sort of master directory, and placed both projects in the same git repository. Although small repos are generally better, in this case the master and slave are closely linked, so it seemed to make sense.

Programming the slave

Getting the slave to run is quite another can of worms. There is, of course, the datasheet, the Family Reference Manual, and an application note, AN2721, which has some associated sample code.  Even with this documentation, there are a number of secrets that aren't obvious.

The documentation seems to indicate that the slave program must have the same name as the master's, followed by S1. This doesn't seem to be a requirement, although I haven't tested that supposition. What you do need to do, though, is select a processor name followed by S1 when creating the slave project.  So the project for dsPIC33CH128MP505 is the master program, and the slave program uses dsPIC33CH128MP505S1 as the processor type.

Since xc.h takes care of the processor, it isn't 100% obvious that there are also two header files, p33CH128MP205.h and p33CH128MP205S1.h, which becomes important because often the headers need to be explored to understand what the documentation means, or more often, to fill in the blanks.

Everything is slave 1 this and slave 1 that, so it appears Microchip is leaving the door open for parts with more than one slave core. Since the slave program has to be stored in the master's flash, it would seem that multiple slave versions are going to need an awful lot of flash.

The slave core's program is loaded with a call to _program_slave(), obvious enough, and the slave started with a call to _start_slave(). Also seems fairly obvious. However, the _program_slave() call takes three arguments. The first is the number of the slave. The second is whether the program is to be "verified", whatever that means. The final is the address of the slave program.

And that's where it gets interesting. When creating the master project, a new folder, "Slaves", is created. The slave project must be added to this folder in master. So far, makes sense. If the slave program is going to be stored in the master flash, the master needs to know that it needs to be linked in.

The address in the master flash can be specified in the slave project properties in the Slaves folder. But, referencing that address in the _program_slave call doesn't work!

The examples from Microchip all use the slave project name in the _program_slave() call. However, simply stuffing that in doesn't work. The examples always included the slave's include file in the master's mainline, which I assumed somehow declared the symbol. But I could find no combination of attributes that worked. Worse, in the example code, I could never find that particular include file.

It turns out that referencing the slave's include file, even though it is in another project, does the trick. The include file can even be empty.  I suspect it might not even need to exist, although I haven't tried that yet. Also note that _program_slave() and _start_slave() are defined in libpic30.h.

Once that was in place, I was able to flash an LED from the slave. But to understand that the master and slave were both working, I thought it would be helpful to start and stop the slave.  While libpic30.h defines a _start_slave() function, there is no function to stop the slave.

The slave is started by setting the SLVEN bit in the MSI1CON register. This register, like the EEPROM in the 8 bit parts, requires an unlock sequence. Since I may want to do this in the future, I wrote a stop_slave() function.

I did find it rather curious that the assembler played like a compiler a bit, and modified my code. Where I cleared the SLVEN bit (bit 15) in the MSI1CON register, the generated object code cleared bit 7 in the MSI1CONH register, apparently saving a little time.

I was now able to start and stop the slave as needed.  In theory, one could have multiple slave programs and switch between them under master control. In this case it would be important to be able to stop the slave. Lacking a stop_slave() function in libpic30 seems like a significant oversight.

Mailbox Communications

Now that I could program, start and stop the slave, the next step is communicating between the two. So on to sending data from the master to the slave. There are two ways to do this, through mailboxes or through a FIFO. I decided to try the mailbox first.

Slave Output

Being able to understand that I was successful in sending data from master to slave was going to take more than an LED as a way to let me know I was successful. Previously, I had built a PIC32 based Serial Graphics Terminal  for just this problem.  So I added a connector for this terminal and a litttle code to communicate.

Unfortunately, I had some hassle with this. I'm not sure whether I forgot some initialization or didn't have the baud rate quite right, but the objective was to try out the mailbox communications, not debug the terminal, so I fell back to my
Simple Terminal which only does text. Since this application is really dumb and has no cursor control, it is fairly slow, but adequate for this purpose.

Mailbox Communications

The 33CH provides 16 mailbox registers which are visible to both master and slave. They are unidirectional; each must be assigned as master to slave or slave to master.

There are up to eight protocol blocks. A protocol block is a sequential group of mailboxes going in one direction. The final mailbox in the group triggers the transfer. Again, more configuration bits to enable a group and assign the register.

You can see how we come up with over 100 configuration settings.

Once the configuration bits are set, the exchange is fairly easy.  The master enters the data into the mailbox registers, taking care to load the last register in the handshake block last. Writing the last mailbox sets the data ready bit for the slave.

Master then waits for the data ready bit to clear, indicating that the slave has retrieved the data.

On the slave side, it waits for the data ready bit, then reads the data. When the final mailbox is read, the data ready bit is automatically cleared.

Note that the registers have different names on the master and slave side.

Graphics Terminal Output

FIFO Communications

FIFO communications, if anythig, is even simpler than mailbox, assuming no handshaking anyway.

The master and slave each  have a control register for the FIFO,  MSI1FIFOCS for the master and SI1FIFOCS for the slave. The receiver sets a read FIFO enable bit, while the sender sets a write FIFO enable bit.  The sender then stores data into the FIFO which the receiver can retrieve.

As an example:

Summary

So the dual-core PIC is pretty manageable. There is still plenty to explore.

But I am thinking wouldn't it be nice to have the master run a DDS while the slave runs the keyer.  I may need to try that.

The code for this is in gitlab as always.

73 de WB8RCR

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.

A working dsPIC-EL

After deciding a long time ago that I wouldn't do a dsPIC-EL, nor an Elmer 166, I decided to do a dsPIC-EL, but the Elmer 166 is only kind of.

When I broke down and did the club thermometer project (http://elmer166.blogspot.com/2015/08/club-project-thermometer.html) I realized how straightforward a PCB can be.  OK, I am clumsy at it and it takes a few cycles, but the result is very satisfying.

The PIC24FV16KM202 used in the thermometer, and it's sister the PIC24FV32KA302 were something of a revalation.  The peripheral complement is absolutely breathtaking, and the peripheral pin select allows for a lot more flexibility than the dsPIC30F family.

I ran into to project where I wanted a little more speed, and tripped across the dsPIC33EV256GM102.  Astonishing!  70 MIPS, gobs of memory, PPS like the 24FV, and the family of dsPIC33EVxxGMyzz lets you select memory size, pin count, and network from a family of otherwise identical parts.

I started working on a dsPIC-EL board based on this part, and realized that the pinout was virtually identical to the PIC24FV series.  I could choose between dsPIC33EVxxGMx02, PIC24FV16KM202, and PIC24FVxxKAy02 parts by the simple addition of a jumper.

dsPIC-EL

From the work on the dsPIC30F board I recognized that Arduino-style header connectors were a worthwhile addition.  With the thermometer project I had also recognized that I could get proto boards custom made for less money and higher quality than I could buy already made. It was a short step to realizing that if I bought the long pin headers used by Arduino shields in quantity, I could have shields for under three bucks.

dsPIC-EL with proto shield fitted

Somewhere around this time I got roped into working with the high school electronics club.  The students early on expressed a strong interest in building stuff they could program.  This, of course, pushed me into moving along much quicker on the dsPIC-EL, and I can pretty much call it soup now.

Of course, I want to share this development, so all the work is on GitLab, but I have no interest in kitting the thing.  The good news is that the boards can be had quite cheaply, and there are really no hard parts (although some parts are a lot cheaper in quantity).  If all the parts were purchased in quantity one, I suspect it could be had for around the cost of a PIC-EL.  Buying things like connectors in quantity cuts the cost to less than half.  The main disadvantage to some of the large quantity parts is lead time.

The dsPIC33EV256GM102 is kind of pricey, but the 32K version without the CAN (which is unlikely to be needed) can be had for less than the price of a PIC24FV, which itself makes 16F and 18F parts look expensive.

So, the main features:

• PIC with pins brought out to Arduino connectors for easy prototyping
• Extra connector to allow ordinary perfboard to be used as a shield
• LCD and buttons on the base board.  You always want these, and they have the annoying feature of needing to be on the "top" shield which really limits flexibility if they are on a shield.
• All used pins jumpered so they can be used for prototyping without interference from on-board parts
• A few LEDs thrown in for good measure
• Power from a cell phone charger with an XH connector for batteries or some other external supply
• PICkit connector for programming
• Jumper to allow PIC24FV to be used

Schematic

I don't plan to do another Elmer 160 type class, but I will be guiding the high school club's members through learning the dsPIC, and I will be putting my materials on GitLab, so they will be available to anyone who is interested.  Rather than PDF prose, most will be PowerPoint (well, actually LibreOffice).  Of course, high school kids pick up things a lot quicker than us old hams, so the material will be quite a bit different.

The key repositories are:

The PCB including Gerbers.  The README for this repository includes the schematic and a red/blue image of the board.  The BOM in this repository also contains information on sources.
https://gitlab.com/33E-simple/dsPIC-EL-GM

The ProtoShield gerbers
https://gitlab.com/33E-simple/ProtoShield

An LCD library
https://gitlab.com/33EV-GM1/LCD.X

An I2C library
https://gitlab.com/33EV-GM1/I2C.X

Presentations (under development)
https://gitlab.com/33EV-GM1/dsPIC-presentations

Construction instructions (under development)
https://gitlab.com/E-WCC/dsPIC-EL_Build_Instructions

If you want to get boards made, simply upload the zip file containing the Gerbers to
http://makerstudio.cc/index.php?main_page=product_info&cPath=8&products_id=14
The price is around $16 for 10 boards including shipping.  Shipping seems to vary a bit, I assume based on exchange rates.  It takes about three weeks for the boards to reach the U.S.  I have also used Accutrace in cases where I want boards a little sooner (8 days).  Their price of $40 for 10 is quite a bit higher than MakerStudio, but not crazy, and their customer service is tops.  Their boards are a little higher quality than the Chinese boards, but you need to look really close to tell the difference.

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.

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.