PIC Microcontroller Questions

[Octacone]

Hey everyone!
I'm about to begin my PIC programming/building adventure and I have a couple of questions for those who are familiar.

1. Can I just open my favorite text editor, write my code (in pure C), not use any third party libraries and hit upload? No need for fancy proprietary programming environments?
2. What is the best/fastest/most feature rich PIC microcontroller that is available as DIL-40 (very important)?
3. Has anyone tried writing an embedded OS for such a device? I guess it doesn't really need one, since it is a microcontroller.
4. How hard would it be to hook up some external RAM, flash storage, some other fancy peripherals to it? (skills/education and tools are not a concern)
5. Is it capable of software multitasking?

I would like to hear your opinion on it, past experiences, troubles, successful projects, etc...

[alexfru]

Check out RetroBSD. Board pictures! It runs on the PIC32MX, available in chips with 28, 44, 64, 100 pins (naturally, smaller ones are more limited in terms of speed and flash/RAM size and RetroBSD needs a bigger one).
Also check out ROM C as I call it (like ROM Basic but C) on a 28-pin PIC32MX.
On both systems you can write and compile C code right there, despite there being less than 128KB of RAM (both are powered by my Smaller C compiler).

[Octocontrabass]

1. Can I just open my favorite text editor, write my code (in pure C), not use any third party libraries and hit upload? No need for fancy proprietary programming environments?

You'll need some way to compile your C code. If you target a chip in the PIC32 family, you can use open-source tools. Otherwise, there's no way to avoid a proprietary C compiler.

2. What is the best/fastest/most feature rich PIC microcontroller that is available as DIL-40 (very important)?

That probably depends on which features are important for you. However, the manufacturer has kindly provided this search page which might help you narrow it down. Put "40/PDIP" in the box in the column all the way on the right to limit your search to only parts available in the package you want.

It looks like you're limited to chips in the PIC16 and PIC18 families.

4. How hard would it be to hook up some external RAM, flash storage, some other fancy peripherals to it? (skills/education and tools are not a concern)

This will vary depending on the chip you choose, especially external RAM (which may require special hardware support depending on how you want to use said RAM).

5. Is it capable of software multitasking?

If you're looking at the PIC16/PIC18, yes but it's very difficult. You may be better off choosing a microcontroller more suited towards multitasking, or perhaps just a plain CPU without integrated peripherals. (The all-too-familiar 8086 has 40 pins, for example.)

[Octacone]

