Hi all, this is the question: which is the fastest method to exchange informations between two 8-bit mcus?
I'm developing a tacho unit for a friend's go-kart. As long as I'm planning to use multiplexed 7-segment displays, I want to dedicate one micro to the multiplexing job and the other one will perform measurements and other operations ( the tacho is only a part of the things I want put on the kart )... maybe I'll use two PIC16f877a.
To have all finally working, I nedd them to comunicate, with the one telling the speed to the other. My ideas were:
-to use interrupts and serial or I2C-bus protocol, with the display-manager interrupting the other to get updated data. My doubbts are about lags: if the comunication is too long, the displaying won't be as clear and fluid as it must.
-the use of a buffer: I planned to use an 8bit buffer formed by 8 D-Latch flip-flops and interrupts between mcus, so when the one is writing the other doesn't read and vice-versa... but it can be quite expensive.
-the use of a shared memory, for example an I2Cbus EEPROM shared between the two micros, and the interrupts acting as above.
Any more ideas? THX in advance, I won't forget to add You in the "Special THX" list when I'll post the project ;-)
I have never used I2C myself but checking Wikipedia tells me that low-speed mode is 10 kbit/s (I think that’s the slowest speed you can have). 10 kbit/s would give 10240 bits/s = 1280 bytes/s. 2 bytes should be enough for tachometer (0-65535). So you’d get 640 updates per second (1280 / 2). That should be more than enough (and that’s the slowest mode). Of course there’s some protocol overhead so you would not get the max theoretical speed. Anyway, I think I2C should be fast enough. But then again I’m no expert. Guys who have really used I2C would know better.
Don’t forget to consider parallel comms: 7 or 8 lines from output pins to input pins on the second mcu. Sure it’s a waste of pins, but if you should have them to spare, why not use them.
In picaxe basic the reading of one byte would be as easy as “b1 = pins”. And fast as heck.
Forget about comms protocols, forget about buffers and forget about shared memory - just use the built-in USART modules.
What are you using to program these PICs? USART is dead easy to configure in Assembly, so I can only imagine it’s at least as simple in higher languages. You can get data rates of up to Fosc/4 in synchronous mode (5000kBaud for a 20MHz oscillator), and because you control the transmission yourself you can leave out parity and other data overheads. The USART modules run themselves after you configured them, all you do to transmit is write data to the TX register, and receiving data works the same way - there’s a flag to tell you if new data has arrived, which you can use to trigger an interrupt or you can just poll it. The read register is also hardware buffered, so you can get new data as often as it is available.
USART only requires 2 lines (clock and data in sync. mode), with no pull-up/down resistors or anything to worry about. Just wire the USART pins on one micro to the pins on the other and you’re done.
Yes, I forget to specify that I planned to use the 8bit buffer with parallel 8 pins. It isn’t a problem regarding to pin waste… the problem is the complexity of buffering circuitry. Because the information are two, the speed and RPM of the motor shaft, I need two buffers switched between by some logic.
I don’t want to put them directly connected to prevent lags: I each mcu makes its job separately is better ( I mean one reads and the other writes the buffers when they “wish”).
But You’re right: the speed of this comunication is the best!
When I wrote serial I was meaning the usart module.
But I didn’t know alle these details… so Thank You! The use of assembly isn’t a problem for me and the RX interrupts and the buffered read registry are great news for me.
I’ll try to implement it and for now I think is the best way.
