1k of Program Space, 64 bytes of RAM. Is 1 wire communication possible?

(If your lazy see bottom for TL;DR)

Hello, I am planning to build a new (prototype) project dealing with physical computing. Basically, I have wires. These wires all need to have their voltage read at the same time. More than a few hundred microseconds difference between the readings of each wire will completely screw it up. The Arduino takes about 114 microseconds. So the most I could read is 2 or 3 wires before the latency would skew the accuracy of the readings.

So my plan is to have an Arduino as the "master" of an array of ATTinys. The arduino is pretty cramped for space, but it's a massive playground compared to the tinys. An ATTiny13A has 1k of flash ROM(program space), 64 bytes of RAM, and 64 bytes of (not-durable and slow) EEPROM. (I'm choosing this for price as well as size)

The ATTinys in my system will not do much. Basically, all they will do is wait for a signal 开发者_如何学Pythonfrom the Master, and then read the voltage of 1 or 2 wires and store it in RAM(or possibly EEPROM if it's that cramped). And then send it to the Master using only 1 wire for data.(no room for more than that!).

So far then, all I should have to do is implement trivial voltage reading code (using built in ADC). But this communication bit I'm worried about. Do you think a communication protocol(using just 1 wire!) could even be implemented in such constraints?

TL;DR: In less than 1k of program space and 64 bytes of RAM(and 64 bytes of EEPROM) do you think it is possible to implement a 1 wire communication protocol? Would I need to drop to assembly to make it fit?

I know that currently my Arduino programs linking to the Wiring library are over 8k, so I'm a bit concerned.

Since you only need to send data (which is simpler than receiving) and you can select your own protocol, it should not be a problem to fit the code in the available memory space.

I once created software for an industrial control panel that contained 8x14 segment LCD display, some LEDs, some buttons, a serial (I2C) EEPROM, and serial interface to the host. A 4 bit processor was used. The device did not have any serial interface, so both the RS232C interface and I2C bus had to be implemented in software. On top of that, there was Modbus protocol (which among other things requires CRC calculations some exact timing), and the application program.

The device had some 128 x 4 bits of RAM and 1kW, 2kW, 3kW or 4kW of ROM (10 bits per word). The size of the final program was about 1100 words, so it did not quite fit in the smallest device. I used Assembler, of course.

However, instead of using multiple microcontrollers, you could consider using a hardware solution.

You could use a sample and hold circuit. For that, you need an array of analog switches and capacitors and perhaps op-amps. Just issue a trigger to latch all the voltages into the capacitors. Then you can use as much time as you need to read the voltages with your master processor.

Update: Forgot to mention that there are ready-made sample-and-hold amplifiers that need very little or no external components. This is probably the easiest solution.

1k of program space should be plenty, considering that your protocol only needs to be complicated enough to send a single integer when tickled. Look into Manchester Encoding.

You can probably get away with using a C compiler that targets this architecture, but you'll have to create your own runtime environment and not rely on the one supplied with the compiler. That's doable, but I'm not sure if the additional work to essentially create your own mini-OS outweighs the productivity benefit of using C over assembler.

I've done embedded programming in similar constraints. I used Borland Turbo C (it was a long time ago) in the tiny model and obtained code that was hardly bulkier than I could have done in assembler, with a fraction of the effort. What I'm saying is: It's quite feasible and sensible to use C as a high level assembler.

Just like me, though, you will be facing the problem of providing C with a (tiny) runtime environment. Ideally, you will only need to set up the stack and a few registers. Also, you won't have room for the C library, so you will need to program any needed functions yourself.

Yes, probably, though if you know your compiler very well you might be able to get away with c.

What you could do, is use a compiler to emit any standalone functions you need based on c code, then glue them together with a little of your own. (You'll certainly have to do the c runtime setup yourself - stacks etc.)

You may consider upgrading to the ATTiny25. It is a more capable 8-pin AVR that includes Atmel's Universal Serial Interface. It is capable of doing 1-wire serial comms in hardware, given only a few bytes of software.

Why wouldn't you just use sample-and-hold hardware, rather than a pile of microcontrollers?

I designed a master-slave system recently using an AT90USB646 master and ATtiny85 slaves. Obviously I had a lot more memory to work with on the slaves, but what I wanted to share with you is this:

With regard to your communication protocol, bear in mind that the uncalibrated internal oscillator on the ATtiny13 has an accuracy of +/- 10%. This means you won't be able to use, e.g., RS-232 communications.

I used a variant of the Dallas 1-Wire protocol in my system. Including full support for slave enumeration etc., the C source code compiles into 1626 bytes.

Edit: Whoops, didn't realize the question is so old. Hopefully this may still be of some help.