@alexfru
Actually I'm not looking for a development board or anything similar.
I just need a bare bones chip that has 40 DIP package, so I can hand solder it on a perfboard.
I want to be the one who creates all the electronics around it.
It has to be the most powerful of its kind (8/16 bit architecture, I don't know if the 16 bit variant comes as DIP 40) but not as powerful as PIC32.

@Octocontrabass
Proprietary C compiler is not an issue, as long as I don't need to utilize any third party C libraries and any other overhead.
That tool was quite useful - I managed to find the PIC18F47K42, looks like it's the most powerful 8 bit 40 DIP microcontroller.
It doesn't have to multitask in a way an OS does, it just has to run multiple tasks at a time. If it can't I can always assign one micro per task since they are cheap.
I don't know if I'll need as much RAM as I think, since my bigger concern would be how to store large programs on it.

PIC programmers seem to be really expensive, looks like I'll have to make my own. Any suggestions? What should I be worried about?

Edit:
Looks like there is a ton of high performance (both 16 and 32 bit) PDIP chips available. I just wasn't searching the right category.
I guess they would require some complex circuitry in order to get them to work on a perfboard.

[alexfru]

Actually I'm not looking for a development board or anything similar.
I just need a bare bones chip that has 40 DIP package, so I can hand solder it on a perfboard.

Did you miss the 2nd project I mentioned? The guy put the thing together manually with minimum additional circuitry. He made his own board, but it should work on a breadboard as well because it's so simple.

I want to be the one who creates all the electronics around it.

Nobody takes that away from you. You just get a lot of useful stuff in a single chip, which should make it a better/faster start.

It has to be the most powerful of its kind (8/16 bit architecture, I don't know if the 16 bit variant comes as DIP 40) but not as powerful as PIC32.

Why not PIC32? 8-bit nostalgia? Why not the i8051? It would be even more screwed up. Seriously, what's the goal/point?

[Octacone]

@alexfru
Yup I missed it. It looks easier than I expected.
PIC32 wasn't a consideration because I thought it wasn't available as DIP. Since it is, and is more powerful I should consider using it instead of the PIC18F47K42, since it is more powerful.
My goal is to make some embedded devices I might use in the future for my future project(s).
I don't know what it is, but when I see an old bulky chip with many pins, easy to work with, I seem to like it. I hate those tiny things with billion of legs you can't solder, even doe they're powerful they don't feel like it.

[Combuster]

Have you considered plugging the things you want into the GPIO pins of a raspberry pi?

[Octacone]

@Combuster
Nope, I don't need it to be that powerful. Also I dislike raspberry pi and all other "development platforms"...
A bare bones chip and me building the circuitry is what I enjoy.

[eekee]

I wanted to do this around 1990. I was going to do it with a 6502 and a battery-backed 256Kbit (32Kbyte) RAM or two. The battery-backed RAM would have saved me buying a programmer. I remember thinking I could write-protect part of it with a DIP-switch.

A Z80 would have worked too, of course, but I didn't like it; too fancy. Just around then, 8051/8031 and some PICs became available to me, but the PICs of the time were very limited and I've since heard <32bit PICs are a bit crazy. I got more curious about the 8031/51, but I've since heard they're not wonderful either.

The project didn't happen for several reasons, one of the main ones was lack of info. My local library, although the biggest in the county at the time, had a very poor computer section. Britain's telephone monopoly made BBS access prohibitatively expensive. The local computer shop should have and could have provided all the info I needed, but the less said about the neighborhood it was in, the better.

It doesn't have to multitask in a way an OS does, it just has to run multiple tasks at a time. If it can't I can always assign one micro per task since they are cheap.

I've been thinking the same way myself lately, having used Plan 9 for a while. Plan 9, although a multitasking and multiuser OS in itself, is designed to be networked with separate computers for each major task: one file server, several "CPU servers" which can be assigned to tasks such as the auth server or maybe running HTTP servers etc., (and these days the file server runs on a CPU server too,) and terminals which are used in a single-user way.

There are two ways of multitasking, both of which have been used by operating systems. Cooperative multitasking is very easy to implement but requires tasks to return control to the scheduler. It has the problem that if one task gets into an infinite loop, the whole system is stuck. Preemptive multitasking is the better type for an actual OS, a physical interrupt returning control to the scheduler regardless of what the user code is doing. I guess preemptive is probably easier to debug for the same reason. Cooperative multitasking makes IPC simpler.

Incidentally, if you want to look at systems which have been used for multitasking on simple hardware, you should have a look at Forth. Well-written Forth code is normally reentrant, which simplifies things, and 'words' defined in Forth are position-independant by nature. The 'words' defined in assembly language are somewhat like kernel code in that they're always loaded and so don't need to be position-independant. HForth's multitasking is extremely simple; cooperative multitasking in a few lines of code.

Also, Forth interpreters of the "double-indirect threaded" variety make best use of RAM; they make the code very compact indeed. ("Threaded" in the context of Forth refers to execution flow in the interpreter; it weaves its way through different bits of code.) Many interpreters of the past have been designed to make code more compact. RAM has pretty-much always been the most serious limiting factor of computers, although in practice it became much less of a problem in the mid-late 90s.

[coderTrevor]

I have a little bit of experience with embedded projects (although it's been a while) so I thought I'd chime in on what I'm familiar with. Forgive me if some of my advice you already know.

My first and most important piece of advice is that datasheets are your friend. You'll be using them a lot.

4. How hard would it be to hook up some external RAM, flash storage, some other fancy peripherals to it?

It entirely depends on the peripheral and interface, especially since you say you want to avoid any third party libraries. External RAM / flash with a parallel interface is about as easy as it gets. For parallel SRAM (which is what I'd recommend) you just connect the address lines to some of your chip's I/O and read / write the data via some other I/O. You'll need a few other I/O pins for control signals and off you go. Parallel flash is just as easy to read and only marginally more complicated to write data. You generally have to erase either the entire chip or the page that you want to write first. Then you send the chip a short sequence that says you're about to write data to it and away you go. Again, datasheets are your friend here.

Digikey and Mouser both have nice search features you can use to find parts (I like digikey's just a little bit better). It's easy to find parallel SRAM or flash up to 4 Megabits in a DIP package. The AS6C4008-55 is a good choice at the high end for SRAM and the SST39SF040 is a good flash chip. The latter has a 5v interface though, which could be a problem depending on what microcontroller you pair it with. Bear in mind that memory chips are usually spec'ed in terms of bits instead of bytes.

Also, bear in mind that microcontrollers usually employ a Harvard architecture, which means they will only be running code directly from their internal flash memory, so you can't rely on external memory for that. In practice though, it's very unlikely that you would need to.

I²C is probably the second-easiest way to interface peripherals, and many chips will have some kind of built-in support for this. It's also pretty easy to bit-bang.

3. Has anyone tried writing an embedded OS for such a device? I guess it doesn't really need one, since it is a microcontroller.
5. Is it capable of software multitasking?

Look into FreeRTOS.

You might also want to take a look at the embedded project that first got me interested: the Uzebox. This employs a special-purpose kernel which draws graphics and plays sound and allows game developers to write games in C. It also has a very nice community around it.



Another piece of advice I have is once you've picked out a potential chip, you should make sure you can setup a toolchain for it and successfully compile a project. Sometimes the software is the weak link with embedded devices and you don't want to find that out after you've waited for a chip to be delivered and designed and built your hardware around it.

Also, make sure to find the errata for that chip and read it. Some errata will even make certain features completely unusable but the manufacturer's marketing is still not above listing those features in the product specs or datasheets (Microchip is particularly guilty of this).

PIC programmers seem to be really expensive, looks like I'll have to make my own. Any suggestions? What should I be worried about?

Bootstrapping is one of the most tedious things to do. I have actually made my own JTAG programmer which I used to install a bootloader on a PIC32 which allowed for uploading code via USB. Keep in mind that if you go this route, you'll most likely need to make your own software and hardware to upload the bootloader to the chip. Once you've accomplished that though, the rest is easy. The Microchip documentation for device programming and bootloading is really good, and if I recall correctly, they give you all the source code and software you need for a USB bootloader. It's still a lot of work, however. In practice, you only need to use JTAG or ICSP to get the bootloader programmed, then you probably won't need to use JTAG or ICSP anymore, so it's a lot of work just to avoid buying a dedicated programmer.

I can elaborate some more on this if you think it would help, but after shelling out $50 for the PIC programmer, I personally think it's well worth it. I don't know if there's the kind of command-line support you'd want for it though. I do know that you can get that kind of support with AVR chips, and for those you can build or buy a very cheap (but slow) programmer that uses some kind of USB-to-ttl cable.

I guess they would require some complex circuitry in order to get them to work on a perfboard.

It's really not too complex. A good datasheet will give you a minimal circuit to get the chip up-and-running. It's usually called "typical application" or "basic connection requirements." For example, the datasheet for the PIC32MX1XX/2XX 28/36/44-PIN FAMILY (I just chose that at random) has all you need to know under section 2.0 Guidelines for Getting Started with 32-bit MCUs. You typically just need a few capacitors and maybe a couple of resistors. Slower chips and 8-bit chips tend to have less external requirements, but even a fast, 32-bit chip won't have many critical requirements. A high-speed PIC32 does require a single tantalum capacitor that needs to be installed very close to the chip, so putting it on the other side of the board directly under your chip might be necessary. This is all spelled out in the datasheet.

Even if it isn't called out specifically in the datasheet, you always want to use at least one decoupling capacitor for every chip in your circuit. This is just a capacitor between VCC and GND that you put as near the chip as possible, typically in the range of 0.1uF to 1uF (the exact value isn't very critical).


My final piece of advice is don't try to use a crystal to build an oscillator circuit, especially if you don't have a scope. Instead, just spend a little more ($2) and buy an "oscillator" in a package. I don't know why more people don't do this. This will save you all the headache of calculating load capacitors (which you really can't do accurately with a prototype anyway) and will eliminate a potential problem that is nearly impossible to diagnose without an oscilloscope.


Hope some of this helps you. Hardware development is lots of fun!

[Octacone]

@eekee
I must have been hard back then to find any valuable info without the Internet. Can't imagine the faces of people when you asked them to give you a PIC101234567XYZ programming reference manual.
Generally, preemptive multitasking is the only choice. Can't have the risk of an app malfunctioning and bringing down the entire system, even worse when that system is life dependent.
I don't fancy any other languages besides C derivatives.

@codeTrevor
Harvard architecture you say, dang it! I needed that extra code/execution space. So I'm basically limited in terms of code size and program usable RAM space?
I'm aware of all the serial signaling interfaces, will probably have to use them for module interconnecting. Most of them are straightforward.
Uzebox seems very interesting, as Dave Jones would say it is a thing of beauty and a joy forever.
Don't mind the programmer, I found a cheap one on eBay, seems the be reasonably priced and widely used. "PICkit3"
Unfortunately, I don't have an oscilloscope. I could buy the best one on the market, but I have like 10 other more important things that I have to spend the money on... Such a shame, my life would be much easier if I had one.
I don't think I'll need any oscillator circuits, maybe for the USB HID interface (there's a premade one I suppose).
Ty for suggestions!

[eekee]

@eekee
I must have been hard back then to find any valuable info without the Internet. Can't imagine the faces of people when you asked them to give you a PIC101234567XYZ programming reference manual.

Actually, Maplin was very good in those days; a mail-order electronic components company. They had this huge catalogue which was also a reference for smaller components, and you could order datasheets from them at very low cost too. But then in 91 or 92, the old marketing director left or retired or something, and the new one made a lot of changes which weren't friendly to hobbyists on a budget like me.

I think that restricted Harvard architecture was the actual reason I didn't want to touch PIC. I wasn't interested in Forth either back then, although looking back at my specific curcumstances, I would have been better off if I had been. I would have got a lot more done with my limited knowledge. Doesn't matter any more.

Here's an odd thing: A friend of mine finds SMT easier to solder than through-hole components. O.o He says people use an ordinary tabletop oven as a reflow oven. (Just don't use the same one you cook your dinner in.) He even says he finds it easier to re-work SMT joints. I've never tried it, haven't done much soldering at all since he mentioned it. I'm not sure whether I ever will try it, because with my health, some days my dexterity isn't so good. With through hole components, a loss of dexterity seems less problematic.

[AJ]

Hi,

I must admit to not having had time to read all the posts above in detail, but just thought I'd add something a bit quirky in to the mix. How about the Parallax Propeller, which Is available in 40 pin DIP and 44 pin QFP / QFN? It doesn't quite multitask and has an unusual architecture, but might be worth a play and needs minimal support circuitry.

Cheers,
Adam

[alexfru]

How about the Parallax Propeller, which Is available in 40 pin DIP and 44 pin QFP / QFN? It doesn't quite multitask and has an unusual architecture, but might be worth a play and needs minimal support circuitry.

AFAIR, it doesn't support interrupts, meaning polling and high power consumption when seemingly idle.

[AJ]

Ah - you're right. I last used the propeller 2-3 years ago in a stage electronics project where power draw was really not an issue (compared to all those incandescent lights I was controlling ).

Oh well...