1

I'm working on an SoC with 128K RAM, and currently the UART printing is too much so we have to reduce the code size by drawing it from memory.

We've got an working 128Mb SPI serial FLASH on board, and i'd like to store strings on it. please notice there is no file system on flash or in our FW.

Instead writing everything by myself, i'd like to know is there any useful code or standard or other material we can make use of?

including: (anything below could be helpful)

  1. library generating
  2. resource fetching method implementation.
  3. SPI FLASH read/write.(in fact i have wrote it.)

I'm expecting something like this:

UART_PRINT(C315);

and there is an “C315”, item on FLASH, corresponding to "Hello world".

we read it out then print through UART while run time. and the final result is "Hello world" on the terminal.

of course, anything that will blow my mind is welcome.:)

artless noise
  • 21,212
  • 6
  • 68
  • 105
Ethansong
  • 53
  • 6
  • Not really related to the question, but I am thinking that DMA might blow your mind. Do you have any DMA on your chip? Would be nice if you could write an application layer so that you don't have to worry about whether the data is in on-chip flash or in the external one. Let alone all the data shovelling from the SPI to the UART buffers. – Lundin Apr 28 '15 at 06:50

2 Answers2

1

Create an array of pointers to strings, and use an index into the array similar to a resource. This array as well as the strings can be stored in the flash memory. It may be easier to use assembler for the array of pointers and strings, possibly as a separate build from your embedded code. You'll need to coordinate index names used in a .h include file with the array of pointers to strings, similar to a resource file used for windows apps. This could be done with a bunch of defines or an enum:

enum stringindexes{C000, C001, ...};

update - I'm wondering if it would be possible to use something like a windows resource editor to create pointers and strings. This make require some reverse engineering to create a utility to convert the produced resource file into a binary image with just an array of pointers and strings, but it would automatically generate the include file giving names to the pointers. If anything, the resource editor could be used as a guide for creating a custom program to generate an include file with defines or enums to index into an array of pointers to strings.

rcgldr
  • 27,407
  • 3
  • 36
  • 61
  • The storage is on serially accessed memory on the SPI bus, not the memory bus - you cannot have a pointer to non-address mapped memory. – Clifford Apr 28 '15 at 07:06
  • The pointers would be offsets into the Flash memory. I'm assuming you can random access the flash memory via the SPI bus. – rcgldr Apr 28 '15 at 08:30
  • 1
    In the context of the `C` tag the term "pointer" might be misleading, but yes random access/serial read-out is the access method. I cannot imagine that this simple and direct solution has not already occurred to the OP. The simple answer to his question is probably "no", and that he does have to write his own system. I do think however that he is overestimating the necessary effort perhaps. As you point out the major issue is perhaps getting the strings into the memory in the first instance. I am not sure that anything would be easier in assembler - that seems quite unnecessary. – Clifford Apr 28 '15 at 13:09
  • @Clifford - I only mentioned it may be easier to use assembler, possibly as a separate build, to create a binary image that only contains the pointers (offsets) and strings. My concern is if a C source file with only data (the pointers and strings) would end up with any extra data in the produced binary image. – rcgldr Apr 28 '15 at 18:25
  • I see; I had envisaged the application loading the strings and meta-data dynamically rather then embedding them in code; there is little advantage in that perhaps because you could not load the serial EEPROM with the microcontroller device programmer. – Clifford Apr 28 '15 at 22:18
  • Perhaps a separate initialized build with code used to transfer the pointers and data into the EEPROM, then once the EEPROM was programmed, the operational code would be loaded. – rcgldr Apr 29 '15 at 02:20
  • That makes sense, although I would suggest including the EEPROM loader in the final application and have it receive data over serial or USB allowing the strings to be updated post-deployment. – Clifford Apr 29 '15 at 18:25
  • @Clifford - Yes, having the EEPROM loader in the final app makes sense. How does this device boot up? Is there something like a ROM with just enough code to download a small update app that would in turn update the EEPROM and the operational app? – rcgldr Apr 29 '15 at 22:54
1

You may be able to leverage the linker.

Place the SPI FLASH strings in a custom section in a custom region. Program the SPI FLASH with the linker-generated contents of the custom region.

Use the string pointers as the argument to UART_PRINT(). The function should convert the pointer to an offset by subtracting the base address of the custom section from the string pointer. Then use the offset to retrieve the string from the SPI FLASH.

D Krueger
  • 2,446
  • 15
  • 12