I would pay for your SPI interface to control the ATMEGA series... I don't like the fact that it is controlled by SPI, but that Atmel Atmega series is something to be desired.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

You could easily change from SPI to another serial protocol, such as I2C or RS-232 (even a 5v logic-level RS-232). A parallel interface could be made but the handshaking for Read and Write access would be more complicated that it would be worth. A one-way parallel interface would be a snap.

The AVR series is fun to work with and the instruction set is similar to the 6502.

Daryl

Funny, I find absolutely nothing in common between the AVR and 6502 instruction sets.

As far as "fun" to work with, that depends on whether you're hacking on the original set of 64 I/O ports (more than half of which was wasted on non-I/O related cruft because the original AVR microcontrollers lacked SRAM!) or if you're using the 160 "extended I/O" registers, which are ONLY accessible by dereferencing the X, Y, or Z pointer registers.

Worse still, the AVR instruction set lacks an immediate-form of exclusive-OR. Who the hell thought that one up?

AVR's highlights include a reasonable instruction set (certainly better than PICs), reasonably fast execution rates (most instructions are single-cycle; however, you often need more than one instruction to accomplish something useful), and a reasonable interrupt model. And, the units are cheap, and seem quite simple to program.

That being said, what is wrong with SPI? Controlling peripherals via SPI is trivial to do, and if you want a general purpose, bidirectional communications link, I would recommend implementing something like HDLC framing procedure (using byte-stuffing, like PPP) over it. Alternatively, you can use a newer technique, called Generic Framing Procedure (GFP), which is very lightweight from a data-link perspective.

I'm finding that the RS-232 link on my Arduino boards are not reliable. The ATmega328p and FTDI-232C chip are no more than a centimeter away from each other, and yet, I'm getting dropped bytes all the time. This only seems to happen when I connect my two Arduino boards together (e.g., port-to-port connections). Strangely enough, the o'scope shows no ground-bounce.

I get zero bit-error rate between my Arduinos when talking to each other via bit-banged HDLC. I'm finding a bit-error rate in excess of 10^-3 (sometimes 10^-2) on the RS-232 port. The explanation eludes me. I should point out that if the FTDI chip receives a byte, it's (so far) correct (e.g., no bit errors inside an RS-232 frame). However, for some reason, the FTDI just seems to miss bytes sporadically. Whether this is due to a bug in the Linux drivers, the FTDI chip, or actually is some unexplained and currently undetectable electrical phenomenon in my circuit setup, I'm not sure. But, it's annoying.

I am more "old school". I prefer a parallel interface... But I responded because what I am looking for is a high resolution frequency generator/divider, and the Atmega series can do it from what I've read. I can do my own logic but it would consist of many IC's...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I recommend the ATmega328P chip -- it has 3 I/O ports exposed to the world. One is 8-bits wide, and the other two are somewhat truncated due to pin limitations (you can get larger chips, but the 28-pin devices are pretty convenient to play with). The I/O ports behave not entirely unlike 6522 VIA ports. They don't have hardware hand-shaking like the 6522 does, though, so you'll need to implement that yourself. Every I/O pin can be an interrupt source as well (via "pin change" interrupts), so you don't have to busy-wait on the port unless you're looking for the utmost in speed.

If you want more 8-bit wide ports, you can get the ATmega32, which is the 328's 40-pin big brother.

Are the system clocks for the boards set to provide exact BAUD rates, or are they approximate. Depending upon your BAUD rate, and the amount of continuous data your are sending, the drift might be resulting in a missed byte periodically.

I'm not trying to belittle your experience, as I beleive you have much more than I do when it comes to data protocols and such. I did find that xmodem transfers on my ATMega8 and ATMega32 resulted in block resend errors if the system clock did not yield exact BAUD rates. For instance, a 16MHz system clock does not provide standard BAUD rates, but a 14.7456 MHz or 17.832MHz clock will.

Just a thought...

Daryl

You know, I never thought to ask that question -- that is a very good point. I'll have to research that. What is the solution though? Do I simply add some delay between the bytes to give the FTDI receiver time to reset its clock phase between bytes?

Yes, it looks like the bitrate I'm using, 57600, produces a 2.1% error or so, based on my calculations, and is confirmed by the data sheet. I didn't pay that much attention to it because I thought the RX clock recovery circuit would re-synchronize on every start bit. Apparently, I was mistaken.

My solution was to replace the system clock with one that matches the baud rate generator. adding some delay between bytes might fix that, at a cost of throughput.

We all shy away from the unknown, and I suspect that's why you wouldn't like the serial interfaces. But serial interfaces dramatically reduce the amount of work needed to wire things up, as well as reducing the number of ICs and the board space required, making you more productive and allowing hundreds of times as much I/O from a small computer that puts all of its I/O through one or two 6522's.

The software to drive SPI even by bit-banging is very easy, not having any timing requirements to speak of like RS-232 does. RS-232's timing requirements are very stringent; but for SPI, as long as your program raises or lowers the chip-select, data-out, and clock lines, and samples the data-in line in the right order, there's no timing requirement at all. Your clock speed doesn't matter. It doesn't even have to remain consistent through one byte. You can even pause a byte transfer in the middle to go service an interrupt, and come back later to finish, and it won't matter. SPI has no such thing as a framing error, needs no false-start detection, etc..

I put a concise description of the various serial interfaces here.

Try a baud rate which is a factor of 16MHz and 12MHz, the clock rates of the AVR and FT232 respectively (The FT232 may actually operate internally at 48MHz - I'm not sure)



PIC16s/12s/10s, certainly. PIC18s, probably. PIC24s/dsPICS? No. The dsPIC family C compiler is very very good, and the architecture has nothing in common with the 8-bit PICs. For the same price as an AVR, you'll get more flash, more RAM and it will operate at 30MIPS (dsPIC30) or 40MIPS (dsPIC33/PIC24H, 3.3v only).

(The other great thing is that my PICKit2, a steal at only ~$35, can program everything from a 6-pin PIC10 to a 128-pin PIC32)

I don't care about C compilers, I do my coding in assembly.

Also, let's compare apples to apples here. There also exists an AVR32 instruction set series of microcontrollers too, but I've not used those. 8-bit AVR to 8-bit PIC is no comparison.

Although, honestly, I'm most at home coding for the Intellasys and GreenArrays chips.

The only time these days I get out something smaller than a dsPIC is when I need something 8 pin. There is, unless talking in 1k unit prices, no reason to go for an AVR, PIC16 or 18 over a dsPIC. There is no reason not to compare the dsPIC and AVR 8-bit families.

The dsPIC assembly language is very nice and regular - it's a very clean RISC. (A slight irregularity is that you have to execute the DIV instruction a number of times - though using the REPEAT instruction this becomes very fast).

Sure, I, like you, prefer working on more powerful processors; but in some cases, a small microcontroller is all you need, and unless you need to squeeze into an 8-pin package or are designing something to be sold in huge quantities, theres no reason to choose something smaller than a dsPIC.

(P.S. I can't find a distributor for the SeaForth chips you mentioned; they're interesting, though I feel I prefer the XMOS chips)

I'm writing in assembly language because my work requires precise timing, not because I need a small unit.

You're missing my point here - which is that people tend to dismiss all PICs out of hand based on the awfulness* of the 8-bit architectures, without considering that the 16-bit models, which are aggressively priced, and have more features than the ever-popular AVRs.

* Awful to program on, anyway; I have a feeling they may be close to the smallest 8-bit processors in use, though.