3
\$\begingroup\$

I'm thinking about buying some Arduino development kits to migrate from my actual development platform (picaxe) to Arduino. I want to buy just what I need to develop my next project, but taking in consideration that I am a total ignorant of the Arduino capabilities I have some issues trying to decide what to buy. So I decided to explain you what I want to do and what I think I need (in terms of hardware) hoping to have some feedbacks.

Ok the idea is simple, over the serial cable my computer (or USBtoserial) I will send some commands to my Arduino Uno board: these commands are composed of several bits (defined in my own protocol); anyway, after my Arduino has received this commands it will take some actions, at the moment the only action that matters is to send a word to other Arduinos connected to a communication bus (need to decide if I2C, serial or TTL). This word is composed of 1000 bits, the firsts 8 bits are just the header (containing the address of the chip that will receive the data) and rest is just data (the actual length of this word is always fixed to 1000 bits).

So in summary this is what I will do: enter image description here

For example, from the PC, I send the command over the serial cable: 110110111010101010011…….01101. This goes to the Arduino board who resend it to the communication bus where all the other micro controllers are always listening to the bus, they will read the first 8 bits and compares them to their own address: if it matches the micro controller address (stored in a variable), it will store the next bits on memory (if the power goes off I don’t need to save the informations, so it could be a volatile memory).

After that the micro will be waiting for a future command that will eventually tell him to output the data bits over an output pin. All the micro will only save one word of 1000 minus 8 bits at the time, so the memory is fixed for just 9992 bits.

I'm having problems to decide which small microcontroller to use, which communication protocol to use and some issues with the software. Taking is consideration that the distance between the first micro and the last one could be up to 7 meters I think that I2C is not the way to go, serial will be great but that means that I will need a serial to ttl converter on each micro (take in consideration that they could be up to 128 micros) so that can make the project to go out of my budget, TTL will be great but I never tried a communication via TLL over 7 meters, what do you think? I think a good cable will not drop so much voltage in 7 meters, also the speed I thinking to use is max 19200bits/s.

About the micros, my biggest concern is to choose the cheapest alternative because they will only receive data in one pin (serial data) saved in a volatile memory, and then output that data at a fixed rate over an output pin (to light up and off a led for example). I saw on internet that you could program the ATtiny with the arduino board, is this chip capable of doing what I need? Do I need an external memory to store the data? Or I can save it on a variable? (what memory you suggest?)

enter image description here

And my final question is about software, when I was using PicAxe, a very simple development kit for microcontrollers when I need to store a word over a serial input I just make this:

serin serpin,N2400,(27),seraddr, b4,b5 

Where serin is the command to begin the serial acquisition, serpin is the number of the input pin I want to use and b4 and b5 are four bits variables so using they two I have a 8 bits word. The PicAxe platform is fixed with 10 4 bits vars (b0,b1…….b9) so it will be imposible to store a 1000 bits word without passing the information to an external memory. With the Attiny I can store that amount of data on a program var? What is the maximum I can store? At the point do you still think the attiny is the way to go?

Thanks so much for any feedback and suggestion!

\$\endgroup\$
  • \$\begingroup\$ Few lines per microcontroller; much data; "long" distance -> IMHO UART is the way to go \$\endgroup\$ – clabacchio Feb 4 '12 at 19:35
  • 1
    \$\begingroup\$ "All the micro will only save one word of 1000 minus 8 bits at the time, so the memory is fixed for just 9992 bits." do you mean 992 bits (1000-8)? \$\endgroup\$ – Jon L Feb 4 '12 at 21:05
1
\$\begingroup\$

Most small microcontrollers will be capable of doing what you need. You could even ditch the Arduino "wrapper" and use a USB capable micro in it's place.

Microchip, Atmel, TI, ST, etc all have 8, 16, 32-bit uCs of varying RAM/FLASH/EEPROM sizes to pick from. All the modern uCs come with at least UART, SPI, I2C peripherals that can be used for your communications.
There is not a lot in them really, I'd just pick one and see how you like it.
I (currently) use ST's 32-bit ARMs and Microchip 8, 16 ,32-bit PICs.
I'd probably use a few PIC12F or 16Fs for the slave uCs and a PIC18F or PIC24F for the master.

You mention needing ~10kbits of memory (not quite clear what type or which uC needs it from your description to me though)
It's easy to determine what is suitable though, just check the RAM/ROM/EEPROM specs of each uC you look at.
For example the PIC16F1938 has:

 Parameter Name          Value
 Program Memory Type     Flash
 Program Memory (KB)     28
 CPU Speed (MIPS)        8
 RAM Bytes               1,024
 Data EEPROM (bytes)     256 

