Programming ext eeprom w/hex file- please help

[Sophi]

wav2dvr

A continuation of this thread


In my eeprom programmer buffer I am seeing three columns.

I havent used the PonyProg but most programmers are the same. When you see the buffer the 3 columns are as this

Address -- Hex Data --- ASCII data
000000 00 00 04 06.. ...AJ87ds

The HEX data and ASCII data are actually the same data represented in 2 different formats.

You should be able to edit any of the data in columns 2 or 3. When you load the file, it should show in these 2 columns. Try loading any text file into the buffer and it should show in column 3 as readable text.

When I load the file, it loads into column 3 no matter if the file is ASCII or HEX. The output from the eeprom itself is column 2 (hex). Since the programmer reads the hex file I give it as ASCII, then converts it to Hex, the file it is using is the wrong one. I've tried adding by hand what I think might be the way to get the software to understand that this is a hex file (ie: putting :1001000...1002000....etc.) in front of each line of data. But this does not work. PonyProg does not recognize my file as hex data.

The whole picture is: analog sound file converted to hex via "wav2dvr" software (available here: **broken link removed**), then put the hex file into the eeprom via PonyProg, then read the file via PIC to D/A to amplification to speaker. All the hardware has been tested and does work. But sound is pure noise. And I think all of these file conversions are seriously corrupting my sound file.

Does anyone have a better software converting method and programming than what I've got? Or suggestions, advice....
Sophi

Added after 5 hours 37 minutes:

So PonyProg will only take an Intel Hex file- (this after re-reading the help files). And adding 1000100 etc. to the beginning of each line is not enough.
Is there a software available that can convert from data to Intel Hex?
Thanks-
Sophi

 

[silvio]

.wav to binary for eeprom

I've tried adding by hand what I think might be the way to get the software to understand that this is a hex file (ie: putting :1001000...1002000....etc.) in front of each line of data. But this does not work.

And adding 1000100 etc. to the beginning of each line is not enough.

Dear Sophi,

If you want to know what is hidden behind those numbers inside of a hex file, it would be wise to read an Intel hex format description:

**broken link removed**

where you can find that it's not enough to change :1001000....1002000....etc if you don't know exactly what are you doing and the character meaning.

IN order to convert an wav file (binary file) to a hex file to be burned into circuit then a suitable program like bin2hex mentioned here:

 

[Sophi]

sound file hex

Thanks Silvio!
Yes, I had read what's in an Intel Hex, that's why just the numbers in front didn't work.
Are you saying that a sound file wav format is binary? That would make things much much easier! Please let me know if this is what you are saying and thanks for the software link.
Sophi

 

[silvio]

ponyprog2000 for comcast

Are you saying that a sound file wav format is binary?

When a programmer looks at a "bin" file it's expecting to take that long stream of bytes and placed them contiguos in the target according to:
1. The start address of PC buffer and the length of it
2. The start address of target chip

When the programmer looks at a "hex" file it's expecting to write in "chuncks" to target.
If the format of the "hex" file is correct then start parsing every line that starts with the colon and ends with the carry and new line markers.
As you already noticed, the programmer looks at starting address of the contiguos stream of bytes and the lenght of it.
The programmer could write randomly starting at different target chip adddress and different lengths.
That's one of the advantages of a hex file.

Now, from the chip point of view, it's strong related with the application that uses the stored bytes.
But it's always a stream of bytes.

When I said that the wav file it's a binary file, I thought from a programmer point of view.
No matter if you're able to clearly read some bytes with a text editor, the programmer takes the input wav file as binary and programm as mentioned above.

It's up to the application reading the target chip to decipher what's hidden behind those bytes.
Thus it's time for your PIC to deliver to DAC according to some "rules".
If the sound it's pure noise it's not the hex programmer guilty but your application.
The programmer has done his job and placed that stream of bytes in the EEPROM memory chip.
If you look carefully to the mentioned link **broken link removed** you can see that the EEPROM contents is read by the Link-Comm DVR-1 that can play directly.
It's up to the Link-Comm DVR-1 to extract the "channel samples" and play them accordingly.

Look at the following description of the wav file :
Next using the COOLEDIT program, convert your wav file to 8khz samplingg rate, 8 bit mono for the DVR-1 to play the file properly.
Use the hex2bin utility to convert from hex to bin and look at the contents of the bin file with winhex program.
Try to look if the file follows the wave file specification with all that chuncks present (RIFF, WAVE....)

I don't know if your PIC and DAC, when playing file from EEPROM behaves exactly as the Link-Comm DVR-1 (to be honest I don't know what device is)

 

[Sophi]

how to understand eprom chip hex

Silvio-
Thanks for the reply- that really helps alot for me to understand this.
With WinHex I was able to get the correct sound file out. It is corrupted with lots of noise but maybe I can fix this in the hardware...or make a better recording.
BTW, I have no idea what the DVR device is either!
Sophi

 

[phucthinhel]

from eeprom hex to ascii

Understanding Intel HEX file

 

[eng_ahmed22]

ext eeprom

Salam
here you will find good informations about the *.hex file format.

also here: www.keil.com/support/docs/1584.htm
hope that help you.
bye

Ahmed