custom app. upload direct to bankstick. random data issue??

[Durisian]

Hi guys.

I've been working on some floorboard software.

The way it works is ain/din get information about what to do from an event table.

in the event table are the midi events name, status, and a 'style' definition, eg, on/off or show a bar grapgh or calculate tap tempo, etc, etc

AIN/DIN also have tables that tell them which entry to refer too.

Plus a few other tables for various things.... I ran out of flash memory a loooong time ago, so now I'm trying to run the all the tables from a bankstick.

I just can't get it to work.  

I upload some information direct to bankstick with a dedicated asm file like so...

;; preload file for BankStick

list    p=18f452

org   0x400000

;       "Name        ", Status, Param1, Param2_def
;; 0- These are the CC's
  db    "Volume          ", 0xb0, 0x07, 0x04
  db    "Amp Gain        ", 0xb0, 0x0c, 0x03
  db    "Amp Treble      ", 0xb0, 0x0d, 0x03
  db    "Amp Mid         ", 0xb0, 0x0e, 0x03
  db    "Amp Bass        ", 0xb0, 0x0f, 0x03
  db    "Amp Vol         ", 0xb0, 0x10, 0x04
  db    "Presence        ", 0xb0, 0x11, 0x03
... etc

END

When I upload with MIOS studio, every section gets a recieved less bytes than expected error!! I recall the information like this: just say pin_mapped = pin for ease of understanding.

// snippet from AIN notify change

    for (t=0; t<16; t++) found_event.name[t] = MIOS_BANKSTICK_Read(0x0000 + (pin_mapped * 19) + t);
    found_event.status = MIOS_BANKSTICK_Read(0x0000 + (pin_mapped * 19) + 16);
    found_event.param1 = MIOS_BANKSTICK_Read(0x0000 + (pin_mapped * 19) + 17);
    found_event.param2_def = MIOS_BANKSTICK_Read(0x0000 + (pin_mapped * 19) + 18);

found_event is later used to send a midi event and print data on the LCD. This works for the first entry of the table, but there seems to be extra bytes between lines. I wrote a quick bankstick scanner to check the uploaded data....

// In AIN nofity change

{
      bankstick_offset_LSB = (MIOS_AIN_PinGet(0)) >> 2;         // 00 - ff
      bankstick_offset_MSB = (MIOS_AIN_Pin7bitGet(1)) << 4;   // 0000 - 7f00


    MIOS_LCD_CursorSet(0x00);
    MIOS_LCD_PrintHex2(MIOS_AIN_Pin7bitGet(1)); // MSB
    MIOS_LCD_PrintHex2(bankstick_offset_LSB);
    MIOS_LCD_CursorSet(0x40);
    MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(bankstick_offset_MSB + bankstick_offset_LSB)); // Show eeprom data
}

It shows at location 0x24 = 0xB0, 0x25 = 0xc0, 0x26 = 0x03 (which is line 2).

By my calculations that seqence should start at 0x23... which shows 0x20... There's lot's and lot's of 0x20 in the eeprom, is there any significance?

So as of the second entry in the event table, I get a garbled LCD, and random MIDI out behaviour

For now I just want to ask if there something in the code above that could be causing the issues... Or should the code work. (a 'looks fine to me' would be much appreciated if it should be working)

Thanks!!

[stryd_one]

Do you get the upload errors when uploading a pre-made app (like clockbox or something)?

[Durisian]

Hi Stryd.

applications upload fine, only get upload errrors when uploading data to a bankstick.

Cheers!

[stryd_one]

Plus a few other tables for various things.... I ran out of flash memory a loooong time ago

May be time to optimise. :)

When I upload with MIOS studio, every section gets a recieved less bytes than expected error!!

Not sure why this is....

This works for the first entry of the table, but there seems to be extra bytes between lines.

It shows at location 0x24 = 0xB0, 0x25 = 0xc0, 0x26 = 0x03 (which is line 2).

By my calculations that seqence should start at 0x23... which shows 0x20... There's lot's and lot's of 0x20 in the eeprom, is there any significance?

The 0x20's are space characters " " so there should be a lot of them (at the end of the strings)... but there may be some unwanted ones...

So everything is fine for the entire first line, then it packs an extra 0x20 between the lines? Sounds strange... does 0x13 = A ? (first char on the 2nd line) Is 0x0f = 0xb0?

