Propeller EEPROM file and Visual Basic 2008 help needed
bambino
Posts: 789
I would like to support remote upgrades to a device I designed before it goes to market.
It has been put off till the last minute, but ,boy what a short minute I got!
I would like to read in a EEPROM files, for the propeller, and transmit it serially to my device.
I've managed to read the data into a rich textbox control, but it is in string(integer) format. Given time I'm sure I can trial and error my way thru this, but the devices going out without this modifacation would need to be recalled in order to have it.
They are going out regardless, so has anyone done similar work with EEPROM files. The file access read, write funtions are all I need.
It has been put off till the last minute, but ,boy what a short minute I got!
I would like to read in a EEPROM files, for the propeller, and transmit it serially to my device.
I've managed to read the data into a rich textbox control, but it is in string(integer) format. Given time I'm sure I can trial and error my way thru this, but the devices going out without this modifacation would need to be recalled in order to have it.
They are going out regardless, so has anyone done similar work with EEPROM files. The file access read, write funtions are all I need.
Comments
Beginning with the read operation
Can you transmit the EEPROM data as a binary stream to the PC. (how is the ASCII data being transmitted to the RichTextBox you have now)
Is it a continuous stream or split into blocks
Is there a checksum for·each stream/blocks
What is the preferred baud rate
Do you have the control to precede the data with a header or an address
Feel free to PM me with the info and an email address if you think it would get the ball rolling quicker.
Jeff T.
I am just using 32 bytes at the moment. I want to send them to the propeller, place them in upper 32k of eeprom then read them back.
Problems: $00 in hex is just 0 to VB.
············· bytes being sent back are just nibs, not full bytes. So it appears I'm sending 32 and gettin 16 back.
I'm not worried about moving the upper 32 to lower 32 for rebooting. I think Mike has allready wrote an object that does that.
No header at the moment, because I'm not using the actual device. I'm using a stander usb protoboard to debug this serial , i2c issue.
Later a header command of some sort would be neccessary in order to put the device into an upgrade mode, but that would rest in the top object not this upgrade object.
I would like to have a home spun checker though. Maybe have a cog send back the recieved data will the primary cog is writting to the I2c bus.
The other issue is that the vb file is for a windows app. The real mekoy will be in a PDA. So all components must be compatable with win Mobile.
Never really used the I2C protocal that much either. I could be misunderstanding it as well.
The attachment is set for port 19 at 9600 and is set to read 32 bytes. It's very straight forward and you can tailor it to suit your needs. This is the read part only.
The destination file is hard coded as C:\testfold\reload.bin
When I tested this I·toggled the serial port DTR to reset a Stamp which then started the transfer , you may need to remove the toggle or use RTS instead to signal to the Prop that we are ready.
If this works for you let me know and we can do the loader and perhaps a binary file reader for display purposes.
Jeff T.
Anyway I've changed the dtr on the app you posted to execute at start up. And the read button to send a character to the prop to start the sequence of reading the lower 32K eeprom.
I'm not getting something. I've been playing with the thresshold values, and your idx value trying to get the full 32k into the reload.bin file.
Best so far was 8k.
binReaderApp does attempt to read the file but isn't quite right when I compare it's values with the original memory dump from the propeller.exe.
It's a good start though. If we can read out a program, sending one should be pretty simple!
@@@Maybe just trying to read one of the files made by the propeller tool properly is a faster alternative. Will look into that later this week.
Thanks,
No time today.
I had problems running BinFileReader , nothing major I don't think but I didn't have a great deal of time to go into it too deep.
I did look through the code though and I think you nailed it when you increased the read buffer size.
I took your lead increasing the buffer size , using your example spin file I began to get results·.
At first the read operation was painfully slow but improved by reading a 32 byte packet at a time with a 115200 baud·, also added a screen dump button and a write button (the write routine needs some testing and cleaning up)
I would like you to try and compare at some time if you get the chance. The port is set for 19· 115200·, the file destination path will need altering.
If you don't have opportunity to trial this out thats ok I'v been having fun at the challenge.
Jeff T.
FullDuplex Spin Byte = 0 thru F
PC = 0 thru FF