Hi all,

I have a bit of a Ninja code question.

I was thinking about the lack of RAM on the NXP, and the lovely huge Flash on the mbed board, and though that it should be quite easy to have sections of code, modules if you will, that can be loaded on demand during run time, and then flushed/replaced with another module once the task has been completed.

It seems that the mbed complier and support libraries would support this, the only thing required, as far as I can tell, is to be able to build code in the compiler that is position independent... Is this possible? any thoughts before I waste an evening hacking away at this idea? :)

Hi Matt,

The code already runs directly from the microcontroller's onboard (512KB) FLASH, and only R/W data goes in RAM. So unless you've got even more ninja ideas, I think your work is already done and no "loading" is needed? Then again, I may have missed your point :)

Simon

Simon Ford wrote:

Hi Matt,

The code already runs directly from the microcontroller's onboard (512KB) FLASH, and only R/W data goes in RAM. So unless you've got even more ninja ideas, I think your work is already done and no "loading" is needed? Then again, I may have missed your point :)

Simon

My code is running happily, controlling some complex system... perhaps a reaction vessel or an engine or something... Then something changes and we need to run a different algorithm to control it... now what if we could flush the code that was controlling the system, and load in a new "module". It is hard to explain the idea without an example, I should probably try and put something together first.

Basic idea is that my code generally runs a main loop, executing various function to control certain things. what if each function was loaded separately from the initial bootloaded program. I reserve a block of memory, load my code and jump to it... then I can swap out what is in that block of memory to something else on disk... I appreciate we are moving into OS territory here, but I need to take my mind off my main project for a while ;)

A switch/case on a list of functions (operating in a cooperative model,  each function will return and not block for long periods of time) will do what you want in a very simple manner.

An array of function pointers would be the next elegant way that are dynamically loaded with your task would be the next elegant method.

Matt Parsons wrote:

 

I reserve a block of memory, load my code and jump to it... then I can swap out what is in that block of memory to something else on disk...

The goal posts seem to have moved since your original question ;-) Are you now saying that the total amount of code that you might need to run in one session is greater than the Flash size?

So you basically need a mechanism similar to DOS overlays?

Lol, guys, you have the wrong end of the stick here! It is not an issue to load some code from the flash at runtime and then jump to it, that is fine. I have plenty of experience with this from my old M68k/Amiga days...

My question is about the mbed compiler, does/can it produce position independent code that I can use as modules? Or will I need to use my separate gcc compiler to build the runtime modules?

The compiler output would need to be position independent and unlinked.

All of mbed's flash is mapped to memory and is directly executable, so you don't need any tricks to run from it. You should worry about it if you manage to reach 512KB which I don't think you will any time soon. Don't put the carriage before the horse.

Igor, I believe he's asking if mbed has the equivalent of gcc's -fpic / -fPIC (I think it's called ROPI in armcc or something similar). Which is actually a good question :)

There's another thing going on here, as far as I can tell. Since the 512KB Flash size is so huge, there's really only one reason I can think of that one would need position-independent-code - to use it and link it with another tool. My gut tells me that it would be amazing to build a VERY simple Mbed program that includes a single call to all MBed libraries. Thus, the MBed linker would include the executable code for all MBed library calls. Since the code would be position indpendent, you could then link it to something else you wrote, with a different toolchain.

At least, that's the only reason I can think position independent code would be helpful.

Bogdan Marinescu wrote:

Igor, I believe he's asking if mbed has the equivalent of gcc's -fpic / -fPIC (I think it's called ROPI in armcc or something similar). Which is actually a good question :)

The compiler (RVCT) supports that but you can't set compiler options in the online IDE. It also doesn't make much sense to use since the final binary has to be linked absolutely anyway.

Greg Link wrote:
Since the code would be position indpendent, you could then link it to something else you wrote, with a different toolchain.

Or you can just link to the static libraries available in SVN.

Hi Matt,

I think the answer you are looking for is "no"! We generate binaries, and that is it. Keeps it simple, and avoids feature creep :)

Simon

Simon Ford wrote:

Hi Matt,

I think the answer you are looking for is "no"! We generate binaries, and that is it. Keeps it simple, and avoids feature creep :)

Simon

I think I have to get out of the limited Harvard Architecture mind set of my 8bit MCUs! :)

Matt Parsons wrote:

 

Simon Ford wrote:

Hi Matt,

I think the answer you are looking for is "no"! We generate binaries, and that is it. Keeps it simple, and avoids feature creep :)

Simon

Lol! Ok, that's not a problem, I was just thinking out aloud. I also didn't realise that the whole 512K of flash was usable directly for code!

 

I think I have to get out of the limited Harvard Architecture mind set of my 8bit MCUs! :)

Well if we're going to get picky, it's actually a modified harvard architecture :) Code and data share the same address space, but there are separate busses to transfer each.

....i'm totally going to have to setup a ninja forum for these sort of discussions. a) to stop intimidating people with these deep diving discussions that many can ignore, and b) to encourage these discussions from which many can learn! A difficult balance of interests!!

Simon

Dear Matt Parsons, Simon Ford and colleagues, first of all, sorry about my poor English. Your question Matt, is direct related with my current design. I am working in a system bus that I call SPI8CON. This system is based on FRDM-KL25Z and FRDM-K64F. This bus has 8 lines: miso, mosi, sclk, select, int_in, int_out, +5vdc and gnd. At boot, during the bus arbitration, the "select" line goes down and the first SPI byte is transmitted by the "master" and received by "slaves". In this byte, the 4 most significant bits, select one of 8 interfaces (slave circuit board - DIP Switch or EEPROM defined) present in the bus. The fourth bit is the parity of the last 3. The remainder 4 bits, select one of 8 SPI devices present in the interface. Again, one bit is used as parity. With this design, is possible for each "master" (KL25Z or K64F) manage up to 64 SPI devices (8/interface x 8 interfaces). After detected all interfaces, the "master" can start to retrieving and putting data in the interfaces. At this moment, the simulation of the system is working well. There are 4 interfaces designed: [1]analog controller (AD and DA 18 bit resolution), [2]digital I/O (24 bit), [3]memory (RAM, EEPROM and Phase Change Memory - PCM) and [4]communication (UART 6, 10 and 12 Mbps - RS485). Everything looks great, but every day there are users asking for new interfaces: DA 20 bit resolution, AD 24 bit resolution, temperature, etc. This system is going to be used in a Synchrotron installation. The number of interfaces will reach 4000 units. If I need to change the "master" software each time that I install a new interface, I will get crazy. So, I am thinking about to install the software of each new interface inside the interface (Plug&Play - I hope not to be Plug&Pray). During the bus arbitration, the manager software could "download" the software for that kind of interface (device driver). If possible, this system will be very modular and dynamic. Matt and/or Simon, do you have any idea about how can I do this using the MBED compiler? I am learning about the structure of MBED application for KL25Z and K64F and ARM software/firmware, but it is a hard way. Any help will be welcome. Thanks, Gfranco (www.lnls.br (Sirius))