I've included some excerpts from the gpasm manual (more technical details are in the MPASM manual) fo your info. You can see that a db entry can have a label, maybe it is using the spaces in front of the line (I don't think so)..  I dunno... I also noticed that you didn't set the default radix, but again, that should make no change because you are specifying the radix for every one of those entries (0xnn or "nnnnn").

Maybe 'de' would be more appropriate, or 'dw'... I am stumped though.....

Sorry mate. Don't be discouraged, this sort of thing is normal when you try something that has not been done before ;) TK will probably pop by shortly and say "do this" and fix it instantly ;) But You will learn something interesting from testing it for yourself of course.

DATA

DATA <expression> [, <expression]*

Generates the specified data.

See also: DA, DB, DE, DW

DA

<label> DA <expression> [, <expression]*

Stores Strings in program memory. The data is stored as one 14 bit word representing two 7 bit ASCII

characters.

See also: DT

DB

<label> DB <expression> [, <expression]*

Declare data of one byte. The values are packed two per word.

See also: DA, DATA, DE, DW

DE

<label> DE <expression> [, <expression]*

Define EEPROM data. Each character in a string is stored in a separate word.

See also: DA, DATA, DB, DW

DT

DT <expression> [, <expression]*

Generates the specified data as bytes in a sequence of RETLW instructions.

See also: DATA

DW

<label> DW <expression> [, <expression]*

Declare data of one word.

See also: DA, DATA, DB, DW

RADIX

RADIX <symbol>

Selects the default radix from ?oct? for octal, ?dec? for decimal or ?hex? for hexadecimal. gpasm uses

this radix to interpret numbers that don't have an explicit radix.

See also: LIST

[Durisian]

So everything is fine for the entire first line, then it packs an extra 0x20 between the lines? Sounds strange... does 0x13 = A ? (first char on the 2nd line) Is 0x0f = 0xb0?

I've included some excerpts from the gpasm manual (more technical details are in the MPASM manual) fo your info. You can see that a db entry can have a label, maybe it is using the spaces in front of the line (I don't think so).. I dunno... I also noticed that you didn't set the default radix, but again, that should make no change because you are specifying the radix for every one of those entries (0xnn or "nnnnn").

Maybe 'de' would be more appropriate, or 'dw'... I am stumped though.....

Thanks Stryd, I look more into this on the weekend.

0x10 = 0xb0.

Not nessacarily 0x20, there was just lots of them. Generally it seems random.

This requires more testing on my behalf.

It didn't like 'nnnn' had to convert all to hex (was using a mix).

The 0x20's are space characters

Sweet, use heaps of spaces...

May be time to optimise.

hehe thought about optimising, but I'm not sure I can optimse 30k of variables.

There are 3512 variables that the user can modify direct from the floorboard :o

The project is designed to be very flexable. I'm not sure it can be reduced and keep the same level of flexability.

Sorry mate. Don't be discouraged, this sort of thing is normal when you try something that has not been done before TK will probably pop by shortly and say "do this" and fix it instantly But You will learn something interesting from testing it for yourself of course.

Yes, the best way to learn is to do it yourself!!

Not discouraged, i've come a long long way from the first time I stumbled to this site 8-9 months ago. But for the first time I havn't been able to work out whats going on.

Last night I set up a little application that writes data to eeprom, reads it back on the lcd screen, and then later reads it back again.

First time the text shows up correctly,

In the second loop, the first 8-10 entries are garbled, after that they are fine.

possibly a wiring fault??? I can't see how though. I'll rewire it on the weekend.

I wrote ths really quick... sorry it might be a little hard to follow.

I only used the first 20 entries in this test

void upload(void)
{
MIOS_BANKSTICK_CtrlSet(0x00);
MIOS_LCD_CursorSet(0x40);

// upload event_map

  MIOS_LCD_Clear();
  MIOS_LCD_CursorSet(0x00);

  count = 0;
  for (i=0; i<20; i++) {
    MIOS_LCD_CursorSet(0x00);
    for (t=0; t<16; t++) {
      error = MIOS_BANKSTICK_Write(count + t, event_map[i].name[t]);

    }
    error = MIOS_BANKSTICK_Write(count + 16, event_map[i].status);
    error = MIOS_BANKSTICK_Write(count + 17, event_map[i].param1);
    error = MIOS_BANKSTICK_Write(count + 18, event_map[i].param2_def);

    for (t=0; t<16; t++) {
      MIOS_LCD_PrintChar(MIOS_BANKSTICK_Read(count + t));
    }
    MIOS_LCD_CursorSet(0x40);
    MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(count + 16));
    MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(count + 17));
    MIOS_LCD_PrintBCD2(MIOS_BANKSTICK_Read(count + 18));
    count = count + 19;
    MIOS_Delay(255);
  }

  count = 0;
  for (i=0; i<20; i++) {
    MIOS_LCD_CursorSet(0x00);
    for (t=0; t<16; t++) {
      MIOS_LCD_PrintChar(MIOS_BANKSTICK_Read(count + t));
    }
    MIOS_LCD_CursorSet(0x40);
    MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(count + 16));
    MIOS_LCD_PrintHex2(MIOS_BANKSTICK_Read(count + 17));
    MIOS_LCD_PrintBCD2(MIOS_BANKSTICK_Read(count + 18));
    count = count + 19;
    MIOS_Delay(255);
  }
}

