Well I am pretty advanced with AVRs, I write alot of weird stuff with AVRs. I have written LED sign controllers, desktop consoles/keypads, Scoreboards, Other various display controllers. Input controllers, Even an MP3 player with IDE support. Then some random systems and control stuff like an Ice machine control board I used an AVR on.
But the problem is, AVR is pretty capped at 20mhz. Some might go higher, but the I/O is limited. That begs the question, Why not use another CPU? why the AVR? Well at the time I was getting into microcontrollers, I had AVRs at hand, and a shitload of them at my fingertips. So I got into programming on the AVR. ASM at first, then BASIC but not C. I should have taken C classes in school but didnt, took basic instead. whoops. Well BASIC will compile on AVR so that works for me. So from that point, I sorta stuck with AVR and became a big AVR fanboy.
Now of course, theres the PIC line too. Which have much higher clock speeds, But they dont have the 1 cycle execution time the AVR has. Maybe newer chips do, I dont know, but PIC is still a choice as they make BASIC compilers for PIC as well.
But with that aside, for these applications, I/O is a big thing.
Propeller would be nice, you can taskroute individual interrupts/subroutines to each core. But the I/O is limited.
HOWEVER.... Something along the lines of a 5V CPLD as an I/O expander would probably be ok. Maybe a dedicated 8-bit parallel bus between the prop and the CPLD, or tie every single available I/O pin on the prop to the CPLD. Who knows. CPLD could provide dual functions. I/O expander and address decoding. You wouldnt need anything as crazy as a FPGA. a Simple CPLD would probably do.
Anyway, Micha's code which my hardware was based on, the 2 AVRs are interconnected via 8-bit parallel bus with some flow control lines, INT/BSY.
James: I tried that, time and time again. I think its the layout as I didnt route the VCC/GND lines sufficiently enough, decoupling caps too far apart. and the CPUs have thier own crystals, 16mhz. Timing should be irrelevent because of the async 8-bit handshake bus. But thats where things fail. The CF card socket didnt pick up the card correctly either, but I havent even gotten to that point yet as I wanted to iron out the bugs.
Also another point to be said, Michas code/design works, is proven. So it has to be me. However in his setup he was using the AHA2940 with linux. I tried AHA2940 and it choked up. So i know its me. If i force parity check off, (fails parity). it will pick up and show the device ID and medium info! but just after the bus release, one of the AVR dies out, wont respond anymore. has to be hard cycled.
But the gadget makes a pretty SCSI activity light though. On a powerbook back when I was debugging it, I set it to the same SCSI ID as the HDD internal. Once the Target sees an ID conflict, it kills itself to avoid it. But the busy LED driven by the SCSI side AVR, still blinks when the HDD is working. lol. so technically the PIA AVR could be a fancy smancy LED activity indicator. lol.
But the problem is, AVR is pretty capped at 20mhz. Some might go higher, but the I/O is limited. That begs the question, Why not use another CPU? why the AVR? Well at the time I was getting into microcontrollers, I had AVRs at hand, and a shitload of them at my fingertips. So I got into programming on the AVR. ASM at first, then BASIC but not C. I should have taken C classes in school but didnt, took basic instead. whoops. Well BASIC will compile on AVR so that works for me. So from that point, I sorta stuck with AVR and became a big AVR fanboy.
Now of course, theres the PIC line too. Which have much higher clock speeds, But they dont have the 1 cycle execution time the AVR has. Maybe newer chips do, I dont know, but PIC is still a choice as they make BASIC compilers for PIC as well.
But with that aside, for these applications, I/O is a big thing.
Propeller would be nice, you can taskroute individual interrupts/subroutines to each core. But the I/O is limited.
HOWEVER.... Something along the lines of a 5V CPLD as an I/O expander would probably be ok. Maybe a dedicated 8-bit parallel bus between the prop and the CPLD, or tie every single available I/O pin on the prop to the CPLD. Who knows. CPLD could provide dual functions. I/O expander and address decoding. You wouldnt need anything as crazy as a FPGA. a Simple CPLD would probably do.
Anyway, Micha's code which my hardware was based on, the 2 AVRs are interconnected via 8-bit parallel bus with some flow control lines, INT/BSY.
James: I tried that, time and time again. I think its the layout as I didnt route the VCC/GND lines sufficiently enough, decoupling caps too far apart. and the CPUs have thier own crystals, 16mhz. Timing should be irrelevent because of the async 8-bit handshake bus. But thats where things fail. The CF card socket didnt pick up the card correctly either, but I havent even gotten to that point yet as I wanted to iron out the bugs.
Also another point to be said, Michas code/design works, is proven. So it has to be me. However in his setup he was using the AHA2940 with linux. I tried AHA2940 and it choked up. So i know its me. If i force parity check off, (fails parity). it will pick up and show the device ID and medium info! but just after the bus release, one of the AVR dies out, wont respond anymore. has to be hard cycled.
But the gadget makes a pretty SCSI activity light though. On a powerbook back when I was debugging it, I set it to the same SCSI ID as the HDD internal. Once the Target sees an ID conflict, it kills itself to avoid it. But the busy LED driven by the SCSI side AVR, still blinks when the HDD is working. lol. so technically the PIA AVR could be a fancy smancy LED activity indicator. lol.