mkl0815 wrote:
What are the reasons for the "sequence" in the java GUI? I see the point, if you want to verify the image that is burned, but why should I erase, clear and write in one sequence? Are there special requirements for other (E)EPROMS then 28Cxx?
Yes, most Flash memory devices require a specific erase procedure. The 28C256 does not require it, but it does have a hardware erase that is much faster than writing to each byte individually.
mkl0815 wrote:
You also changed the offset list. It's OK to extend the list, but why you use these "strange" steps? I think in some projects it is a good practice to devide a 32k or 8k chip logically into different parts. You may have the basic IO routines in the first 1k (0x0000 to 0x03ff) of the EEPROM, maybe from 0x0400 to 0x0fff you have you basic interpreter, or what ever. So I think at least 1k steps for the offset should be possible.
The usual reason that the offset it used, is that the chip is bigger than desired so some address lines are not needed. But the unneeded address lines might be high or low, so on a 32k chip maybe every 8k would make sense, and smaller chips could use smaller offsets. Dividing the chip up like you say is indeed very common! But I have not seen separate binaries being made with these unique offsets, it seems like it would be a pain to burn it. The usual way is to have the linker put everything into one binary file at the right locations.
Maybe you do something different than what I have seen, no problem there. I think it you want every 1k, something other than a drop down box is needed because there are just too many options. I guess it could be a text input box too but then it's hard to limit the acceptable range of values.
mkl0815 wrote:
On my Mac you GUI appears always over the top of all other windows, even if the program is not the active one. Also the size of the window is not right after the program started. Is this only MacOS related, or does anybody has the same behavior on Windows or Linux? I tried the binary version you uploaded to this forum.
It seems the "always on top" was checked sometime, but I have already pushed a fix for that. I changed the GUI style to "native" so it looks a lot better, but I guessed there could be problems. I tested on Win7 and Ubuntu but I don't have a Mac. If the window needs to be a bit wider than that is no problem, but not too much or else it won't fit on my netbook screen.
mkl0815 wrote:
You asked about the 57600 baud rate I set for communication. This had historical reasons, because the first plan was to create a board like Aslak3 posted here. A standalone Atmega328p running with the internal 8MHz clock. Therefor normally you would not use a rate higher then 19200, because of an increasing error rate. My first prototype used the Arduino nano with a 16MHz clock and higher rates were possible. I set it to 57.600 sometime and never changed it again. I've tested with my prototype today, but everything higher then 115.200 caused communication errors. This may caused by my USB hub, because I have also problems with my logic analyzer if it is connected via the hub rather then using the direct usb port on my MacBook. So using 115.200 as the "default" rate seems to be a good compromise.
Ok that sounds good to me. The Leonardo is nice because it doesn't even care what the bps is set to, it runs flat out all the time. Maybe in the future a "negotiate" can occur to set the speed to the highest one that works.
mkl0815 wrote:
My intention for this project is still to keep it real simple, so that everybody is able to build it and use it. UnaClockers PCB was a big step in that direction. There are always possibilities to make this better, but I'd like to keep it as simple as possible. Adding a feature to write EPROMs with a 12V booster circuit is really cool and we should try to have a second Arduino Shield that covers the additional parts. I think I will take the changes to the ardino sketch into the "main line" of the project and make some "quality tests" burning eeproms and reading them back using my prototype and the arduino shield. The java part will also be updated to respect the changes on the Arduino firmware. But I will leave the gui unchanged in this first step. Maybe we should use the github functionality to handle this project. Issue tracking is a good start to manage feature requests and discussing feature changes.
Mario.
Okay, whatever you'd like to do is fine. I am happy, I have a working programmer.
I wanted to give my changes back if anyone wants them, and I am happy to help if you would like anything else.
Thanks again,
Ryan