Sign out

PIC control board PCB

#1

I’m toying with the idea of making a PCB layout for a PIC control board.
If other folks here might be interested in buying one or more of the boards, then it reduces the cost for everybody.

Just brainstorming, here are some thoughts:

  • It would NOT be a “be-all” robot control board, but it would have several features that (in my opinion) are very useful.
  • It would also serve as a “demo board” for general PIC stuff.
  • I would do the layout and fab via ExpressPCB.
  • The main CPU would be a 40-pin PIC, such as an 18F4620 (several others would work with the same basic pin-out).
  • It would include a “co-processor” based on a dsPIC30F chip. This could be a 28-pin skinny-DIP, or a 40-pin (which is best?). The dsPIC series are higher-end PICs that include a “digital signal processor” engine in them, which means they’re good at number-crunching. My thought is that the main PIC would talk to the PIC30 via either I2C or SPI. The main guy would ‘offload’ some compute-intensive stuff to the other guy. The other guy could also be used as a source for extra I/O pins. If you don’t care about the dsPIC stuff, just leave it off the board.
  • Both PICs would run from discrete-crystal clocks, for good accuracy and low power consumption.
  • The board would include several MOSFET switches, to give SW power control over other boards. For example, one switch controls power to your SSC-32, another controls some sensors, etc. It would NOT be intended for high-current devices such as motors (that’s what motor-control boards are for).
  • The board layout might include support for some basic sensors, such as temperature, ambient light, etc. I’m thinking that this area should be kept to a minimum, because everyone has different sensor needs, and I don’t want to deal with 10 different sensor types.
  • Having good I/O options is a priority. In particular, enough serial ports (for connecting to things like SSC-32’s), plus I2C for sure, and probably SPI support. This area needs more thought. Would it make more sense to change the dsPIC to a regular PIC, and make it a dedicated I/O processor?
  • The layout will include a spot for those small transmitter and receiver modules, and the option to hook a PIC serial port up to them.
  • On-board voltage regulation, with protection for reverse-voltage.
  • A place for an ICSP connector (for programming the main PIC). What about the other PIC?
  • A couple of buttons and LEDs.
  • Some prototyping area (just a grid of holes on 0.1" centers).
  • Support for 0.1" headers for all PIC I/O pins that make sense.

What else??

Pete

#2

Another feature that many people could use:
A basic NiMH charger circuit. Not a fast-charger, but rather something that is just voltage- and current-limited.

Pete

#3

If the dsPic could be used to offload compute intensive stuff like Inverse Kinematics and such, it would be great. Could it be used in this way?

It would be great to have a compute engine capable of crunching on Inverse Kinenatics and perhaps handling the leg control motions direct while the main PIC handles sensors and main decions making, interrupting the dsPic as needed to change its gait processing. It would be great to have this all on a single board if all the unused I/O is exposed to appropriate headers.

There could actually be two versions of this board - one with headers appropriage for robotics usage and another for general usage.

Maybe I wish for too much. :slight_smile: Well, you did say brainstorming… More I/O is better.

#4

Yes, Yes, and YES!

I bought a charger for NiCad and NnIH packs, but found out it requires a [email protected] input. It did not say this in the item description on the website. :frowning: If I had known this when I bought it, I would have passed as it is a rather expensive charger. So, all I have is the charger that came with the 7.2V packs I got for my RC Hummer and I don’t know if I can safely use this to charge 6V packs or not.

#5

You posted it first =’.

I was starting to plan a PIC based project for later on. I want to develop a PIC based board (such as the ABB for the atom or the arduino for the atmel). I am planning on making it a “modular”. Such as I can plug in different things into it. (For example a blank PCB such as the ProtoShield for arduino, or a server controller or DC motor controller.) This modularity would enable for multiple boards to be “networked” together (Nick’s idea :laughing:).

But yea, thats sort of far away… I need to learn more about these PICs… I am planning on maybe having an onboard programmer… But a later version…

As for you, I think you sould use Eagle for the board design. BatchPCB has a really great $2.5 per square inch deal and they dont accept ExpressPCB but they accept Eagle.

#6

After a little more thought:

I’m thinking that the “dual processor” feature maybe is the highlight of the board. There are already a zillion other boards that support a single MPU and some I/O stuff. The dual-MPU support means that it is possible to do some fairly sophisticated stuff (in SW), but folks doing simpler stuff can just populate one MPU chip.

Yes, I suppose that a dsPIC would be a good choice for the Kinematics and such. The code would be up to you, though. :confused: If I do this project, I will gladly share the code that I would use myself, which would include some standard I/O functionality and I2C and such.

Given that there are 2 PICs, and one is a ‘standard’ 18F series, while the other is a dsPIC30F series; I’m undecided about which one (or both) should be a 40-pin vs a 28-pin. The point of the 28-pin would be to save board space, but do we care? I’m leaning towards using two 40-pin devices.

There would be only a single ICSP connector, but a single jumper would let you select which chip you are programming. I would prefer the Microchip telephone-style connector, because it plugs directly into the ICD2.

To get more than 2 serial ports (desireable) will require bit-banging I think. Each PIC has 2 ports, but the pins for one of the ports is needed for I2C to talk to the other PIC, so we’re left with just one port on each PIC. Another approach (maybe better) is to add a hardware MUX to one of the ports, so that it becomes (for example) 4 ports, although the PIC would only be able to talk to one of them at any given moment.

Pete

#7

build one for the TINI platform please!

Neil

#8

Correction on the serial-port issue:
The dsPIC30 in a 40-pin package allows two serial ports in addition to I2C/SPI.
The 18F4620 will allow 1 serial port plus I2C/SPI.

SO, this gives a total of 3 full-function UARTs to work with, which I think is enough. I will add a MAX232 chip which will allow 2 of the ports to be true RS232 (but there will be a jumper if this is not wanted on either port).

For clocking, the layout will allow for a crystal plus 2 small caps for each PIC. In the dsPIC30, by using the “HSPLL” mode with a 7.5 Mhz crystal, it will apparently produce an internal clock speed of 120 Mhz, which is supposed to be a throughput of 30 MIPS! I’ve never tried using the juiced-up clock speeds before, so it will be interesting…

Pete

#9

I’m certaintly interested.
:smiley:

40-pin sounds good to me.
If size is really a big issue (as it is with bipeds, and little else) then it’s usually necessary to make a special board for it, anyhow.
So, anyone looking to jump aboard this is probably not going to worry about size much.

I do like the sound of that onboard battery charger.
Although, I’d settle for a bit less, happily.
I’d like to see a “smart” monitor that:
(1) Cut off the battery supply to the robot when one plugs in an external charger.
(2) Cut off the battery supply to the robot when one plugs in an external power supply.

That way, whether one wants to charge, power the bot off of tethered supply to save batteries during testing, or both of those scenarios, no connecting/disconnecting of hardware is needed.
I find that the worst mistakes arise when one gets used to (read- becomes lazy) swapping in and out hardware and accidently puts something back together wrong.
At worst, this could be done with jumpers, but I’d rather see it done with FETs to minimize the age-old jumper issues.

I like the sound of offloading that IK.
Perhaps we could knock together a simple IK engine to streamline things.
The only problem I can think of is the big delay of I2C.
Would the speed bonus of connecting the two micros via parallel port be worth the hogging of all those necessary pins?
I just can’t see how helpful a micro that operates 3X faster would be if it’s run through a slowpoke connection (although I’m basing that on the supposed new 1MHz “fast” I2C that I’ve read about, and not any experience with it).

What I’d really like to see is a plethera of interupt pins.
There’s 3 dedicated INTs on my 2620 and 4620 as well as 4 other “shared” ones.
Still, I can think of good uses for at least 10 more, so the more the merrier.
:smiley:

About the programming connector…
I’ve just started using that programmer at school and I can’t complain about it or it’s connector.
But, at home, I have been and probably will be using the Tiny-ICD2 from Sparkfun which has a polarized (molex?) connector.
Worst comes to worst, though, I can always make an adapter cable for meself.

#10

I’m somewhat anti-PIC but I wouldn’t mind sending a C-note towards something cool, especially hobby-based.

I want to make a board that incorporates an arm7 processor plus a CPLD, I’m getting the two eval kits to play around with it.

#11

Good point. I think the solution is to not send high-bandwidth data over any link, if it can be avoided. I can imagine three scenarios for using the dual-PIC setup that we’re talking about:

  1. You’re doing compute-intensive work, and you need high-BW I/O that works in real time. The answer to this one is that you do all of that stuff on the dsPIC, and the other PIC (if it even exists) is used for lower-BW tasks, such as sending serial data to an SSC-32. The slower PIC also does any human-interface-related stuff, because it is inherently low-BW.

  2. You simply need some data crunched, but you don’t have time to burden the ‘master’ PIC with it (or it doesn’t have enough code space). So the first PIC sends a packet of data to the dsPIC to crunch on, and the dsPIC interrupts when it’s done, and the master retrieves the results.

  3. You just need more I/O capability than you can get from a single 40-pin PIC. One PIC is the master (you choose which one), and the other just accepts I2C commands to manipulate various I/O devices. For somewhat-real-time stuff on the slave PIC, it would have an interrupt line back to the master to tell the master that it should query the slave to see what’s up.

I think that most folks would only need case 3). Nick can do some fancy schmancy IK stuff and do case 1). The guys (who?) playing with AI techniques may want to do case 2).

