PIC control board PCB

Let's Make Robots Projects Showcase
61

Ah, yes I did recieve my board a few days ago.
I’m afraid that I haven’t had the opportunity to do anything more than oogle at it.
I’ve been spending the last two weeks evaluating the LEGO NXT kit for my college as well as learning what the heck 1,000+ lines of C code are doing so I can interface the code to a CMU2cam.

The NXT kit is for a highschool competition that my college hosts, and the camera is for a local (South Plainfeild) FIRST team.

Between the two, I think I’ve gotten about 3 hours of sleep in the last week.

Rest assured, though, the board is next in line on my to-do list.
Heck, I’ve only got 930 more lines left to go!
:laughing:

62

930 lines of C code to me would make every bridge look like diving boards. :laughing:

63

Last night I got the I2C comms working between the two PICs! Woo Hoo! (“Woo Hoo” is a technical term that describes the sound of bits moving happily back and forth…).

There were no HW problems - the issues were all SW. The I2C engine in the dsPIC30F series is a bit different from what I’ve used before. But now that it’s working, I won’t have to re-invent it again. The 18F4620 is the Master, and the dsPIC30F4011 is the Slave. When the 4620 is running at 10 Mhz, the I2C clock rate is about 100 kbps. There are faster I2C speeds, but right now I don’t plan to mess with it.

I’m writing some routines around the I2C stuff on the two PICs such that I can do some fairly generic “message passing” between the two. In my own bot, I will be connecting the SSC-32 to one of the dsPIC’s serial ports, so the 4620 (which is in charge of the overall bot) will send SSC commands over I2C to make servos move.
There will also be I2C commands to tell the dsPIC to read/write data from its I/O port pins and such.
If the dsPIC detects something interesting “on its own”, it can fire off an interrupt to the 4620, and the 4620 then will do an I2C query to find out “what’s up?”. So that will be another I2C command: Ask the dsPIC for its overall state.

I hope to post some new code in the next couple of days.

Pete

64

Good going, Pete! :smiley:

These will both be programmed in ‘C’, right? Will we be able to use this board and have it be controlled by an external microcontroller like the Basic Atom? Maybe an external microcontroller could become the overall master, but then you would have to contend with a multi-master bus and you may not want to deal with the arbitration that would involve. Or maybe the 4620 could just let the external microcontroller think it is master and just execute commands.

Hmmmm, my head doesn’t want to wrap around this well today. I better go back and reread the start of this thread, because I’ve long since forgotten the original idea.

8-Dale

65

Yes, I’m using Microchip’s C18 and C30 compilers (free).
Yes, you certainly could control it with another micro like an Atom28, but I don’t think there’s much point (and you’d have to work out the comm protocol yourself).
My board is WAY more powerful than an Atom28. The Atom28 is based on a PIC16F876, according to the Basic Micro web site.
Here’s a comparison of the key features:

                                         max    I/O
                 Flash  EEPROM   RAM    speed   pins  A/Ds  timers
Atom28 (16F876)   14KB    256    368    20Mhz   22     5        3
PIC18F4620        64KB   1024   3968    40Mhz   36    13        4
dsPIC30F4011      48KB   1024   2048   120Mhz   30     9        5

The down-side of my board is:

  • You have to buy the bare board from ExpressPCB, and you have to buy at least 2, and it’s pretty expensive (per board) unless you can order at least 4 or 6.
  • You have to be willing to work in C. You are welcome to use the code that I write for it, but if you want something special, you’re mostly on your own.
  • You have to buy the parts and solder up the board yourself.
  • You need a PIC programmer to burn code into it.
  • My board is not “formally documented”, because I’m not selling it as a product (perhaps Jim would like me to help him product-ize a version of it??).

The up-side of my board is:

  • Rather powerful and flexible considering the cost. If you order several sets of parts from Microchip and a place like Jameco, and several PCBs from ExpressPCB, you can probably get everything for about $65 per complete board.
  • Lots of I/O possibilities compared to other options.
  • Many things on the board are optional. You could skip the dsPIC for example. Or skip the battery charger, or some/all of the FET switch parts, etc.

Pete

66

Hmmmmmmm… I have perhaps found something I can do then, if Jim isn’t interested. He has no doubt got more resources than I do so would be better able to do a manufacturing project. If I just had money to work with, I am sure I could do this with no problem. I would just have to find somebody to assemble the boards, but might be able to manage to do a few myself - I did electronic assembly and test/QA for 4 years.

I programmed professionally in ‘C’ for 4 years, so I think I can get back into it pretty easily. :slight_smile: Now I am wondering how hard it would be to write some sort of high level language for this… I’ve written applications specific command languages.

I am going to get all the information on this project that I can now. :smiley:

8-Dale

67

Would I just have to have them make the boards for me like you do now?

I’d just have to brush up on my assembly skills.

