Jump to content

Bankstick Storage Concept


Recommended Posts

Hi,

as I am not really capable of understanding the ASM-code from the provided application examples that use bankstick patches, maybe someone might check if my concept of storing patches on a bankstick seems correct?

I noticed that my codesize increased rapidly (>50%) due to my implementation of read/save handlers to store patches on a bankstick. This is not critical but it makes me wonder if there's a more efficient method for this.

Here's what I'm doing:

Every patch consists of AIN_NUM * 16 bytes. I have a const unsigned int array bankstick_patch_address[MAX_PATCHES] that points to the address of the bankstick.

Then I have two accessor functions, that collect or set the current data

and two functions that read/store the whole patch:

(the code is cutted to the relevant)

#define MAX_PATCHES 16
const unsigned int bankstick_patch_address[MAX_PATCHES] = { 
	0x000, 0x040, 0x080, 0x0C0,		0x100, 0x140, 0x180, 0x1C0, 
	0x200, 0x240, 0x280, 0x2C0,		0x300, 0x340, 0x380, 0x3C0
};

void ZS_SENSORIZER_SensorSetting_Write(unsigned int address, unsigned char pin) {
	// called by ZS_SENSORIZER_SensorSettings_Write(address)
	MIOS_BANKSTICK_Write(address, ZSSENSORIZER_VERSION);
	MIOS_BANKSTICK_Write(address + 1, (sensor[pin].enabled) | 
					  (sensor[pin].pedal		<< 1) |
					  (sensor[pin].pedalPanic	<< 2) |
					  (sensor[pin].invert		<< 3) |
					  (sensor[pin].gate		<< 4) |
					  (sensor[pin].read		<< 5) |
					  (sensor[pin].expand		<< 6) |
					  (sensor[pin].scale		<< 7));
	MIOS_BANKSTICK_Write(address + 2, CH[pin]);
	MIOS_BANKSTICK_Write(address + 3, CC[pin]);
}

void ZS_SENSORIZER_SensorSetting_Read(unsigned int address, unsigned char pin) {
	// called by ZS_SENSORIZER_SensorSettings_Read(address)
	// read and set sensor config from Bankstick
	if(MIOS_BANKSTICK_Read(address) != ZSSENSORIZER_VERSION) { 
		return;
      }

	// read and set sensor pin from buffer
	// set sensor settings from buffer
	sensor[pin].enabled		= 0x0 | (MIOS_BANKSTICK_Read(address + 1));
	sensor[pin].pedal		= 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 1);
	sensor[pin].pedalPanic		= 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 2);
	sensor[pin].invert		= 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 3);
	sensor[pin].gate		= 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 4);
	sensor[pin].read		= 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 5);
	sensor[pin].expand		= 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 6);
	sensor[pin].scale		= 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 7);
	CH[pin] = (MIOS_BANKSTICK_Read(address + 2));
	CC[pin] = (MIOS_BANKSTICK_Read(address + 3));
}



void ZS_SENSORIZER_SensorSettings_Write(unsigned int address) {
	// write all sensor configs to Bankstick
	// 1 sensor setup needs 16 bytes (c << 4 => c * 16)
	unsigned char c;
	for(c=0; c<SENSOR_NUM; c++) {
		ZS_SENSORIZER_SensorSetting_Write((address + (c << 4)), c);
	}
}

void ZS_SENSORIZER_SensorSettings_Read(unsigned int address) {
	// read and install all sensor configs from Bankstick
	// 1 sensor setup needs 16 bytes (c << 4 => c * 16)
	unsigned char c;
	for(c=0; c<SENSOR_NUM; c++) {
		ZS_SENSORIZER_SensorSetting_Read((address + (c << 4)), c);
	}
}
for example, the patch is then loaded by calling this:
	// load patch #5
	ZS_SENSORIZER_SensorSettings_Read(bankstick_patch_address[5]);

Now I wonder:

- should I store the address lookup table on the bankstick to save memory?

- should I rather find a bitshifting formula that increments the address like this: PATCH * 0x40 ?

  (I already hammered my brain out, I just can't figure it out  :-[ )

- is this concept okay or is there a better method for this?

Cheers,

Michael

Link to comment
Share on other sites

Hi Michael,

yes, there is a better method: don't use a lookup table, but just calculate the address directly, it's: (unsigned int)patch << 6

In addition, you could organize the data structure in RAM in the same way like it should be stored in BankStick. By doing so, you can use the MIOS_BANKSTICK_WritePage function in order to store the whole patch at once (a page consists of 64/0x40 bytes). The advantage of a page write operation is, that it takes appr. the same time like writing a single byte (see 24LC256 datasheet for the timings, so far I remember it was appr. 4 mS) - so, at the end a page write works 64 times faster!

Best Regards, Thorsten.

Link to comment
Share on other sites

Hi,

that makes it a lot clearer :) thank you!

In addition, you could organize the data structure in RAM in the same way like it should be stored in BankStick.

Because I cannot group my int arrays to bitfields (SDCC just allows 8 bit / field), this sounds like it's best to create structures of 64 bytes, so that I can simply send the whole structure to write a page, right?

Thanks again for clearifying this,

Michael

-----

@Stryd_one: yeah, I updated the code each time I did improve something, so although I tried to comment out everything related to my app, some lines might have slipped through ;)

But this should be just the "runloop", that can be heavily customized to your needs, it's not really encapsuled... drop me a line if you have problems or questions!

Link to comment
Share on other sites

  • 2 weeks later...

the 2nd parameter is the buffer. You "give" the buffer to the function and it will be returned, filled with data. See writePage on how to create the buffer.

There's an example in the C-Function-Overview: http://www.ucapps.de/cmios_fun.html#MIOS_BANKSTICK_ReadPage

But I agree, an additional example how to get and fill that buffer would be helpful. Anyone already did that and want to share his/her experiences?

I have not worked on my sensorizer project any further, because I obviously have to reprogram wide parts of my application, but as soon as I resume, I'll keep you updated...

Edit: forgot that there are no ladies here.. ;D

Link to comment
Share on other sites

Ok, i'm on trys...

I wonder : do the bankstick have to be initialised on startup to be used ?

Do the variable  MIOS_BOX_STAT.BS_AVAILABLE autmaticaly set to 1 when bankstick is connected ??

Soon, i will reply to questions, instead of asking ;)

thanks

Link to comment
Share on other sites

Because I cannot group my int arrays to bitfields (SDCC just allows 8 bit / field), this sounds like it's best to create structures of 64 bytes, so that I can simply send the whole structure to write a page, right?

Is a good idea to have a union?

So that a 64-byte "value" can either be treated like a structure (for variable access) and on the other hand be read out as a 64-byte value.

I want to have a clean storage implementation, but I don't know if nested variable access is slower or this has some other impacts I haven't thought about...

Thanks for your comments!

Michael

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...