I have some experience with the LPC1768, where files can be created and read that reside on the module itself. I have not been able to find something like that, looking at the reference and searching through the forum, for the Nano. Hopefully it is possible, there is storage on the chip, so why not use it
If it is not possible, what are the alternatives? Of course a serial connection can be made to a PC and software can be created, but that would require a PC (and a lot of hassle). An I2C EEPROM or even an SD card are possible, although I would not know how to add these, but that makes life always more complicated compared to storing data on the Nano itself...
In my case it would be for a very small account of data, 1024 bytes, the contents of a 2708 Eprom, that needs to be read and written. That's such a small amount of data that it would even fit in an array, but then you want to store it or first you need to read it anyway
The ATmega328 happens to have exactly 1Kbyte of internal EEPROM memory that you could use, but it doesn't have any "file" abstractions around it. Check out the EEPROM functions/library.
Thanks both for your (more or less similar) replies. Indeed, with 1K it would be exactly enough
When there are no files, I'd say I could also use an array of 1024 bytes, so the normal RAM.
But what would be the way to go to if I want to copy a HEX-file to some sort of filesystem / Flash-memory through a PC in order to burn that to the Eprom? Or when I would like to create a HEX-file when reading the Eprom?
It sounds I would need to add something like Flash memory that also creates a drive on the PC (for copying files), or I guess I would need to work with swapping SD cards (which is fine too) and that would require an SPI interface to an SD card "holder" (aren't SD cards SPI per definition?). That sounds quite complicated... I have no idea how to interface and what statements to use, as in the end the data would need to become a file on a filesystem.
westfw:
The ATmega328 happens to have exactly 1Kbyte of internal EEPROM memory that you could use, but it doesn't have any "file" abstractions around it. Check out the EEPROM functions/library.
Maybe you can give a description of what you want to achieve at the end.
Store data from a PC on the Arduino and read it back? And do what with it?
Representing an Arduino as a filesystem (e.g. like USB harddisk or memory stick) to a PC might indeed be tricky; no real idea what is involved though.
A small dedicated PC application that connects to the serial port, instructs the Arduino to store data (in eeprom) or give it back data (from eeprom) is not complicated. HEX files are nothing more than text representation of binary data (with a text representation of a checksum); if we're talking about the same). The Arduino can produce or reverse this on the fly; alternatively the PC application can convert binary data from HEX before sending it to the Arduino or convert binary data to HEX when receiving it from the Arduino.
An alternative can be the use of an ethernet shield and implementation of a simple webserver with upload / download functionality; you can use your browser to upload and download the file. As I haven't used network functionality on the Arduino, I think it's feasible.
Storing data in RAM has the disadvantage that a power loss will result in lost data; if that is non-issue there is no advantage in using the eeprom (although RAM is a scarce commodity in microcontrollers).
Using an SD card only gives you a local (to the Arduino) filesystem; you still have to implement something (one of the above options) to present it to the PC (or take the card out, place it in the PC and copy the file).
Thanks for the information. I'm thinking of using the SD card, I have one of those breakout boards, and connect it via SPI to the Nano. Not ideal compared to the LPC1768 ARM controller that has the functionality of a filesystem.
I could even copy the HEX file from the SD card to RAM first. The whole idea is that I create a 2708 (1K) Eprom reader en programmer. Therefore I need to be able to read a HEX file, indeed it could be done via a serial connection to a PC as well, in order to program the Eprom. And of course I should be able to read and dump the contents of an Eprom. That's the background...
I have some experience with the LPC1768, where files can be created and read that reside on the module itself.
I knew that the NXP chips emulated a USB flash drive for the purpose of loading code, but I didn't think it actually wrote "files" that were accessible to the LPC programs as well. Are you sure it does that? How does it distinguish between "this file is the program to run at startup" and "this is a data file"?
All old programmers worked via RS232 (or dedicated hardware).
Sounds like a reasonable straight forward project. You can use the SD card to store multiple files. The SD library seems to have functions to get e.g. a directory listing. Only limitation that I see is number of pins available, but one can work around that using some additional hardware (or a Mega).
Implement a small command set like
LS -> (list) returns all files stored on SD
SAV filename (save) -> read content from eeprom and store on SD under given filename
PRG filename (program) -> read file with given filename from SD and program eprom
VER filename (verify) -> verify that eprom content matches content of given file (e.g. programming success)
RD filename -> (read from Arduino) send file with given filename from SD to PC
WR filename -> (read from PC) send file from PC to Arduino and save on SD under given name
For the first four I do not see a direct need for HEX except for detecting data corruption on the SD card.
westfw:
I knew that the NXP chips emulated a USB flash drive for the purpose of loading code, but I didn't think it actually wrote "files" that were accessible to the LPC programs as well. Are you sure it does that? How does it distinguish between "this file is the program to run at startup" and "this is a data file"?
Well, it might have to do with the uC LPC1768 itself and the board it is used on? Maybe the uC itself does not have this capability... I have the board and creating, reading writing files is native functionality. Here is some of my old test code I looked up in the online compiler:
Serial pc(USBTX, USBRX); // tx, rx
LocalFileSystem local("local"); // Create the local filesystem under the name "local"
int karakter;
int main() {
FILE *fp = fopen("/local/george.txt", "r"); // Open "george.txt" on the local file system for reading
if (!fp) {
pc.printf("File not found\r\n");
}
else {
pc.printf("We're going to send a file to the COM-port screen:\r\n");
}
do {
karakter = fgetc(fp);
pc.putc(karakter);
} while(karakter != EOF);
fclose(fp);
pc.printf("Ready!\r\n");
}
Appologies to any moderator, as this is not Arduino code...
You're actually echo-ing a file on the file system to the COM-port screen.
Same for writing a file. You can check on mbed.org.
"pc" is what's the serial-interface and the println for the Arduino.
I guess it distinguishes in the following way:
A .bin file on the Flash drive is automatically loaded when the reset button on the board is pushed. I haven't found out what happens if more than one .bin resides on the Flash. That code is loaded in the uC. The Flash filesystem has been made available, and theoretically, you could overwrite the .bin just loaded. There might even be a way to externally trigger the board to load new code (never needed that), that would be funny, it would mean that you could alter your code file and load it on the fly. Not sure if that would work...
sterretje:
All old programmers worked via RS232 (or dedicated hardware).
Sounds like a reasonable straight forward project. You can use the SD card to store multiple files. The SD library seems to have functions to get e.g. a directory listing. Only limitation that I see is number of pins available, but one can work around that using some additional hardware (or a Mega).
Implement a small command set like
LS -> (list) returns all files stored on SD
SAV filename (save) -> read content from eeprom and store on SD under given filename
PRG filename (program) -> read file with given filename from SD and program eprom
VER filename (verify) -> verify that eprom content matches content of given file (e.g. programming success)
RD filename -> (read from Arduino) send file with given filename from SD to PC
WR filename -> (read from PC) send file from PC to Arduino and save on SD under given name
For the first four I do not see a direct need for HEX except for detecting data corruption on the SD card.
Indeed, pin count can become an obstacle...
Data: 8 pins
Clock: 1 pin (to a 4040 to generate the 10 bit address)
SPI for the SD card: 4 pins
Read/Write selection: 1 pin
Programming pulse through transistor that releases 27V programming voltage
But... I think I can save on the data pins and reduce these to one output pin by clocking in bits in a shift register...
Btw, I think the majority of programmers used the parallel (LPT) interface, instead of the RS232, isn't it?
I have seen an SD library, it is a bit more hassle than I expected, but looks doable. I shouldn't make things too fancy, programming a 2708 will rarely happen