Agreed. Once you’re comfortable with using interrupts, it’s hard to imagine doing anything without them. One of the dedicated INTs on each PIC will be wired to the other guy, so that whoever is ‘slave’ (as determined by the code) has a quick way to get the master’s attention. It is possible to add a bit of logic to make a single INT input cover several different signals at once - sort of like the ‘interrupt-on-change’ in the PIC, but implemented external to the PIC.
However, if you’re willing to include the dsPIC on your board, you will already have a bunch of extra interrupt stuff:
It has INT0, INT1, and INT2, just like the 4620.
It has 10 interrupt-on-change pins.
Each type of interrupt source has an 8-level interrupt priority assignment. This means that if multiple ints occur at the same time, the PIC will give priority to the one with the highest, uh, priority…
For more info, check out the datasheet for the dsPIC30F4011 - this is what I will be plugging into the board for myself (there are others in the series with the same basic pin-out that should work also). If you buy one of those, note that there are two speed versions, the “-30” and the “-20”. You want the -30 version.

Pete

#12

As am I! :slight_smile:

I would love to see this sort of on board battery charging scheme implemented in something, if not this project. Even just a charger that could be mounted on a robot and used to charge on board batteries. It would allow us to possibly make “self feeding” robots with an appropriage “feeding” station the bot could find and feed from…

Yes, PLEASE protect me from myself when I am pulling an all nighter and can’t clearly see what power source I am plugging into my bot! :smiley::smiley:

I don’t think the speed if I2C or other serial data communication protocl is really an issue. Consider we won’t typically be transferring very much information between the twp MPUs. We should just be transferring command and status information normally. Anything requiring the transfer of a lot of data, such as video, really needs its own dedicated bus.

Whatever the programming connection used is, PLEASE let it be something STANDARD like a DB-9 for serial or a real USB connector, rather than something that requires and adapter be used. I will be running into this with my Propeller Robot Controller board - it does use USB but does not have a standard USB connector on it. I have to get a $25.00 - $30,00 adapter so I can program my board. I don’t think this is acceptable. I want to be able to just plug a single cable from my PC to the board and go.

8-Dale

#13

This programming connector goes to a PIC programmer, not directly to a PC, so the connectors you mention do not apply.
Microchip’s ‘standard’ programming connector is a 6-conductor telephone-type cable/connector. However, in the real world nobody puts that connector on their own boards, so people end up making their own cable connection scheme…

Pete

#14

This projects sounds really interesting. I’ve never really used any of the more powerful PICs and the thought of a PIC with 120 MIPs is a bit hard to comprehend. Once things start to get this powerful, I almost fail to see the reason not to use some kind of OS and embedded computer, since direct programming of anything worthwhile seems kind of hard. Since I have a number of 100-200 MIPs machines running full Linux installs, I’m imagining trying to program a Pentium I class machine only in assembly and the nightmare that can become. If this is an unreasonable thought, please correct me.

