On Sat, Feb 27, 2010 at 3:38 PM, David Brownell <[email protected]> wrote: > On Saturday 27 February 2010, Mariano Alvira wrote: >> >> > I don't entirely "get" these chips which execute code from large SRAMs >> > instead of from NOR flash ... I had understood that the SRAMs use more >> > power than the NOR flash, so that most microcontrollers minimized the >> > quantity of SRAM they included (even at the cost of annoying the folk >> > writing code that might like more SRAM). >> >> Yeah, after working with it I actually really like just running out of >> RAM. You don't have to flash everytime to test something. > > Another option is to provide both "enough SRAM" *and* much flash. :) > > Of course, that still costs extra power. Which can be OK on > development boards where the power budget doesn't much matter.
You can power the RAM down in blocks. I think the smallest block is 8KB. Code that lives in that 8KB can reload the 60KB of RAM from flash. The chip is extremely power efficient. It draws 0.85uA with the 8KB RAM in hibernate mode. 08mA running with the radio off. You are supposed to be able to run it for ten years off from batteries in a remote control. > > >> Also your >> "code space" is limitless if you come up with an elf loader or >> some other kind of swapping/virtual memory thing (no MMU though). > > But in practice, most of that code is read-only and therefore may as > well live in NOR flash so you can execute-in-place. And not *NEED* > to come up with some kind of segment loader. > > >> Also you get to make the tradeoff between code/data. No more of these >> 128KB flash things with only 4KB of SRAM. Now you get 96KB of SRAM --- >> and you can slice it up however you want. > > No question that 4K isn't much R/W memory to pair up with 128K flash. > The 32-bit processors I've looked at which have 128 tend to not be > that parsimonious ... 32K (or more) is a bit more typical there. > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development > -- Jon Smirl [email protected] _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
