Any further developments on flash write / read?
Working with flashWriteWord, but seems a little strange, I'm trying to deal with u8[]'s but that function seems to want u32's that then get chopped to two u16's to be written sequentially. I think I can do some bitwise copying and end up okay but I was wondering if anyone else had seen a simpler implementation for copying straight to memory with an index of 1 byte.
Seems like there are two prerequisites to read/write memory
1) Set up RCC
2) Unlock Flash
The methods for this are integrated into the bootloader hardware.h but not in the normal libmaple.
Does it seem like a better solution to borrow these from the bootloader or to try and port STM's eeprom.h so that it fits in libmaple?
If anybody else is successfully reading/writing words to upper flash around say 0x08010000 I'd love to hear about it, otherwise I'll keep plugging away and report back if I have any success.
mbolivar
LeafLabs
structuresound -- yup, there's (currently) no libmaple support for writing flash, and there's no time-line in place for adding that support. as you discovered, we do it in the bootloader only. it's not on the critical path right now, although it's certainly reasonable for flash write support to get added to (at least) the libmaple C api.
gbulmer
Moderator
mbolivar - I assume there is nothing to stop us just using hardware.c directly. Correct?
Maybe, at some point in the future, factor out from hardware.c the flash functions, and put into their own file so that the Maple library API can use them too?
structuresound - I'd just use hardware.c directly.
All you need to do is pack 4 bytes into an unsigned int, or uint32 to avoid possible confusion.
Packing can be done at the bit level with shifts, and's and or's, or you could try it with a union. You likely know this, but for the benefit of readers who follow ...
Whenever I use a union, I always do a quick check to make sure it is going to work the way I want, e.g.
void loop() {
union { uint32 ui; uint8 ub[4]; } u;
if ( sizeof(u) == 4 ) { // Yipee, game on
SerialUSB.print("sizeof(u) is correctly reported as 4 bytes: ");
SerialUSB.println(sizeof(u));
} else {
SerialUSB.print("Unions will not work, sizeof(u) is not 4 bytes, it is reported as: ");
SerialUSB.println(sizeof(u));
}
}I do the check because the C standard says that the behaviour of unions is implementation defined, so it can vary from compiler to compiler. But, IMHO, if it does work, byte packing using a union is easier to understand than bit packing.
EDIT: WARNING - I have not tested this code.
okay, cool that seems easier, I was trying this method:
long l = 0;
l |= b[0] & 0xFF;
l <<= 8;
l |= b[1] & 0xFF;
l <<= 8;
l |= b[2] & 0xFF;
l <<= 8;
l |= b[3] & 0xFF;now the byte arrays I want to copy are larger than 4 bytes, maybe I can use a 32 bit array pointer to step through 4 bytes at a time?
I'll try a direct implementation of hardware.c and see what I can come up with.
gbulmer
Moderator
Spoiler alert
- This contains a suggestion for code
- ignore if you are having fun doing it your way
If you have a byte array, you can do a truly horrible tricks with a pointer, but I won't encourage you (hint, use a pointer to the enum :-)
Copy hardware.c and using my enum example above, do something like:
uint32 *flashPtr = (uint32 *)0x08010000L;
union { uint32 ui; uint8 ub[4]; } u;
uint8 buff[100];
int i;
u.ui = 0;
for (i=0; i<sizeof(buff); i++) {
u.ub[i%4] = buff[i];
if (i%4 == 3) { // time to write it
flashWriteWord(flashPtr, u.ui);
++flashPtr;
u.ui = 0;
}
}
// now tidy up any remainder of 1, 2, or 3 bytes
// using flashWriteWord(flashPtr, u.ui);(I didn't want to take away all the fun, so I left tidying up TODO :-)
It isn't as compact as using a pointer, but avoids any issues of reading from non-aligned uint32's (which AFAIK is fine on Cortex-M3, but isn't supported on all ARM architectures)
WARNING - I have not tested this code.
bless you gbulmer, the union works like a charm. Only problem was that flashWriteWord doesn't want a pointer (it converts the address to a pointer internally, not sure why it's written this way). Here's what I did, to write use
assuming myArray is the global variable I'm interested in storing
also I hardcoded 64 in there instead of sizeOf probably will return to "macro'd" now that everything is squared away.
void writeFlash(){
uint32 flashPtr = (uint32)0x08015000L;
flashErasePage(flashPtr);
union { uint32 ui; uint8 ub[4]; } u;
int i;
u.ui = 0;
for (i=0; i<64; i++) {
u.ub[i%4] = myArray[i];
if (i%4 == 3) { // time to write it
flashWriteWord(flashPtr, u.ui);
flashPtr += 0x04;
u.ui = 0;
}
}
}to read the data back out of memory
void readFlash(){
uint32 flashPtr = (uint32)0x08015000L;
union { uint32 ui; uint8 ub[4]; } u;
int i;
u.ui = 0;
for (i=0; i<64; i++) {
if (i%4 == 0) {
u.ui = *((uint32*)flashPtr);
flashPtr += 0x04;
}
myArray[i] = u.ub[i%4];
}
}Also, in order to get things ready I wrapped the relevant functions from bootloader hardware.c/h into libmaple flash.c/h which requires a few of the defines from hardware.h, changing to the libmaple typdefs (i.e. u32 to uint32), include libmaple.h, and include usb_hardware.h
This is my first time "porting" something albeit from one version of the same library to another, so I don't totally know what I'm doing but it seems to work great "in practice".
One weird thing is that I now get some compiler warnings for redefines between usb_hardware and rcc neither of which I modified and didn't repeat any of those defines in flash.h. They don't seem to halt the compile so I'm not sure what's up.
Probably wouldn't take much more effort to wrap a couple of overloaded easy read/write functions make sure the pageclear is never less than 0x08005000 and call it a user eeprom library.
mbolvar - I don't know much about contributing to repositories like github yet, so I've put the flash.c and flash.h files for you here http://www.structuresound.com/maple/
I would like to learn how to work with that kind of environment because I'm interested in contributing to the codebase, I'm just a little timid about it because I'm still very "novice" at coding in general.
These don't have function definitions or implementations for the read/write functions that we've been discussing.
You must log in to post.