A couple of things to consider. If you want to stick with a dual micro that can offload calculations, why not use a micro with multiple cores. I don’t know of too many off the top of my head, but Parallax’s Propeller has something like 32 (yes, its insane). There are other 8051 based ones too. This gets rid of the nasty interconnect issue. These chips aren’t that expensive either. If you don’t have any experience with Propeller (neither do I), and 8051micro code can be a pain, they maybe just go for a full scale embedded type system.

I’m not sure if this meshes with your design goals, but what about a MIPS based chip as the master running embedded Linux. Broadcom makes some especially nice chips for this. Basically you add a memory and flash chip and you have a full fledged computer. The chips included multiple (at least four) serial ports, a good deal of GPIOs, and even a PCI bus. Programming could be done via JTAG to the flash chip. I’m kind of thinking along the lines of a Linksys WRT54 but with a higher end CPU, smaller board (no ethernet, maybe USB if you can utilize the PCI bus), more memory, and more storage. The slave PIC could be programmed directly from the master’s interface serial with some logic controlled by a GPIO on the master. Since the CPU would be more than powerful enough to do IK, the PIC here would mainly be used for I/O.

I know building such a board seems a little far out, but much of the design of something like that would be connecting the pins in Eagle or some other PCB design suite. Might need a 4 layer board though. I know I could get the base system working, having done a similar thing with a higher-end Z80 based chip (it was an exercise for a class on a breadboard). I’ve never done PCI design, so that might not be so easy. However, if you’re designing a board whose hallmark is it packs a lot of processing power in a small package, why not go all out. There are very few options right now between the microcontroller and the ITX range of control boards, and such options are very expensive. Such a board could fill this void and probably cost less than $100.

#15

Tillin9, thanks for your thoughts/inputs.
I can’t speak for others, but the things you mention, in general, go beyond what I am willing to invest my time into. Things like memory and PCI buses and such are non-trivial to design a PCB layout for (if it runs at a reasonable speed). There’s a lot more to it than just connecting the right pins to each other - the exact location of the traces relative to each other is very important at those sorts of speeds (from the 10’s of Mhz on up). Using a “reasonably fast” self-contained MPU (like a dsPIC) keeps those types of problems contained inside the chip itself, since all pins are essentially I/O (no memory buses, no PCI, etc.).

For those who really want “serious computing power”, and/or something that can run a mainstream OS, a ready-made board is the way to go.

A couple of nits that I think you mis-read or mis-interpreted:
You mentioned that the dsPIC is “120 MIPS”; but it’s really 120 Mhz and 30 MIPS.
You mentioned the woes of assembly, but all this PIC stuff would be in C, using the free compilers from Microchip. I have a lot of ready-made code to do useful stuff on the PIC platform, so we wouldn’t be starting from scratch. Some folks may want to start from scratch though, because that’s the way to learn a lot.

Regarding the dual-processor and interconnect issue: As I said in my previous post, I intend that the interconnect is NOT very high-bandwidth, and it doesn’t need to be. As for the Propeller, I think maybe the jury is still out on useful that architecture really is. There are reasons why the big MCU makers haven’t already done the same thing (they certainly could if they wanted to).

Other advantages (for me) in the PIC-only approach:
I am familiar with the PICs and have the relevant tools and such.
The lack of an OS means I have direct control over everything.
The basic CPU that we’ve been discussing is literally less than a dozen parts, and none of them are ‘tricky’ or ‘special’.
The 2 PIC chips can be bought ‘retail’ for around $6-7 each. A lot of folks might feel that just one is enough.
A PIC is “the right amount of power” for most people’s autonomous robot projects.
The proposed board will serve as a nice “demo board” I think, for quickly trying out new sensors or whatever. Ready-made demo boards (such as those from Microchip) tend to be expensive. Some places sell some blank boards that seem nice, but they’re pretty generic, and don’t include features like FET switches and simple battery chargers.

Pete

#16

I’m sort of surprised by the 10 Mhz limit. I knew that speed caused problems, I mean I noticed the zig-zags on circuit boards and am aware of the theory behind race conditions, etc. However, from seeing projects online with hobbiests making PCI cards (wirewrap too no less) and a number of custom PCB 68K based machines running in the 20-50 Mhz range I somehow thought the limit was much higher. Always nice to learn something, and at the very least this may explain why we don’t get to play with real embedded machines in class. An 8Mhz Z80 is on par with an 8080, Mac Classic, or modern midrange printer in terms of processing power.

