On Sat, Mar 13, 2010 at 05:14:06AM -0500, HuwD wrote: > > I'm new at using Microcontrollers. I'm interested in using them in Robotics > and bought a book called "PIC Robotics". The software the book recommends is > the "PIC Basic compiler". However it appears to come on a 3.5 inch floppy > disk and uses the either the serial or parrallel port on the PC to interface > with the Microcontroller. This seems a little antiquated and I was wandering > if there was anything more recent and ideally free to download. I would also > be good if I could connect to the microcontroller via USB. > > Whats the best current software for programming the PIC Microcontroller? I actually started this post several hours ago. I went AFK to do some testing... As others have stated, best is a relative term depending on a lot of factors. There are at least 6 different (and somewhat opposing) issues at work here: 0) And old book will probably use old PIC parts. Before you do anything else be sure that you are up to speed with current parts and all of their enhanced features. For example the PIC 18F family is a whole lot better on virtually every front. I'm currently looking to set up shop with 18F2620 and 18F4620 parts. With the internal oscillator and PLL enabled you can run at 32 Mhz with a boatload of memory, easy program memory access, and the standard array of periperals. And that's with no additional parts. 1) You have a book in your target area, Robotics, that is using a particular target language, PIC basic, to explain concepts. 2) You are new to microcontrollers, but the rest of your background is missing. New to computers? New to programming? What programming languages do you already know? 3. Cost and support. Are you willing to work with a free environment? Do you need to have support that you can call/email? It all depends on you as a developer. 4. Understanding the underlaying architecture. Small embedded systems environments applications, such as robotics, often have real-time and resource (memory and the like) contraints. In short, whether it will fit and run fast enough often depends on what you use to develop. It can be difficult sometimes to understand the tradeoffs without understanding the underlaying archetecture. And most high level programming environments are specifically designed to shield developers from that architecture. Often floating in the abstract without having to worry about details works well. Other times it can kill a project. The problem is often that a developer who hasn't worked from the bottom doesn't have enough experience to determine the difference between the two. You have already gotten, and probably will continue to get, suggestions to write in PIC assembly. While it is true that there are a limited number of instructions, the challenge is in the composition. Even something as simple as: i = 1 Can be a challenge in PICs, with their banked memory and lack of instructions for direct memory interaction and 8 bit memory model. In PIC assembly this could be as many as 11 instructions depending on the location of i, the state of the W register, and the size of the integer variable in question. This is precisely my point. Such an innocent statement can be a huge drag on system speed depending on memory allocation, and if the system is compiled or interpreted. But someone who only writes in HLL's may not realize what the tradeoffs are. My suggestion is always to write and test at least one signficant project (not just a blinking LED) in PIC assembly before making a decision on language choice. The exposure to the underlaying architecture will help in the process of using the HLL when you get to it. Also knowing PIC assembly will help you in discussing issues with other developers, who may not actually be using your language of choice. I call it the linqua franca for PIC developers, because it's the language that most PIC developers can read and understand, even if they are developing in another language. Another benefit is that with most compilers you can actually examine the produced code to see where your issue may lie. But it's kind of hard to do if you don't know PIC assembly. So to summarize: start with PIC assembly, then choose something else after you get a better understanding. I'll walk away from this part of the discussion with a couple of off the wall suggestions to take a look into. If BASIC is your target then a good choice looks like Great Cow BASIC: http://gcbasic.sourceforge.net It's a free BASIC compiler that works on the 16F/18F chips along with AVRs. They even have a graphical editor for it that is cross compatible with text code. So you can start out dropping/dragging symbols, then switch to editing text directly later on. Even a bit more further afield is FlashForth: http://flashforth.sourceforge.net Forth is my current language/programming environment of interest. It packs quite a bit of power and complexity in a small, self hostable package. Flash Forth is a system where the entire development environment runs on the PIC itself. There's no PC software involved. So not only do you get a bootloader, you actually get the entire development package onchip. I'm currently working on my own self hosted forth for the 16F family. But after spending the evening yesterday porting the code to the 18F, it's easy to see that the 18F family is much better suited for hosting a forth environment. 5) The programmer issue is orthogonal to the others. I left it for last because I have quite a bit to say. You'll get a lot of different opinions on how to tackle that issue. I'll throw my hat into the ring and suggest that a very usable development model is to use a bootloader. A bootloader is software that you install on the PIC, then use the PIC to program itself via the interface that you choose. I personally like and use bootloaders because it eliminates one more piece of hardware, the programmer, to track, and it allows for using natural interfaces for the product to do development. For example if I were building a MIDI music controller project, then I can use a bootloader that uses the MIDI interface to program that project. The final useful part is that if you use a separate interface, say bitbanged serial, for programming, then you get a natual debugging channel for your hardware that is apart from the application itself. And this can be done with as little as zero pins of I/O. The big problem is the chicken/egg problem. Bootloaders are very useful, but blank chips do not have bootloaders on them. So unfortunately there is still a need for hardware programmers. But they are very limited use items in a bootloader environment. In fact in my head I've renamed them "code dumpers". You just need one long enough to dump the bootloader code on the part, then put it away. Please note that bootloading isn't an option on all PIC parts. A PIC has to be able to program its own program memory in order to support bootloading. This limits your options a bit. But at this point there is at least one PIC part in every family and in every pin count that supports self programming. I just got some 12F617s, which are 8 pin parts, which supports this model. The serial/parallel port code dumpers have limited utility in today's PC world. USB has pretty much killed those two ports on modern computers. Serial ports have the additional problem of just not being EIA-232 compilant, which means that the serial port programmers that require an EIA-232 compliant port, such as the JDM serial programmer, simply won't get the job done. The most promising avenue for code dumping on modern PCs is via a USB serial converter. They have the advantage of being cheap, presenting a consistent and well known interface (a serial port) to the OS, having precise clock timing, and being readily available. Their biggest challenge, in addition to also not being EIA-232 compliant, is the fact that their modem control signals, which programmers like the JDM programmer use for clocking, are not syncronous. You simply cannot expect the OS to flip the DTR bit and for it to change instantly out the other end of a USB serial dongle, if it changes at all. So the ton of designs that use the modem control bits, for example this one: http://web.archive.org/web/19980530025932/www.iet.unipi.it/~luigi/README.prog84 Simply will not work with a USB dongle. Sorry for rambling. This is an issue that is currently on my mind that I'm trying to resolve. Tony Nixon came up with a solution a while ago. He defined the problem in these terms: " The idea behind this project is to provide some means of loading a program into a PIC that will then be able to program other PICs in a more conventional way." As an aside, the bootloader is exactly this, a more conventional way to program a PIC. "This is a mouthful, but ... How do you program a PIC to be a programming device without a programmer, and why would you want to build a programmer if you already have one that can program the PIC to be a programmer. " I couldn't have said it better myself. Tony's solution is here: http://www.piclist.com/tecHREF/com/picnpoke/www/http/projects/prog.html It exploits the fact that a transmitted serial character has precise timing. He generates a clock that expires halfway through a character. the clock is triggered by the start of the character and ignores changes after the start bit is transmitted. I attempted to do the same with my design here: http://www.finitesite.com/d3jsys/tbs555 Note there's still no software for it yet. My mistake was falling into the trap of trying to get feedback working properly. I now realize with my current setup, that one way dumping is fine. So it's a project that I plan to complete sooner rather than later. So from this standpoint I personally have a decision tree: 1) If possible use a code dumper to get a bootloader on the part. 1a) If a parallel port is available use the Trivial Programmers: http://www.finitesite.com/d3jsys Which can be breadboarded in less than an hour. 1b) If a true serial port is available use it with a simple serial code dumper. Be sure to watch the voltages to make sure that they don't cause issues. 1c) A USB dongle may have some utility. This is where I went offline to check mine. The modem control signals do actually work. But they are a bit slow. But this can be pretty easily corrected in software by monitoring the signal and only proceeding once the signal has stabilized. Python's pyserial package has simple tools for managing the serial port. I'm going to work on some simple programming. 1d) If all you have is a working Tx signal out of serial dongle, then Tony's solution is the right one. 1e) Look into Microchip's Pickit 2/3 options or similar USB programmers such as EmbedInc's USBProg: http://www.embedinc.com/products/usbprog/index.htm 2) Go directly for 1e and not bother with a bootloader. Personally I haven't gotten past 1a. Currently I'm using Frank Sergeant's pikme bootloader: http://pygmy.utoh.org/pikme/index.html His design is simple enough to get going in a very short amount of time. I'm still thinking that maybe Wouter van Ooijen's ZPL concept: http://www.circuitcellar.com/flash2002/honorable.htm Has some merit. But I'm starting to think that with today's newer PICs where virtually all of them can replace MCLR with a input only pin, that maybe it would be better to stick to Frank's half pin concept. The clincher would be adding autobauding so it works no matter what speed you set the serial port. Xiaofan has a pretty good listing of bootloaders here: http://mcuee.blogspot.com/2007/11/i-am-trying-to-collect-list-of.html If you decide to go this route, be sure to read Wouter's doc that accompanies ZPL. He does a great job of discussing issues of resource utilization and transparancy with bootloaders. I think that's enough for now. I'm going to go work on a harness for the USB dongle to get my newly arrived 12F617 parts programmed and bootloaders going on them. Unlike many of you, I have a class full of students. Now that I think about it, Wouter does too. Maybe that's what colors our thinking on the subject. TTYL. Hope this gives you some insight. BAJ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist