Shop OBEX P1 Docs P2 Docs Learn Events
Simplest way to transfer dat files to eeprom? — Parallax Forums

Simplest way to transfer dat files to eeprom?

T ChapT Chap Posts: 4,223
edited 2012-09-22 14:44 in Propeller 1 
DAT
graphic39_data long
        'file "enteradmin.dat"

PUB EEPROMCONFIG
  'WriteBlock(epenteradmin,@graphic39_data& $FFC0, 640)        '39
  '23 more of these writes
At the moment there are 24 dat files that are transfered one at a time using the method shown above. Probably two could be copied, but that still doesn't solve the problem of requiring multiple steps(running multiple spin programs). This is for a project that I need to copy numerous boards with bitmaps that are converted to dat files. The dat files are stored on extra eeprom above 32k, and are called up as needed for LCD use.

Since there are now 24 files at 640 bytes, the Prop can't store all at the same time, and more will be added to the project on an ongoing basis. What is the best way to load up the eeprom with the least effort per load?

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2012-09-22 13:16
    Best way is to attach an SD card to the Propeller, store the files on the SD card, and copy them one at a time to the EEPROM. If you have 4 I/O pins to spare, you can temporarily attach the SD card to them for the process.

    Since these files are 640 bytes each, you could also have 40 or more of them per Spin program (40 x 640 = 25600 bytes) and still have room for the EEPROM write routines (like from "Basic I2C Driver") and your main method that would write these files one at a time to the EEPROM. You'd download this program to RAM and it would automatically run, then you'd do the same with a 2nd similar program to write the next 40 files, etc.
  • T ChapT Chap Posts: 4,223
    edited 2012-09-22 13:30
    Oh, that gives me a better idea Mike. I can have a GUI on the PC made up that will transfer the files one at a time to a SPIN program that copies them over. I don't have 4 pins without redesigning the board or hacking some for dual purpose. But the SD card idea applies to several similar methods of trans fer so that solves it. Thanks.
  • T ChapT Chap Posts: 4,223
    edited 2012-09-22 13:47
    Mike, if the files are referenced under DAT, I thought that there was a limit of 2k per cog? How are you suggesting parking the dat files so that they could all be in there at once? I don't mind so much running two programs to copy everything to eeprom. 24 files at 640 is 15360 bytes.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-09-22 14:15
    You can put them all in your DAT section at once. Just put an org 0 in front of each one (or every three). That will keep the compiler from complaining, and it will not change their hub addresses.

    -Phil
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-09-22 14:15
    Todd,

    File data stored in a DAT section is no different than data stored using a long, word or byte command. You are only limited by the size of hub RAM, and not by the size of cog RAM. You may be thinking of the size of a cog program, which is also defined in a DAT section, and is intended to fit in the cog's 2KB RAM.

    You could write a single program that transfers all 24 files to EEPROM at one. There is no need for an SD card in this case. You don't even have to disrupt the lower 32K of EEPROM if you load the program in RAM and run it.

    Dave
  • Mike GreenMike Green Posts: 23,101
    edited 2012-09-22 14:19
    If you're writing an assembly program for a cog, the 2K limit applies because that's all that can be copied into the cog's memory. The DAT section can be any length up to the 32K size of hub memory. You can also have multiple DAT sections as long as they all fit in the available 32K. They're all grouped together by the Spin compiler and loaded into a block of hub memory along with other blocks like the compiled Spin code for the methods.
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-09-22 14:20
    Phil Pilgrim (PhiPi) wrote: »
    Just put an org 0 in front of each one (or every three). That will keep the compiler from complaining, and it will not change their hub addresses.
    I don't thing the org 0 is needed unless you use a fit instruction.
  • T ChapT Chap Posts: 4,223
    edited 2012-09-22 14:26
    I see what you guys are saying. I think the problem before was that I couldn't compile because there was program code AND data files. I will go back and write a minimal program just for transfers and see if that solves it. It was just a coincidence that when the DAT reached near 2k the program was crashing.

    Thanks.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-09-22 14:44
    Dave Hein wrote:
    I don't thing the org 0 is needed unless you use a fit instruction.

    'Just checked that. You're right.

    -Phil
Sign In or Register to comment.