I've been searching for discussions on the forum about programming an AVR chip as a dedicated peripheral and have had no success. Does anyone recall a thread that might be applicable?
While looking for a source for an obsolete timer/counter (MC6840) it occurred to me that I could probably duplicate all the functions I wanted with one ore two ATTinys or at the worst an ATmega8 and not use the board space that the old chip would.
I need to think through the best way to generate and poll for interrupts as one would want that to work as well as it did on the old parts. I can envision handling 8 interrupts by wiring 8 AVR I/O pins to an octal bus transceiver and an 8 input NAND gate to generate the interrupt. The interrupt service routine could then read that "register" to see what peripherals had generated an interrupt but I'm not sure how to clear individual bits to simulate how you would do it on the legacy part.
This may belong in another section. Or on another planet.
AVRs are so cheap now, it makes sense to use them to replace other chips.. Even if it is an underuse of an avr by our standards.
When using 16x2 LCD's, I hate wasting all those pins. Atmega8 costs $1.20, two caps costs a dime, internal oscillator is fine.... And makes an awesome serial and I2C interface chip. For a buck thirty, you can build character sets, handle sprites... Etc..
I am also going to do something similar with a 328 and the TVOUT lib.
All of a sudden, using a "whole" avr doesn't seem like such a waste...
PapaG:
While looking for a source for an obsolete timer/counter (MC6840) it occurred to me that I could probably duplicate all the functions I wanted with one ore two ATTinys or at the worst an ATmega8 and not use the board space that the old chip would.
I suspect that is true; that duplicating the functionality is possible. It does look like a lot of work.
But, I believe the bus timing is going to be the hitch-in-your-get-along. Assuming I'm reading that datasheet correctly, the MC6840 is expected to have data available on the bus within a small number of nanoseconds of the control line(s) being asserted. Even clocked at 20 MHz and staging everything in anticipation of the control line being asserted, I don't think you will be able to meet the deadline.
focalist:
AVRs are so cheap now, it makes sense to use them to replace other chips.. Even if it is an underuse of an avr by our standards.
When using 16x2 LCD's, I hate wasting all those pins. Atmega8 costs $1.20, two caps costs a dime, internal oscillator is fine.... And makes an awesome serial and I2C interface chip. For a buck thirty, you can build character sets, handle sprites... Etc..
I am also going to do something similar with a 328 and the TVOUT lib.
All of a sudden, using a "whole" avr doesn't seem like such a waste...
I agree. I was just looking at the ATTiny2313 to make an LCD "backpack". It has a full 8-bit port and a USART and is even smaller than a 328.
We may be talking about different things. I would preprogram the AVR to perform some 6840 function(s). Lets say generate an interrupt at 1 second intervals to update a display, 60 Hz interrupts to scan a keyboard matrix and 1 minute interrupts to trigger something else. It wouldn't be necessary to mimic the data bus I/O in that case, only figure out how to reset the interrupt outputs. I suppose the MPU could even communicate with the AVR via USART or SPI as part of its interrupt service routine to prioritize and reset interrupts. That part requires more thought because you would want to reduce the latency as much as possible. Does that make sense?
• Timer 0 on most (possibly all) of the processors is identical.
• More recently introduced ATtiny processors typically have two timers.
• The second timer on ATtiny processors can be very unique. Timer 1 on the ATtiny85 is a good example. There is nothing else like it in the AVR product line.
• The second timer on ATtiny processors can be very similar. Timer 1 on the ATtiny84 is a good example. It is identical to timer 1 on ATmega processors.
• If accuracy is not very important, the internal oscillator works a treat (±1% after tuning).
Thanks, that is helpful information. I was looking up all those facts and you've summarized them nicely for me.
As for accuracy, one could probably drive them with a precise clock already available because of the other MPU. You could even use the crystal on the AVR and scale that clock down to drive the MPU clock input as I think the prescaler scales clock out on some AVRs.
I was looking up all those facts and you've summarized them nicely for me.
Atmel does a terrible job of providing a quick summary of processor information (in my opinion). I've always ended up back at the datasheets.
As for accuracy, one could probably drive them with a precise clock already available because of the other MPU.
Yes. Even the lowly ATtiny13 can be driven from an external clock signal (but not a crystal or resonator).
You could even use the crystal on the AVR and scale that clock down to drive the MPU clock input as I think the prescaler scales clock out on some AVRs.
True. On the other hand, the timers would operate as programmed and that would probably be okay in a lot of applications. I don't envision the AVR doing much programmatically after setting everything up.
So, in the meantime I found some 6840s at Jameco so I'll be able to compare the real thing to an AVR peripheral.
I think there is much to be said for focalist's observation, in that AVRs could be dropped around in a project like we used to do with logic chips. That could solve some problems writing the program for the main AVR as the peripheral AVRs would be the analog of multiple threads.