const events_t event_map[256] =  // DO NOT CHANGE ARRAY LENGTH!!!
{
//{Name        , Status, Param1, Param2_def }

  {"Volume          ", 0xb0, 0x07, 4 },
  {"Amp Gain        ", 0xb0, 0x0c, 3 },
  {"Amp Treble      ", 0xb0, 0x0d, 3 },
  {"Amp Mid         ", 0xb0, 0x0e, 3 },
  {"Amp Bass        ", 0xb0, 0x0f, 3 },
  {"Amp Vol         ", 0xb0, 0x10, 4 },
  {"Presence        ", 0xb0, 0x11, 3 },
  {"Reverb Mix      ", 0xb0, 0x12, 3 },
  {"Amp Type        ", 0xb0, 0x13, 7 },
  {"Fx Type         ", 0xb0, 0x14, 13},
  {"Fx Send         ", 0xb0, 0x15, 1 },
  {"Reverb Send     ", 0xb0, 0x16, 1 },
  {"Cabinet Type    ", 0xb0, 0x17, 8 },
  {"Reverb Type     ", 0xb0, 0x18, 9 },
  {"Noise Gate Level", 0xb0, 0x19, 12},
  {"Drive           ", 0xb0, 0x1a, 1 },

// 16-
  {"Wah Pedal       ", 0xb0, 0x1b, 3 },
  {"pre Effect Type ", 0xb0, 0x2c, 11},
  {"pre Effect Par 1", 0xb0, 0x2d, 3 },
  {"pre Effect Par 2", 0xb0, 0x2e, 3 },
... etc...etc
}

This needs more testing... Sadly the real world is calling me away for a few days :(

[stryd_one]

First time the text shows up correctly,

In the second loop, the first 8-10 entries are garbled, after that they are fine.

possibly a wiring fault??? I can't see how though. I'll rewire it on the weekend.

Yeh sounds like it might be... I mean what you're putting in the code doesn't match what's on the bankstick, and what you read from the bankstick is changing all by itself... That ain't right.

[Durisian]

Alright I've tried the above code with 2 different banksticks.

And 2 complete different core boards.  As far I can tell initially - identical results.

The only thing that is the same, is the IC socket, cable and header that connects the core.

Which I have checked with a multimeter and appears to be fine.

Is there a test that I can do to check if a bankstick is wired correctly?

[Durisian]

Ahhhh,

I'm not sure whats going on with the c code.

But the asm eeprom file. Needs to be an even number at the start of a line.

eg.

db 0x01, 0x02, 0x03

db 0x04, 0x05, 0x06

When uploaded will look like

0x01, 0x02, 0x03, 0xANYTHING, 0x04, 0x05, 0x06. 0xANYTHING

I'm now starting to make progress with the asm method of bankstick uploading.

[stryd_one]

Ahh this is one of those moments where we both should smack ourselves in the head... from the very same documentation I referred to above, and read before I posted (no really I did!):

DB – Declare Data of One Byte

5.13.1Syntax

[<label>] db <expr>[,<expr>,...,<expr>]

5.13.2Description

Reserve program memory words with packed 8-bit values. Multiple

expressions continue to fill bytes consecutively until the end of expressions.

Should there be an odd number of expressions, the last byte will be zero

Shoot me now.

Edit: ARGH I actually posted the answer!!

[Durisian]

hehe!

Yes, My tech talk is a little weak, so I didn't understand what that meant, but it did give me the idea.

Thanks Stryd!!

[stryd_one]

LOL  ;D well I'm glad it gave you the idea, 'cause I completely spaced!

I think that my mistake here can be a lesson to all the newbies reading this forum - if you rush, and don't pay attention, and don't bother to take your time and reaaaad, then you will make mistakes, no matter how much experience you have....