So 28KB of program memory is more than enough to store non-volatile data if your program is small enough (on the newer PICs you can also read/write to program memory at run time) 10kbits will not quite fit into the RAM though, at 1024 * 8 = 8192 bits.
The 16F1527 has 1536 bytes of RAM though, so you could use this if necessary.

For the master (alternatives to Arduino) there is something like the 18F25J50 or similar, which has a USB 2.0 peripheral. Microchip provide a USB stack an plenty of example firmware to get you started with USB.
If you need something more powerful for the master, have a look at the PIC24 series with up to 256K of Flash and 96K of RAM. Or even the PIC32 which is 32-bit and up to 80MIPS. The PICKit3 is a low price programmer that will program all the above mentioned PICs, and MPLAB (or MPLABX) is a free IDE for firmware development.

Communication can be done with I2C, which deals with the master/slave configuration and addressing easily. All you have to worry about is sending the data. 7 meters should be no problem with a reasonably quiet environment and the right setup (low value pullups - say 2.2k, low capacitance cable)

\$\endgroup\$
3
\$\begingroup\$

As you are already planning to use an Arduino, why not stick to Arduino's? Or get yourself an AVR programmer and use bare ATMega328 chips.

As for the communication: RS485 is a very reliable bus, and the transciever chips are cheap. For even lower cost you could send a TTL-level signal and regenerate it at each node.

\$\endgroup\$
1
\$\begingroup\$

Take a look at the TI MSP430 series. They are really low cost (start at under $1.00) and features increase with price up to quite powerful little SoC devices.

\$\endgroup\$
0
\$\begingroup\$

Regarding your distance concerns, check out these chips: I2C bus extenders. They are made by a few different manufacturers, you can find one that fits your needs and budget.

I think I2C is a good choice for the protocol here given that you want an addressable scheme. Arduino sounds like it can do what you want (seeing as they all have UART and I2C capability), but really any microcontroller with those peripherals will do the trick.

As @Oli Glaser mentioned, using a stronger (smaller) pull-up resistor will help as well, but if that can only get you so far, definitely check out the bus extenders as I've had success with them before.

Regarding your size concerns, check out the specs of the microcontroller that you're looking at. Specifically you want to look at how much SRAM it has. You mentioned that you want to buffer 1000 bits == 125 Bytes. SRAM spec is usually given in KB (Kilo-Bytes) so be sure to choose one that is larger than that. If you are using more buffers in your code as well, or your program is somewhat complex (large and many function calls) then you will probably want at least 512 bytes - 1KB of SRAM. It is hard to determine how much you need without knowing more about the application. If you don't need all of the 125 bytes at once, you can stream it in and out of EEPROM as well.

\$\endgroup\$
  • \$\begingroup\$ I don't think this is the way to go, especially to send that amount of data; to me UART seems a more reliable protocol, also because he doesn't need to save in terms of pins or lines. \$\endgroup\$ – clabacchio Feb 4 '12 at 19:34
  • \$\begingroup\$ @clabacchio, unless you're suggesting to add a checksum to the protocol, I can't imagine how UART will be any more or less reliable given that you haven't made any comment about cabling or shielding or provided any facts or evidence. Can you please explain how? I made my suggestion for I2C based on the addressable master/slave architecture he specified, and because I2C already takes care of all of that. \$\endgroup\$ – Jon L Feb 4 '12 at 19:42
  • \$\begingroup\$ Premise: that is my idea, based on my knowledge and I don't pretend at all to have the absolute truth. Then, AFAIK, I2C is an interface designed for intra-PCB communication, as also the name suggests. Being open drain, it's not really robust, and I would rather use a stronger protocol such as UART. Then, it's true that cabling and shielding considerations are necessary, but my objection was purely on the fact that it's strange to send signals in 7m wires with I2C, and I've never seen that. \$\endgroup\$ – clabacchio Feb 4 '12 at 21:19
  • \$\begingroup\$ @clabacchio, agreed, it is strange, which is why I suggested the bus extender IC's to enable that ability. I agree that UART over RS232 signalling would probably perform better over those lengths, but I weighed the fact that you would need to write your own master/slave protocol instead of using a hardware peripheral. All things considered, I don't think either are bad ideas, just compromises. Thank you for the response. \$\endgroup\$ – Jon L Feb 4 '12 at 21:31
  • 1
    \$\begingroup\$ @clabacchio - I2C is mostly used for intra-PCB stuff, but there is no reason why it can't be used over longer distances. This is why buffer ICs are available. I think 7 metres should be achievable without a buffer depending on the number of slaves and correct setup. Here are a couple of references mentioning using I2C up to 100m 1. I2C FAQ 2. I2C distance related post \$\endgroup\$ – Oli Glaser Feb 4 '12 at 23:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.