Closed NigelTwo closed 3 years ago
It looks like I re-wrote the command parsing in TommyPROM after developing the HardwareVerify tool, so when I did some later documentation updates they reflected the TommyPROM CLI but not the Hardware tool UI. I'll port the CLI changes in and will update the documentation. The A0/D0 confusion is unfortunate - I was aware of it while writing the docs, but I'll look again to see if there are better ways to describe the commands.
@NigelTwo - one thing to be aware of is that the 595's have an output latch line that needs to be controlled. It looks like the data sheet says that just tying the two clock lines together won't work because the output will be one clock behind the data. The fix is to just pulse the latch clock at the end of setAddress. There is an unlock-ben-eater-hardware sketch that deals with this, so you might look there for an example. I'll be happy to help you through any debugging to get it working.
I should probably add some notes about this because so many people are building the Ben Eater hardware and using those shift registers. I briefly considered writing a version of TommyPROM for that hardware, but it has a few issues that make that difficult, including the use of D13 (which blinks the LED at boot) as the WE control and also controlling output enable via the shift registers. I wish he had just used a few of the A0-A5 lines for control!
@TomNisbet - I'll leave you to choose whether to port the changes into the Hardware Tool UI. The A0/D0 confusion is actually a triple context problem that does take a while to get one's head around:
I am thinking that a new issue might be best for a discussion around the alternative shift register circuits.
Thanks for your offer of help, but I am pretty certain my variant of the circuit is working now. It is slower, and you have stressed the importance of speed wrt the EEPROM unlocking operations. What a surprise to find timestamps already in the code just about where I was to add them!
I checked in a fix so that the CLI parser matches what I thought it was already doing. The documentation has been updated to clarify the distinction between the D5 command, the D5 data pin on the ROM, and the D5 output on the Arduino.
@NigelTwo - I also added code and documentation to support a 74LS595 variant of the hardware. The RCLK pins on the shift registers are controlled by the D13 output on the Arduino. The support needs to be enabled with an edit to the Configure.h file. Details are in the Hardware page of the documentation.
@TomNisbet - I have run up the latest version of HardwareVerify. The A and D commands work correctly. Good.
Also, I see the documentation has been updated. The sub-scripting helps clarify the meanings. Another "tick" from me.
The background to this is that I have built the TommyPROM hardware using 74HC595 shift registers. So with both hardware and software changes a bit of testing is needed! As a result I have discovered that the Troubleshooting documentation is misleading:
To illustrate the address line testing commands I added a print statement to the 'a' command processing code viz `case 'a':
Now the difference between A0 and A000, and A400 and A0400 can be seen. `#a0 ffff 1111111111111111
a0000
0000 0
a400
40ff 100000011111111
a0400
0400 10000000000
`
IMHO the software bug (buffer over-read) doesn't need to be fixed. It is hardware testing code after all. Just adjust the documentation. It will have the side effect of reducing the confusion between A0 the command and A0 the 0th address line, and D0 the command and D0 the 0th data line.
Thanks for taking the time to design and document this project. It's encouraging to see proof that it will work in the end ;-)