Choosing a PIC controller

As long as you use the right half, no. ;-)

I2C is overly sensitive to layout and can be a PITA. SPI is far easier to deal with.

I much prefer SPI. You can *easily* bit-bang it if need be.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Don't understand this last phrase.

It probably doesn't matter much. Just choose one you can get a cheap development kit for and has the I/O that you need. Your needs don't seem to be extravagant, so cheap and _available_, including tools, should be your key objectives.

"SPow" schreef in bericht news: snipped-for-privacy@o30g2000yqb.googlegroups.com... Hi,

I have been reviewing farnell's shop to get an idea of existing PICs, but I am clueless regarding which one i should choose.

The PIC is connected to an accelerometer (input) and has 2 outputs, one that is either 0 or 1 (solenoid command) and an additional EEPROM to store measurements from the accelerometer (associated to time measured by the PIC itself)

I guess i have to take a 16 pins-PIC in case there are additionnal input we forgot about. Is it a problem if you only use a half of the pins ? I read that an I²C bus is an easy way to communicate between accelerometer/PIC/EEPROM, but it's not singlely available for a 16-pin PIC.

On farnell mainpage, i searched for '16-pins' which leave 'AUSART, I2C, SPI' / 'EUSART, I2C, SPI' and a few others selectable. There doesn't seem to be any I2C only 16pins PIC, so which additionnal interfaces should i select ?

What i know from my system is that it doesn't have to be very quick,

10 to 20 measurements a second is pretty enough. It needs a timer for 2 reasons : at a specified time, it'll have to force a solenoid open, and keep track of the time on the additional EEPROM.

I'm pretty clueless about how i am to choose the controller, and would much appreciate help on this subject. Thanks for reading.

Why go for a 16pins PIC? If space is a problem, you can use even a 14 pins type but remember the smallest one is not necessarily the cheapest. You have to do a lot of programming to implement I2C but the code you need is available on the net. For the I2C you need two I/O lines but you can use these same lines for the EEPROM as well as for the accelerometer (assuming that meter to have an I2C interface.) You can use every output pin te drive your solenoid though not directly.

BTW How do you get your information out of that EEPROM?

To make live easy I'd go for a 20 pins 16F677. It's hardly more expensive then others (I can have them for under 3 Euros a piece ex shipment) but is has full master/slave I2C support, 256 bytes of on chip EEPROM, an on chip UART and still a lot of pins remaining for expansion. FAIK it's the smallest and cheapest one with I2C master/slave support.

petrus bitbyter

Why are you specifying a 16 pin chip?

I2C is available on the 20 pin PIC chips.

What is your ecperience level with microcontroller programming?

My guess is that this may be a school project, so the simplest solution is a PICAXE chip:

These ae MicroChip PICs with a BASIC interpreter - not as fast as a "naked" PIC, but much easier to program and probably fast enough with a 16MHz clock.

The 20X2 has hardware I2C and SPI and is about $6US. The programming software is free from Rev-Ed and there's a very helpful forum that welcomes all skill levels from newbie to expert:

I'm currently developng a prototype animal training device using a 28 pin PICAXE (28X2 - about $11US) that talks I2C to a floating point math chip (uM-FPU) and a 32Kx8 EEPROM. Even on a breadboard, the I2C is very stable.

John

In general, unless you're very tightly cost or space constrained, or unless you know _exactly_ what you're doing, you always want to get a processor with extra pins. Furthermore, you want to lay your board out so that you can easily mod it for access to those pins (terminating the pins at an accessible via is a great big plus).

Do that, and when some requirement comes down the pike that you didn't anticipate, or when some technique that you thought would work doesn't, you have pins to play with. At worst, you'll have lots of pins to use for instrumenting the software so you can look at timing with an oscilloscope (spare pins: the printf of deeply embedded systems).

Yes, you can have unused pins. Just make sure that they're pulled up or down if they're configured as inputs (most modern microprocessors do this internally, so you don't have to). I would add to this that when you should decide on a candidate processor for the 'real' system, but for your first prototypes you should go out and get the Very Biggest one that has the same peripherals and core (i.e. if you're getting a 20-pin

18xxx for production, get the 20-pin 18xxx with the most code and RAM space that you can find). That way you won't find yourself running out of code or memory half way through your project -- it's always easier to trim from something functional, but it's pretty darn hard to make something functional when space is tight.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Microchip have an online parts selector application. I find it quite useful:

--
RoRo

You can write your own I2C protocol in the PIC via an INT and unused IO lines.

That is what's great about this whole thing..