I don’t think I would have a problem getting something that would work with MPLAB. I have already done a bit of research on programmers.

I can certainly see the power and flexibility in this board of yours, which is why I am so interested in it. I have a lot of things I want to do with robotics where this could work very well instead of a standalone microcontroller. I suspect I could do a lot of things with this that I would otherwise be considering a Linux based system like a Gumstix for.

8-Dale

68

I just downloaded and installed the latest version of MPLAB, C18, and C30. I think I have found a reasonably priced PIC Programmer.

I also downloaded all the stuff you have available on your project. There are a couple of files missing for the PIC stuff - environ.h and 18f4620.lkr (Linker script).

8-Dale

69

The linker scripts are part of the C18 installation (I didn’t make the file).
The new file set (when I post it) will have new/changed file names and such. Stay tuned…

Regarding writing a ‘high-level language’ for it:
Remember that fundamentally this board is “just a couple of PICs”. Tools that other folks have written will generally apply. Doing it yourself is a big project.

As for making more boards:
In an earlier post is the link to the PCB files for ExpressPCB. You can use that file (either as-is or with changes) and order your own boards.

Pete

70

Ah, OK.

I know doing it myself is a big project. I have lots of time to do such things. :smiley:

OK, I will search back and find that file then. :slight_smile: I won’t be changing the design.

8-Dale

71

Very good. Take note of the missing capacitor (“C2a”). I added it to the schematics, but it is not on the PCB layout yet. The easiest way to deal with this is to leave out D5 and D6 (replace them with wire jumpers), leave out C2, and put C2a in the C2 location.

Meanwhile, I made some progress on the I2C code tonight…

Pete

72

I’ll just wait for your next board revision, and then I want to get one and check it out. If it is not too difficult, I may try building one myself after I get a better soldering iron and a decent board holder.

Good to hear! I figure I will learn a lot by checking out your code. I am very interested in I2C since I want to use it as the major communications channel for my robots.

I want a board that is capable of handling full IK for an 8 legged robot and able to do other stuff too, without having to spend a fortune.

8-Dale

73

New code (V0.1) is posted:
www.geocities.com/saipan59/robots/dualpic.zip

The I2C routines are pretty solid I think.
The PIC can send arbitrary packets to the dsPIC. A “packet” is a command byte, followed by 0 to many data bytes, followed by a checksum byte. The response from the dsPIC will be the same command byte, then 0 to many data bytes, then a checksum.

Currently, the dsPIC understands 3 commands:
01 - Turn on port pin RE0.
02 - Turn off port pin RE0.
80 - A “loopback test” - it returns the checksum byte as data, so that the PIC can know that the complete data path is working in both directions.

On startup, the PIC side does the 80 command to verify that it can talk to the dsPIC, then it loops forever doing cmd 01 and 02 every second, which causes a pulse to appear on RE0 every second.
The 01 and 02 cmds are just for demonstration at the moment - later, they will go away as I add more useful commands.

The most interesting files are:
pic_main.c
pic_i2c.c
dspic_main.c
dspic_i2c.c

Pete

74

Really? I was under the impression that the PICs could be programmed in situ using the DB9 serial port. Not that it matters much for me (have a USB EEPROM/ Micro programmer) but it’s a nice feature.

75

You’re probably thinking of a PIC that has a ‘bootloader’ already burned into it.

Here’s a rundown of PIC programming:

To get code into a raw PIC, you hook up to five signals: MCLR, CLK, DATA, Vdd, and Vss. MCLR is the PIC’s reset line. CLK and DATA are pins that are also I/O pins when you’re not programming it. [There is a variation that involves a sixth pin, but I’m skipping over it…].

A PIC programmer applies about 13V to MCLR, which informs the PIC that it is being programmed. The programmer sends something to the PIC to cause it to erase it’s Flash memory. Then the programmer sends data serially to the PIC via the CLK and DATA lines, and the data gets burned into Flash and/or EEPROM. When the programmer releases MCLR (back to 5V), then the PIC inits itself and starts running code at address 0000.

But some folks have their PIC installed in a board where there is no good way to hook up the programmer to the required pins. If the board has any sort of data interface to the outside world (serial, parallel, whatever), then it is possible to use a ‘bootloader’.
What this means is that before you install the PIC in the board you use a conventional PIC programmer (as described above) to burn a small program into the PIC. The purpose of this program is to use the existing interface (RS232, for example) to receive data that needs to be burned into the PIC, and then to burn that data into Flash, but without erasing or modifying the bootloader code that is already there.