The 120 Mhz/ 30 MIPs bit explains a lot of my misunderstanding about the scope of the project and that it is still in the microcontroller realm. I am the first to admit that a custom embedded system is a tough job, even if you have lots of experience in that area. I also sort of saw PIC and immediately thought assembly, having never used a high-level compiler with one. However, that does seem to suggest programming would be much easier than I anticipated.

Unfotunately, it seems the board wouldn’t have enough computing power for what I was originally planning. However, depending upon price I would still probably be interested in one for having a quality PIC testbed, especially since I haven’t used high-end PICs or a C PIC compiler. The dual processor feature would come in handy since I have a nasty tendancy to bit off more than I can chew in projects, and I like the idea of being able to add a second CPU in such a case. Also, I see something like this helping me kick the BASIC stamp habbit (never learn your microcontoller basics with a stamp if you can help it, as even after you learn other systems you tend to use stamps since they’re so easy), as $6 for a high-end PIC seems a lot more reasonable than the $75 per high-end stamp. The only trouble is getting more familiar with them.

#17

I think you sort of mis-read me again… What I said was “10’s of Mhz”, which I intended to mean “in the area from 10 to 100 Mhz”.

There is no firm limit on what you can build without applying a knowledge of Field Theory and Transmission Lines. You can almost certainly make 10 Mhz work, simply by hooking up all the right wires. By the time you get to 100 Mhz, you had better be doing a ‘formal, correct’ layout, with ‘controlled impedances’. This requires specialized experience (which I don’t have).
Regarding wire-wrap: A long-time technician friend told me that it is “possible” to make a wire-wrap circuit work at up to 100 Mhz, if you are using ECL logic, and are very careful about the wire routing. But we’re not using ECL any more, so the practical limit is much lower.

Pete

#18

Oh I couldn’t let this go lest I feel old or something. ECL is still used, just not in some of the same applications as it used to be the ‘standard’ for. Also, many of the newer technologies are drawing off of concepts and design techniques that used to be soley in the domain of ECL designs. I submit LVDS vs. 2.5V PECL for consideration. :wink:

On topic though, you are quite right that the problem becomes as frequencies go up the connections start taking on transmission line properties that can be ignored as parasitics at lower frequencies. Capacitive coupling, ringing, reflections, and propagation speeds are all becoming significant layout factors as designs push 100MHz+ bus speeds. When you start getting 200MHz+ we start reverting to that ECL type design using impedance controlled differential pairs for each signal in a bus. :slight_smile:

#19

You guys definitely know much more about this than I do. I had to wikipedia ECL (en.wikipedia.org/wiki/Emitter_Coupled_Logic), though in retrospect I think I did encounter it briefly in lecture, never used anything like that though. Sorry for misinterpretting yet again. 50-100 Mhz is more around the boundary that I was envisioning just from observing what people were capable of doing.

Now that I know this, I’m probably not going to try a project like this anytime in the near future (read before taking many more graduate-level EE courses) but what type of CAD tools would you recommend? Protel seems like it would be idea for this sort of design, though well beyond my price range. I doubt there are any open-source type projects for professional level stuff, though that would be idea. I actually have a copy of gEDA though haven’t really used it much, and thought of it more as a low-end Eagle replacement. Though, I don’t think Eagle or other similarly priced tools can even do autorouting at high transmission speed, but might be wrong here.

Thanks again for all the insight.

#20

Today I put a dsPIC30F4011 on a breadboard just to try out the ‘basics’, since I had never run a dsPIC before. It was just the PIC, some bypass caps, an 8 Mhz crystal, and an LED; then I burned code into it to flash the LED.

I did indeed get the dsPIC to run really fast (up to 128 Mhz), but I was reminded that there’s a penalty for speed: power consumption.

Here are some clock speeds, and the associated power consumption just running a for-loop that does nothing (these figures were measured with the LED removed):

speed current
8 Mhz 12 mA (not bad!)
32 Mhz 38 mA
64 Mhz 71 mA
128 Mhz 130 mA (!)

128 Mhz is actually slightly over-clocked - the official limit is 120.

Pete