Awesome! I haven't been following the programmer board details very closely... what kind of microcontroller did you end up using? Does it have native USB, or are you using an FTDI chip, or how exactly is your USB connection made?
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Another IIci ROM hack
- Thread starter dougg3
- Start date
I'm using the AT90USB646. It's native USB, so I'm going to use a USB library such as LUFA to make it a USB CDC class device. Essentially a serial port that is driverless on OS X and Linux, and requires a simple .INF for Windows that only tells Windows to load its own built-in serial driver. I decided against the FTDI chip because it's pretty expensive compared to the microcontroller's price. Anyway, I haven't tested any USB stuff yet other than for supplying power, but I did notice when I plugged it into my computer unprogrammed, it appeared as a USB device with Atmel's vendor ID -- so the USB circuitry probably works. I *think* that was a USB bootloader built into (or pre-flashed onto) the chip.
Latest update is it also appears that the SPI I/O expander chip is working! Struggled with it until I realized the bits in the data direction registers on it (1 = input, 0 = output) are backwards from the AVR's (0 = input, 1 = output)...ooops! My electrical testing code works now, and it should also be useful for testing the programmer board itself for shorts...
Latest update is it also appears that the SPI I/O expander chip is working! Struggled with it until I realized the bits in the data direction registers on it (1 = input, 0 = output) are backwards from the AVR's (0 = input, 1 = output)...ooops! My electrical testing code works now, and it should also be useful for testing the programmer board itself for shorts...
There were three boxes of live chickens on the sorting counter at the post office. I kept hearing clucking, but I was like... naaaah. Couldn't be. Then the postman came in and grabbed the three boxes, and there was the unmistakable clucking of chickens. It got quiet, then everyone in the post office laughed.
Haha, that's awesome! I naturally had to Google it, and I see there are places where you can order chickens, ducks, turkeys, etc. and have them shipped to you...weird!
On a more serious note, the USB circuitry on the board is working fine too. I have it working as a USB serial port. Like I said, it requires a really simple driver on Windows, and works out of the box on OS X and Linux. I've tested it on all three
At this point it comes down to writing the software and hoping that the USB serial performance is fast enough...
OS X recognizes it as a modem...hopefully there's a way to turn that off. It's kind of weird.
On a more serious note, the USB circuitry on the board is working fine too. I have it working as a USB serial port. Like I said, it requires a really simple driver on Windows, and works out of the box on OS X and Linux. I've tested it on all three
At this point it comes down to writing the software and hoping that the USB serial performance is fast enough...OS X recognizes it as a modem...hopefully there's a way to turn that off. It's kind of weird.
well as long as that modem has a "physical" port address that is controllable in a development environment, it doesnt matter.
True, and it does have a TTY device in /dev (tty.usbmodem223 in this case -- not sure what the 223 stands for). Also, after I went into Network System Preferences and clicked "Apply", it looks like it quit whining to me about a new network device every time I plug it in. Excellent
olePigeon's SIMM sockets arrived! Woohoo! Here is a SIMM socket soldered to the completed board (other than the RS232 stuff) with a SIMM inserted:
It looks like my electrical testing routines work All of the SIMMs I have recently built are showing up perfect, and I have some older SIMMs I assembled while I was messing with solder paste that I know have shorts, and they fail the electrical test. The only thing waiting now is for me to write the firmware and software to communicate with it, and then this sucker will be ready to go...
olePigeon's SIMM sockets arrived! Woohoo! Here is a SIMM socket soldered to the completed board (other than the RS232 stuff) with a SIMM inserted:
It looks like my electrical testing routines work
All of the SIMMs I have recently built are showing up perfect, and I have some older SIMMs I assembled while I was messing with solder paste that I know have shorts, and they fail the electrical test. The only thing waiting now is for me to write the firmware and software to communicate with it, and then this sucker will be ready to go...And one more thing -- I have a simple demo program running on the board that sends data out the "virtual" USB serial port as fast as possible. I also have a demo program running on Windows reading the data as quickly as possible.
It takes about 32 seconds to transfer 2 megabytes of data. When I do the math, it's coming out to about 62 kilobytes per second, or almost exactly 500 kilobits per second. That seems to be the theoretical maximum data rate with the settings I have now...
Edit: I lied. It looks like it depends on the size of data chunks I transfer in the AVR. I have gotten it down to 2 MB in 6.1 seconds which is 344 KB/sec or 2.75 megabits per second. Now obviously there's no way I'm going to get that kind of data speed in my real world application, but it looks like sending a big chunk of data (hundreds of bytes) all at once works better than what I was doing (64 bytes).
It takes about 32 seconds to transfer 2 megabytes of data. When I do the math, it's coming out to about 62 kilobytes per second, or almost exactly 500 kilobits per second. That seems to be the theoretical maximum data rate with the settings I have now...
Edit: I lied. It looks like it depends on the size of data chunks I transfer in the AVR. I have gotten it down to 2 MB in 6.1 seconds which is 344 KB/sec or 2.75 megabits per second. Now obviously there's no way I'm going to get that kind of data speed in my real world application, but it looks like sending a big chunk of data (hundreds of bytes) all at once works better than what I was doing (64 bytes).
That's incredible progress! 8-o The rate of development you've been maintaining is awe inspiring.
That pic and report make the perfect rollover to this next developmental stage at p.27 of your quest, DQ!
I love the way the new Jolly Roger is winking at the Jolly Roger on the SIMM. :lol:
That pic and report make the perfect rollover to this next developmental stage at p.27 of your quest, DQ!
I love the way the new Jolly Roger is winking at the Jolly Roger on the SIMM. :lol:
Well, theoretically, does the speed matter? do the chips have a timeout period or something? heck if the write would take 20 minutes, it still wouldn't matter becuase its writing.
Yeah, the speed can be as slow as I want it to be--no timeout period I'm aware of--but I want it to be as fast as I can possibly make it, so that's why I'm talking about speeding up the data rate between the board and computer as much as possible. I'm pretty sure the data transfer rate will be a bottleneck, but I guess I don't know for sure yet.
I successfully read the first byte from each chip simultaneously today--the data/address/control lines work
I successfully read the first byte from each chip simultaneously today--the data/address/control lines work
well thats good news, no circuit errors!
Well, the reason i mention speed, you might want to make it as fast as it can be, but at the same time, you dont want to make it so fast that its unstable. ;-)
Well, the reason i mention speed, you might want to make it as fast as it can be, but at the same time, you dont want to make it so fast that its unstable. ;-)
Yep, that's very true. I'll also want some simple confirmation/error checking in the communication protocol to ensure everything makes it through the USB connection OK. As far as read cycles go, it's impossible to read from the chips too fast because setting up the SPI to read back the data after writing an address takes enough time that the output data from the chips will definitely be valid. Write cycles may be a bit more complex--we'll see. Looks like these chips let you poll to see when a write has completed.
I was able to successfully read the entire SIMM contents (2 MB) back to the computer in about 15 seconds. That's with no error checking or anything so the actual performance will decrease a bit once I'm done, but it's looking good I'm starting to learn about writing/erasing now. I have been able to read the chip manufacturer and product ID, which requires doing some write cycles to put the chips in a special read back mode, so that seems to work OK. Anyway, I'm still figuring things out with the software, but at this point it looks like everything is going to work fine...woohoo!
I was able to successfully read the entire SIMM contents (2 MB) back to the computer in about 15 seconds. That's with no error checking or anything so the actual performance will decrease a bit once I'm done, but it's looking good
I'm starting to learn about writing/erasing now. I have been able to read the chip manufacturer and product ID, which requires doing some write cycles to put the chips in a special read back mode, so that seems to work OK. Anyway, I'm still figuring things out with the software, but at this point it looks like everything is going to work fine...woohoo!
For talking between the computer and the programmer board, you could send a small checksum at the end of each data chunk and verify it in the microcontroller. I've seen a lot of success with this simple method:
XOR all bytes to get an 8-bit X-SUM
Add all bytes, plus the X-SUM to get an 8-bit C-SUM
There is still some possibility of an error and corresponding error(s) in the checksum, but it's very unlikely.
You could communicate back and forth for each success/failure, request re-sending of data, but that would slow things down and add complexity. Alternatively, you could just wait until the end of the flash and report errors, or automatically retry the entire flash.
XOR all bytes to get an 8-bit X-SUM
Add all bytes, plus the X-SUM to get an 8-bit C-SUM
There is still some possibility of an error and corresponding error(s) in the checksum, but it's very unlikely.
You could communicate back and forth for each success/failure, request re-sending of data, but that would slow things down and add complexity. Alternatively, you could just wait until the end of the flash and report errors, or automatically retry the entire flash.
I like that idea for verification -- I may just use it! I agree with what you said -- I have to be careful with error handling or the whole protocol will get bloated and waste transfer time. Thank you for the ideas!
On the writing data to chips front, I have good news and bad news.
The good news is that I am successfully writing to all four chips (SST39SF040) in parallel now -- I write the word 0x12345678 over and over again to fill all four chips, and I can read it back in my EEPROM burner to confirm that I wrote it correctly. The other great news is that the two large chips I've been using (SST39SF040 and the Am29F040B) both use the exact same JEDEC write command set, so they both work perfectly with the same code. At this point I'm 100% confident that every function of the SIMM burner is going to work.
The bad news is that the SPI GPIO expander significantly lowers performance. I'm not even testing any communication overhead at all yet, and it's taking about 1 minute and 45 seconds to do the complete write. If I only write to the two chips that aren't connected to the GPIO expander chip, it only takes about 47 seconds. So that extra ~1 minute of overhead is because of my serial communication to the GPIO expander chip, which I can't really do anything about. The problem is that I have to write out several data bytes as an unlock sequence before I write each byte to the chips. Plus, once I have written the byte to program, I have to read back data from the chips to determine when the byte has finished programming. Each read/write requires an SPI transaction of 4 bytes, which takes over 4 microseconds at an SPI clock rate of 8 MHz, whereas a lot of the timings for these read/write cycles of the unlock sequence and verification can be down in the tens of nanoseconds -- I just don't have the speed to talk to the chips that fast when I'm using SPI.
I probably should have used some kind of parallel device (a bidirectional latch or something like that? I don't know what the terminology would be) that connects to two 16-bit buses, and can save input from them and output to them as requested. That way I could have shared my 16 data lines with all 32 of the SIMM data lines, rather than using SPI for the other 16 data lines. I think that would have been faster (although I would have lost some of my electrical testing capabilities, I think, because it wouldn't have pull-ups built-in). Anyway, too late for that at this point.
It's still faster than my EEPROM burner which takes over 2 minutes to write a single chip, but once I factor in communication overhead, I'm fearing that it's going to be worse performance. On the other hand, since all four chips are being flashed simultaneously, it's still going to be way faster than the EEPROM burner when you factor in the total time it takes to burn enough chips for the entire SIMM (not to mention the annoyance of removing/inserting PLCC chips)
On the writing data to chips front, I have good news and bad news.
The good news is that I am successfully writing to all four chips (SST39SF040) in parallel now -- I write the word 0x12345678 over and over again to fill all four chips, and I can read it back in my EEPROM burner to confirm that I wrote it correctly. The other great news is that the two large chips I've been using (SST39SF040 and the Am29F040B) both use the exact same JEDEC write command set, so they both work perfectly with the same code. At this point I'm 100% confident that every function of the SIMM burner is going to work.
The bad news is that the SPI GPIO expander significantly lowers performance. I'm not even testing any communication overhead at all yet, and it's taking about 1 minute and 45 seconds to do the complete write. If I only write to the two chips that aren't connected to the GPIO expander chip, it only takes about 47 seconds. So that extra ~1 minute of overhead is because of my serial communication to the GPIO expander chip, which I can't really do anything about. The problem is that I have to write out several data bytes as an unlock sequence before I write each byte to the chips. Plus, once I have written the byte to program, I have to read back data from the chips to determine when the byte has finished programming. Each read/write requires an SPI transaction of 4 bytes, which takes over 4 microseconds at an SPI clock rate of 8 MHz, whereas a lot of the timings for these read/write cycles of the unlock sequence and verification can be down in the tens of nanoseconds -- I just don't have the speed to talk to the chips that fast when I'm using SPI.
I probably should have used some kind of parallel device (a bidirectional latch or something like that? I don't know what the terminology would be) that connects to two 16-bit buses, and can save input from them and output to them as requested. That way I could have shared my 16 data lines with all 32 of the SIMM data lines, rather than using SPI for the other 16 data lines. I think that would have been faster (although I would have lost some of my electrical testing capabilities, I think, because it wouldn't have pull-ups built-in). Anyway, too late for that at this point.
It's still faster than my EEPROM burner which takes over 2 minutes to write a single chip, but once I factor in communication overhead, I'm fearing that it's going to be worse performance. On the other hand, since all four chips are being flashed simultaneously, it's still going to be way faster than the EEPROM burner when you factor in the total time it takes to burn enough chips for the entire SIMM (not to mention the annoyance of removing/inserting PLCC chips)
Cool! Glad to hear it's all working!
Faster is always better, but I think this is fine. The main tedium the SIMM programmer avoids for me is extracting the chip from the SIMM, placing it in the EPROM programmer's socket, fiddling with the programming software, clicking go, waiting, extracting the chip from the programmer's socket, replacing it in the SIMM, repeat 4x.
The actual programming time wasn't terrible, I'd sit and review my changes while waiting for it to burn. The real win is avoiding the tedium of fiddling with 4 chips every time you make a change. Plus, we can avoid the while process of splitting the ROM image into 4 pieces for burning, and it avoids the extra opportunities for screwing up by programming the same image into 2 chips because you forgot to load the correct image before clicking "go" in the programming software, or replacing the chips in the wrong order, etc.
Faster is always better, but I think this is fine. The main tedium the SIMM programmer avoids for me is extracting the chip from the SIMM, placing it in the EPROM programmer's socket, fiddling with the programming software, clicking go, waiting, extracting the chip from the programmer's socket, replacing it in the SIMM, repeat 4x.
The actual programming time wasn't terrible, I'd sit and review my changes while waiting for it to burn. The real win is avoiding the tedium of fiddling with 4 chips every time you make a change. Plus, we can avoid the while process of splitting the ROM image into 4 pieces for burning, and it avoids the extra opportunities for screwing up by programming the same image into 2 chips because you forgot to load the correct image before clicking "go" in the programming software, or replacing the chips in the wrong order, etc.