As an example, a bootloader that I wrote works like this:

  • The bootloader code lives at address 0000 thru 0300.
  • When the PIC powers up, the bootloader code runs by default (from address 0000).
  • The bootloader does bare-minimum initialization, including setting up I2C.
  • The bootloader waits for about 1 second to see if it can receive anything on the I2C bus.
  • If nothing is received within 1 second, the bootloader branches to address 0300, which is assumed to be the user’s code, and the PIC does it’s normal thing.
  • If the bootloader gets something via I2C, it assumes that it is one of 2 possible commands: Erase Flash or Program Flash.
  • If the command is Erase, the bootloader erases everything from 0300 to the top of memory.
  • If the command is Program, then the bootloader receives bytes and burns them into Flash, from 0300 on up.
  • After the ‘host’ sends all the bytes, it resets the PIC, waits 1 second, then the PIC should be running the new code…

On my board, I put 5-pin programming headers on the board, so it is easy to program the PICs in-circuit. [For the dsPIC, 2 jumpers have to be removed during programming, because those pins are shared with I2C, and the programmer doesn’t like seeing the pullup Rs on the signals.]

A bootloader is a bit of hassle to set up, so I don’t plan to do it with this board. There are free bootloaders on the web, but be aware that they typically only work with certain PICs, because they must deal with interrupt vectors and such.

If you have a robot with a wireless link, then a bootloader would be a cool way to do code updates remotely.

Pete

76

I haven’t followed this thread as close as I should, therefore, I am confused as to the application of all this PIC stuff. What can be done with this board? Is it a powerful generic platform where it can be used like any microcontroller board? or do you need to use it with the Mini-ABB? Is it a stand-alone micro controller? Can you give me a few examples of its use to help me understand its potential?

Forgive my ignorance; I have very little knowledge of PICs in general.

77

I just posted better-quality images of the board here:
www.geocities.com/saipan59/robots/dualpic_front.jpg
www.geocities.com/saipan59/robots/dualpic_back.jpg

On the front view, lower-left corner, you can see the little transmitter module (I got it from SparkFun).
There are two LEDs on the board (a red and a yellow) that I added for a ‘heartbeat’ indication, so I can tell when the code is running.

On the ‘back’ picture, you can see the 2 tantalum caps I added for “C2a”. The little white wires are for the LEDs.

Pete

78

Caps on the back of the board remind me of my first audio board, except that I used resistors. :laughing:

Did you see my post Pete? It’s two posts up there -----^ :laughing:

79

Yes. I would describe it as a ‘generic’ board, but with some robotics-oriented features added (FET switches, battery charger, wireless serial output).

Definitely stand-alone. See the last 10 or so replies in this thread. It could be used with an ABB (or similar), but I’m not sure that there’s much point. The ABB has some stuff that I don’t, such as buttons, lights, and a beeper, but those things didn’t seem that useful to me (OK, at least one LED is very useful…). For processing power and total I/O options, I think my board is way ahead. My board is also way ahead on cost-for-performance, but see the caveats earlier in the thread.

For starters, it’s about to become the new ‘brain’ for my bot (3DOF Quad with wheels/motors added). In my bot, it will do the following sorts of things:

  • Control locomotion and navigation.
  • Control the SSC-32 to move the legs.
  • Monitor the state of it’s battery. When battery juice is getting low, go looking for a “gas station”.
  • Use sensors to detect obstacles and such.
  • Control the DC power to the servos and electronics (power-down non-essential stuff when sleeping).
  • Wirelessly send it’s status to a remote “telemetry receiver” (that’s a separate project, but it’s working!).
  • Control a sound-recording chip to say some pre-recorded words (such as “ouch” when it bumps into something).
  • If “number-crunching” is needed, the dsPIC can do that really well (and fast), but I can also make it run slow to save power when it’s not doing anything that important.

A lot of the stuff described above is software. If I were using a STAMP-based board, I wouldn’t have the code space to do many of those things.
The main PIC in my board (18F4620) has enough code space for a large C program, and the dsPIC is also available to offload some of the work.

Since I have a couple more of the bare PCBs, I’ll need to figure out what to do with them… One thought is to make something cool that is in my car - I recently got a Toyota Prius hybrid, which already has about a zillion microcomputers hidden in it…
Maybe I’ll use one as a “home control system” of some sort, to track weather, intrusion, turn off unneeded lights, be my alarm clock, etc.

Pete

80

Thanks for clearing it up. I meant the programing pins, you can connect those directly to the serial port with a few glue components. I know nobody uses the telephone cable type plug for the official programmer, I assumed you used the DB9 for that like a number of designs I’ve seen. However, now I see that you just used some IDC pins. Not an issue, and actually saves room and lets us use parallel/ USB programmers too. Yea, a bootloader is way too much work considering the application, at least for now.

One other thing, now that I actually have the boards. They are nice! :slight_smile: Is there a full parts list anywhere? I saw a schematic before, but think the link is broken. Actually, I would want that more, since I’m going to need to breadboard all of this before soldering anyway. I could just solder willy nilly but since I’m a fan of using the mounds of components I have lying around the lab’s basement (literally I found a few pounds worth of 7400/4000 ICs behind a cabinet the other day), I think I better be safe. Plus, I’ll learn more that way.