Shop OBEX P1 Docs P2 Docs Learn Events
Data Storage on SX - strange characters in data — Parallax Forums

Data Storage on SX - strange characters in data

MrdavidjenkinsMrdavidjenkins Posts: 49
edited 2005-08-19 14:38 in BASIC Stamp
Good Morning,· I am having trouble with a little storage algorithim I have written for the SX.· I have a 32 byte long data stored in the SX first 32 bytes.· This data is a mix of words and bytes.·· What I want to do is take the data from locations 100 to 868, move it to 132 to 868 and·discard the last 32 bytes.··I will write this data into storage into the "6th" 2K program storage of the sx.·
Problem is - I get data moved up and then the new 32 bytes put in, but the data looks really goofy - I get special characters in some cases.· Some of the data is recognizable, some not.·
I'd guess that the problem is hex related, but I am not sure.· It might be using a combination of words and bytes, but I would think that copying bytes·from·one location to another would not be a·problem.· Attached is·an example file.·
Why am I getting incorrect looking data in this program? Thanks

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-08-19 02:31
    David,
    ·· From looking at your code I gather 2 things.· First it seems like you're running this program from one in another slot.· I'm not clear on whether the operation of the other program has any affect on this one, but let's assume it doesn't.· Second, you're possibly making things more complicated than they need to be.
    ·· You said you need to copy data from locations 100 to 868 up to 132 to 868, discarding the last 32 bytes.· One counter (FOR...NEXT loop) could easily do this.· The question is, what are the source and destination banks?· I got the impression you were moving the data from one bank to another, but your code doesn't support that, only within the current bank.
    ·· If you could elaborate on exactly where the data needs to go I'm sure I could write something up to demonstrate how this could be done.· In fact, I will attempt to show you one possible way below...Give me a few minutes to add the code.
    ' {$STAMP BS2sx}
    ' {$PBASIC 2.5}
    ' Move data in EEPROM locations 100-868 to 132-868
    ' Disregard last 32 bytes
     
    eePntr    VAR         word
    char      VAR         byte
     
    Move_Data:
      FOR eePntr = 132 TO 868
        READ eePntr - 32, char
        WRITE eePntr, char
      NEXT
    


    If the data needs to be moved from one bank to another, that just requires adding the STORE command before the READ and again before the WRITE to specify source and destination banks.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com


    Post Edited (Chris Savage (Parallax)) : 8/19/2005 2:34:02 AM GMT
  • MrdavidjenkinsMrdavidjenkins Posts: 49
    edited 2005-08-19 04:14
    Wow, this is a very nice piece of code that I can use. Truly, Thanks a lot. I will try it tomorrow AM. I appreciate your help a lot. I am using a SX chip, and I will look up the store command cause I am not familar with it.
    BTW, you are correct, I am using two slots. I am using the first 32 bytes of scram to update the existing data to keep a set of the last 24 hours of a operation. The first bank loads the data into scram, then calls the second slot and the second slot takes the data from scram, appends it to the running stack of 24 records, and delete the oldest data.
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-08-19 04:41
    David,

    ·· You are referring to the SPRAM (ScratchPad RAM), but I didn't account for that in that piece of code.· The code I listed was solely for moving the data up 32 bytes, truncating the last 32 bytes of the source, in effect.· If you then need to copy the SPRAM to that 32 bytes at the beginning we skipped over, then you could use code like below.
    ' {$STAMP BS2sx}
    ' {$PBASIC 2.5}
    ' Move data in EEPROM locations 100-868 to 132-868
    ' Discard last 32 bytes
    ' Then move 
    eePntr    VAR         Word
    char      VAR         Byte
    Move_Data:
      FOR eePntr = 133 TO 868
        READ eePntr - 33, char
        WRITE eePntr, char
      NEXT
    Update_Data:
      FOR eePntr = 100 TO 132
        GET eePntr - 99, char
        WRITE eePntr, char
      NEXT
    

    ·· This code makes two assumptions...First, that you intended to move 32 bytes from 100-868 to 133-868, since that's the only way you'll have 32 bytes of space that won't over-write the data you just moved.· Second, by looking at your original code, it appears you are using ScratchPad RAM starting at location 1 instead of location 0.· Perhaps if I knew exactly how much data was in the original block, and how it was organized, I could see a better way.· 768 divides down into 24 blocks of 32 bytes, but the way you were moving data it would be partially over-written, from what I can tell.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • JLBSheckyJLBShecky Posts: 6
    edited 2005-08-19 05:01
    David-
    I was thinking of but Chris posted before I got to writing anything. Anyways I just looked back over Chris's code and noticed that there was a slight logic error in it. The code that was posted will repeatedly store the first 32 bytes thought the entire space that it writes two, because it writing to memory addresses and then reading them after they have stored the new data, thus causing a continual loop. To get the code working properly just switch the '132' and '868' around, the new code should look like this.
    ' {$STAMP BS2sx}
    ' {$PBASIC 2.5}
    ' Move data in EEPROM locations 100-868 to 132-868
    ' Disregard last 32 bytes
     
    eePntr    VAR         word
    char      VAR         byte
     
    Move_Data:
      FOR eePntr = 868 TO 132
        READ eePntr - 32, char
        WRITE eePntr, char
      NEXT
    
    



    (Also one other thing that I noticed, both in both sets of code is that they seem to be moving an extra byte. If I read your description correctly, you are storing records of data that are 32 bytes long, so if the first record starts at location 132, then the last byte of record 23 should be 867, not 868. Not that this really affected the data, just thought I would point it out.)

    JLBShecky
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-08-19 14:38
    JLBShecky,

    ·· You are correct.· I guess last night I was still stuck on the concept of moving the data from one bank to another, and eventually I took out the STORE commands and didn't think about the consequences of that!· =)· Thanks for catching that.· I noticed I was also off by 1 in my calculation for the number of bytes to move.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
Sign In or Register to comment.