Extending MCU memory with SPI?

[Patrick Mc(avery]

I know next to nothing about SPI but I was wondering if SPI memory
devices might be useful for the project?

I was thinking that if SPI devices could be used to add ROM and RAM, it
might allow devices that would otherwise be underspec'd to the project.

Surely this would deeply complicate bootstraping and if the access times
were too slow, this would be a dead end.

I am learning Kicad now and have had a simple design fabricated. Maybe I
will be able to prototype some boards some day soon. If it was a
sensible thing to do, i could do an experiment.

I just got my first JTAG pod this week and I am practising with openOCD
now. One of these days I hope to get back to my tutorials. Even if I am
not recording them, at least I am still learning and might be useful
later :)

-Pat
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Paul Curtis]

On 5 Jun 2012, at 13:36, Patrick wrote:

> I know next to nothing about SPI but I was wondering if SPI memory devices might be useful for the project?
>
> I was thinking that if SPI devices could be used to add ROM and RAM, it might allow devices that would otherwise be underspec'd to the project.
>
> Surely this would deeply complicate bootstraping and if the access times were too slow, this would be a dead end.

SPI SRAM/FRAM/EEPROM/flash is a mass storage medium with the different characteristics of the underlying physical technology exposed.  SPI SRAM (like that from Microchip) or MRAM (from Cypress) is not directly addressable in C code and can't be used as a generic "add more RAM or flash" mechanism. (*)

>
> I am learning Kicad now and have had a simple design fabricated. Maybe I will be able to prototype some boards some day soon. If it was a sensible thing to do, i could do an experiment.
>

This is doomed to fail if you want to add "more memory" that isn't treated as mass storage.

(*) There are microtrollers that can use quad SPI memory as general memory, like on a PC BIOS, but these are few.

-- Paul.

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

According to the IEEE Embedded C standard ISO/IEC TR 18037 (see p.74
Annex B - Named address spaces and named-register storage classes) a
compiler shall provide a capability for creating such qualifiers
thus you may create variables in any kind of a memory device (with
any kind of interface to the memory). Such identifier can be then
used with any data types, including structures, unions, arrays, and
pointers etc. So it is a matter of compiler not the actual hardware.
Having such compiler you can extend MCU memory via SPI to
fram/mram/sram or a punched card. We do not discuss a potential
execution speed penalty here, of course :)
p.

----- PŮVODNÍ ZPRÁVA -----
Od: "Paul Curtis" <[hidden email]>
Komu: "eLua Users and Development List (www.eluaproject.net)"
<[hidden email]>
Předmět: Re: [eLua-dev] Extending MCU memory with SPI?
Datum: 5.6.2012 - 17:56:28

>
> On 5 Jun 2012, at 13:36, Patrick wrote:
>
> > I know next to nothing about SPI but I was
> > wondering if SPI memory devices might be useful
> > for the project?
> > >
> > I was thinking that if SPI devices could be used
> > to add ROM and RAM, it might allow devices that
> > would otherwise be underspec'd to the project.
> > >
> > Surely this would deeply complicate bootstraping
> > and if the access times were too slow, this
> > would be a dead end.
> >
> SPI SRAM/FRAM/EEPROM/flash is a mass storage
> medium with the different characteristics of the
> underlying physical technology exposed.  SPI SRAM
> (like that from Microchip) or MRAM (from Cypress)
> is not directly addressable in C code and can't be
> used as a generic "add more RAM or flash"
> mechanism. (*)
>
> >
> > I am learning Kicad now and have had a simple
> > design fabricated. Maybe I will be able to
> > prototype some boards some day soon. If it was a
> > sensible thing to do, i could do an experiment.
> > >
>
> This is doomed to fail if you want to add "more
> memory" that isn't treated as mass storage.
>
> (*) There are microtrollers that can use quad SPI
> memory as general memory, like on a PC BIOS, but
> these are few.
>
> -- Paul.
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Paul Curtis]

On 5 Jun 2012, at 18:56, pito wrote:

> According to the IEEE Embedded C standard ISO/IEC TR 18037 (see p.74
> Annex B - Named address spaces and named-register storage classes) a
> compiler shall provide a capability for creating such qualifiers
> thus you may create variables in any kind of a memory device (with
> any kind of interface to the memory). Such identifier can be then
> used with any data types, including structures, unions, arrays, and
> pointers etc. So it is a matter of compiler not the actual hardware.
> Having such compiler you can extend MCU memory via SPI to
> fram/mram/sram or a punched card. We do not discuss a potential
> execution speed penalty here, of course :)

That is a TR and its status is "withdrawn" because it has been replaced; even when it was active, it was only a TR and therefore not mandated.  No mainstream embedded vendor ever implemented such a scheme as it is truly brain dead.  I mean, really, my thoughts on the matter are unprintable.  Even GCC has not implemented this TR.

Having implemented many embedded C compilers over the past 25 years, nobody has ever asked me to implement this madness.  C99 is also madness.  The C steering group seem to have got themselves back into the "no invention" mindset for the latest C11 standard, which is a Very Good Thing Indeed.

-- Paul.

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Tue, Jun 5, 2012 at 8:56 PM, pito <[hidden email]> wrote:

> According to the IEEE Embedded C standard ISO/IEC TR 18037 (see p.74
> Annex B - Named address spaces and named-register storage classes) a
> compiler shall provide a capability for creating such qualifiers
> thus you may create variables in any kind of a memory device (with
> any kind of interface to the memory). Such identifier can be then
> used with any data types, including structures, unions, arrays, and
> pointers etc. So it is a matter of compiler not the actual hardware.
> Having such compiler you can extend MCU memory via SPI to
> fram/mram/sram or a punched card. We do not discuss a potential
> execution speed penalty here, of course :)

That sounds extremely good. That is, until you manage to cast a
pointer to a different memory space or simply cast away a "const"
(something extremely easy to do in C). I actually implemented
something like this in a compiler a while ago. It's spectacular, but
also error prone and a nightmare to use and especially maintain. Some
compilers take this to the extreme, encoding a pointer with an extra
byte that specifies what memory space the pointer belongs to (I've
seen this done on 8051, where it actually makes a lot of sense). This
works nice, but the extra level of indirection has quite an obvious
impact on the speed. Paul is right: the memory has to be directly
accesible by the CPU core in order to be useful. And again, as Paul
said, this isn't generally the case for serial memories on "usual"
CPUs. I believe some NXP Cortex M3 or M4 core MCUs have this
capability. In this case, extending the memory with SPI chips would be
possible, but I'm willing to bet you're going to throw your board away
after running eLua from a serial RAM for more than 5 minutes. Lua's
speed is extremely dependent on the RAM speed (which is
understandable, given the fact that every instance or every type in
Lua is allocated on the heap). The difference in speed is easily
visible even when switching from internal SRAM to external SRAM/SDRAM.
SPI would be inhumanly slow.
That said, nice idea :) Keep'em coming!

Best,
Bogdan

> p.
>
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "Paul Curtis" <[hidden email]>
> Komu: "eLua Users and Development List (www.eluaproject.net)"
> <[hidden email]>
> Předmět: Re: [eLua-dev] Extending MCU memory with SPI?
> Datum: 5.6.2012 - 17:56:28
>
>>
>> On 5 Jun 2012, at 13:36, Patrick wrote:
>>
>> > I know next to nothing about SPI but I was
>> > wondering if SPI memory devices might be useful
>> > for the project?
>> > >
>> > I was thinking that if SPI devices could be used
>> > to add ROM and RAM, it might allow devices that
>> > would otherwise be underspec'd to the project.
>> > >
>> > Surely this would deeply complicate bootstraping
>> > and if the access times were too slow, this
>> > would be a dead end.
>> >
>> SPI SRAM/FRAM/EEPROM/flash is a mass storage
>> medium with the different characteristics of the
>> underlying physical technology exposed.  SPI SRAM
>> (like that from Microchip) or MRAM (from Cypress)
>> is not directly addressable in C code and can't be
>> used as a generic "add more RAM or flash"
>> mechanism. (*)
>>
>> >
>> > I am learning Kicad now and have had a simple
>> > design fabricated. Maybe I will be able to
>> > prototype some boards some day soon. If it was a
>> > sensible thing to do, i could do an experiment.
>> > >
>>
>> This is doomed to fail if you want to add "more
>> memory" that isn't treated as mass storage.
>>
>> (*) There are microtrollers that can use quad SPI
>> memory as general memory, like on a PC BIOS, but
>> these are few.
>>
>> -- Paul.
>>
>> _______________________________________________
>> eLua-dev mailing list
>> [hidden email]
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>
> --
> - - Reklama - - - - - - - - - - - - - -
> Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
> studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
> http://bit.ly/LfImCR
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Paul Curtis]

On 5 Jun 2012, at 19:31, Bogdan Marinescu wrote:

> On Tue, Jun 5, 2012 at 8:56 PM, pito <[hidden email]> wrote:
>> According to the IEEE Embedded C standard ISO/IEC TR 18037 (see p.74
>> Annex B - Named address spaces and named-register storage classes) a
>> compiler shall provide a capability for creating such qualifiers
>> thus you may create variables in any kind of a memory device (with
>> any kind of interface to the memory). Such identifier can be then
>> used with any data types, including structures, unions, arrays, and
>> pointers etc. So it is a matter of compiler not the actual hardware.
>> Having such compiler you can extend MCU memory via SPI to
>> fram/mram/sram or a punched card. We do not discuss a potential
>> execution speed penalty here, of course :)
>
> That sounds extremely good. That is, until you manage to cast a
> pointer to a different memory space or simply cast away a "const"
> (something extremely easy to do in C). I actually implemented
> something like this in a compiler a while ago. It's spectacular, but
> also error prone and a nightmare to use and especially maintain. Some
> compilers take this to the extreme, encoding a pointer with an extra
> byte that specifies what memory space the pointer belongs to (I've
> seen this done on 8051, where it actually makes a lot of sense). This
> works nice, but the extra level of indirection has quite an obvious
> impact on the speed.

The Keil compiler did (does) do this for "general pointers".  True Harvard machines, with separate code and data address spaces, and machines like the 8051 (xdata, idata, code, and sfr and all that) make coding in portable C a nightmare.  Yes, the memory-space-qualified pointer means that you don't need to care what type of pointer you have, but it makes every single access through that pointer so very slow...

> Paul is right: the memory has to be directly
> accesible by the CPU core in order to be useful. And again, as Paul
> said, this isn't generally the case for serial memories on "usual"
> CPUs. I believe some NXP Cortex M3 or M4 core MCUs have this
> capability.

This would be the SPIFI memory:

http://dkc1.digikey.com/uk/en/tod/NXP/SPIFI-Introduction_NoAudio/SPIFI-Introduction_NoAudio.html

What make SPIFI viable is that all you see is slower access, the magic memory system takes care of all the nastiness of reading the SPI device.  At the C level, a pointer is a pointer is a pointer, and it points anywhere, and if it points into the SPIFI address space, that's OK, the hardware (not software) takes care of it.  Great!  No need for crap C-level madness.


> In this case, extending the memory with SPI chips would be
> possible, but I'm willing to bet you're going to throw your board away
> after running eLua from a serial RAM for more than 5 minutes. Lua's
> speed is extremely dependent on the RAM speed (which is
> understandable, given the fact that every instance or every type in
> Lua is allocated on the heap). The difference in speed is easily
> visible even when switching from internal SRAM to external SRAM/SDRAM.
> SPI would be inhumanly slow.

Having seen the speed that SPIFI works at, you are not really going to use it for anything compute intensive.

-- Paul.

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

Frankly, I think such compiler capability is nice to have! When the
speed is not a paramount you may easily compile/run large stuff on
relatively small MCUs.
BTW the CCS compiler for PIC MCUs has got the "addressmod" (and it
works somehow), and maybe IAR for AVR (xmega) has similar option
too..
p.

----- PŮVODNÍ ZPRÁVA -----
Od: "Paul Curtis" <[hidden email]>
Komu: "pito" <[hidden email]>
Předmět: Re: [eLua-dev] Extending MCU memory with SPI?
Datum: 5.6.2012 - 20:19:53

>
> On 5 Jun 2012, at 18:56, pito wrote:
>
> > According to the IEEE Embedded C standard
> > ISO/IEC TR 18037 (see p.74
> > > Annex B - Named address spaces and
> > named-register storage classes) a
> > > compiler shall provide a capability for creating
> > such qualifiers
> > > thus you may create variables in any kind of a
> > memory device (with
> > > any kind of interface to the memory). Such
> > identifier can be then
> > > used with any data types, including structures,
> > unions, arrays, and
> > > pointers etc. So it is a matter of compiler not
> > the actual hardware.
> > > Having such compiler you can extend MCU memory
> > via SPI to
> > > fram/mram/sram or a punched card. We do not
> > discuss a potential
> > > execution speed penalty here, of course :)
>
> That is a TR and its status is "withdrawn" because
> it has been replaced; even when it was active, it
> was only a TR and therefore not mandated.  No
> mainstream embedded vendor ever implemented such a
> scheme as it is truly brain dead.  I mean, really,
> my thoughts on the matter are unprintable.  Even
> GCC has not implemented this TR.
>
> Having implemented many embedded C compilers over
> the past 25 years, nobody has ever asked me to
> implement this madness.  C99 is also madness.  The
> C steering group seem to have got themselves back
> into the "no invention" mindset for the latest C11
> standard, which is a Very Good Thing Indeed.
>
> -- Paul.
>
>

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Tue, Jun 5, 2012 at 9:40 PM, Paul Curtis <[hidden email]> wrote:

>
> On 5 Jun 2012, at 19:31, Bogdan Marinescu wrote:
>
>> On Tue, Jun 5, 2012 at 8:56 PM, pito <[hidden email]> wrote:
>>> According to the IEEE Embedded C standard ISO/IEC TR 18037 (see p.74
>>> Annex B - Named address spaces and named-register storage classes) a
>>> compiler shall provide a capability for creating such qualifiers
>>> thus you may create variables in any kind of a memory device (with
>>> any kind of interface to the memory). Such identifier can be then
>>> used with any data types, including structures, unions, arrays, and
>>> pointers etc. So it is a matter of compiler not the actual hardware.
>>> Having such compiler you can extend MCU memory via SPI to
>>> fram/mram/sram or a punched card. We do not discuss a potential
>>> execution speed penalty here, of course :)
>>
>> That sounds extremely good. That is, until you manage to cast a
>> pointer to a different memory space or simply cast away a "const"
>> (something extremely easy to do in C). I actually implemented
>> something like this in a compiler a while ago. It's spectacular, but
>> also error prone and a nightmare to use and especially maintain. Some
>> compilers take this to the extreme, encoding a pointer with an extra
>> byte that specifies what memory space the pointer belongs to (I've
>> seen this done on 8051, where it actually makes a lot of sense). This
>> works nice, but the extra level of indirection has quite an obvious
>> impact on the speed.
>
> The Keil compiler did (does) do this for "general pointers".  True Harvard machines, with separate code and data address spaces, and machines like the 8051 (xdata, idata, code, and sfr and all that) make coding in portable C a nightmare.  Yes, the memory-space-qualified pointer means that you don't need to care what type of pointer you have, but it makes every single access through that pointer so very slow...
>
>> Paul is right: the memory has to be directly
>> accesible by the CPU core in order to be useful. And again, as Paul
>> said, this isn't generally the case for serial memories on "usual"
>> CPUs. I believe some NXP Cortex M3 or M4 core MCUs have this
>> capability.
>
> This would be the SPIFI memory:
>
> http://dkc1.digikey.com/uk/en/tod/NXP/SPIFI-Introduction_NoAudio/SPIFI-Introduction_NoAudio.html

Thanks! That's a clear, no-nonsense presentation. I'll probably give
SPIFI a try at some point, just for the heck of it :) I don't expect
miracles, but I have to admit that I like the concept. I envisioned
something like this and I'm glad to see that somebody actually made it
happen.

Best,
Bogdan

>
> What make SPIFI viable is that all you see is slower access, the magic memory system takes care of all the nastiness of reading the SPI device.  At the C level, a pointer is a pointer is a pointer, and it points anywhere, and if it points into the SPIFI address space, that's OK, the hardware (not software) takes care of it.  Great!  No need for crap C-level madness.
>
>
>> In this case, extending the memory with SPI chips would be
>> possible, but I'm willing to bet you're going to throw your board away
>> after running eLua from a serial RAM for more than 5 minutes. Lua's
>> speed is extremely dependent on the RAM speed (which is
>> understandable, given the fact that every instance or every type in
>> Lua is allocated on the heap). The difference in speed is easily
>> visible even when switching from internal SRAM to external SRAM/SDRAM.
>> SPI would be inhumanly slow.
>
> Having seen the speed that SPIFI works at, you are not really going to use it for anything compute intensive.
>
> -- Paul.
>

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Paul Curtis]

On 5 Jun 2012, at 19:45, pito wrote:

> Frankly, I think such compiler capability is nice to have!

Frankly, it's fine to have opinions.  However, I am glad that only relatively small set of people in the world get to implement commercial compilers.  :-)

> When the
> speed is not a paramount you may easily compile/run large stuff on
> relatively small MCUs.

There is no need for this at all.  The 16-bit CPU is going to be squeezed, rather like 8-bit CPUs.  Why use such a restricted device when NXP are coming out with powerful 32-bit Cortex-M0 cores for pennies?  The only reason to stick is familiarity (something Microchip seem to foster) and brand loyalty and availability (again Microchip seem to excel at this).  Sure, 8-bit 8051 is still thriving, but even high-performance vendors such as Silicon Labs have migrated to 32-bit Cortex-M3 devices for their latest set of products...

> BTW the CCS compiler for PIC MCUs has got the "addressmod" (and it
> works somehow), and maybe IAR for AVR (xmega) has similar option
> too..

I'm pretty sure the IAR AVR compiler doesn't implement this bizarreness.

-- Paul.

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

> Why use such a restricted device when NXP are
> coming out with powerful 32-bit Cortex-M0 cores
> for pennies?  
That is not about 8/16/32bitters or CM0,3,4 mcu's for pennies. That
is about an ability to compile a larger code (larger data space) on
such mcu's. Maybe someone wants to run a code which needs to access
2Mbytes of RAM with various data (any types). Today I take ie. a
pic24hj @40MHz, I connect 4x MR25H40 (512KB 40MHz SPI mram) and with
such compiler option I can run the code with an int32 type accessed
in ~10useconds. I was maybe the first guy running eLua on the
stm32F4 in full192kB ram (thanks to eLua guys), but I must admit
even 192kB ram is not a big deal for eLua :)
SPIFI with a mapping into cpu's address space is great, what is
needed, however, is the fram/mram/sram vendors will adopt this
interface as well (and fast) !
p.

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 5 June 2012 19:56, pito <[hidden email]> wrote:

> According to the IEEE Embedded C standard ISO/IEC TR 18037 (see p.74
> Annex B - Named address spaces and named-register storage classes) a
> compiler shall provide a capability for creating such qualifiers
> thus you may create variables in any kind of a memory device (with
> any kind of interface to the memory). Such identifier can be then
> used with any data types, including structures, unions, arrays, and
> pointers etc. So it is a matter of compiler not the actual hardware.
> Having such compiler you can extend MCU memory via SPI to
> fram/mram/sram or a punched card. We do not discuss a potential
> execution speed penalty here, of course :)

With the AVR32, we found that the speed penalty between executing from
internal flash and executing in external SDRAM was a factor of 6.
I'd hate to think what the penalty would be for an SPI transfer,
albeit only for data accesses. Any figures?

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Wed, Jun 6, 2012 at 5:35 AM, Martin Guy <[hidden email]> wrote:

> On 5 June 2012 19:56, pito <[hidden email]> wrote:
>> According to the IEEE Embedded C standard ISO/IEC TR 18037 (see p.74
>> Annex B - Named address spaces and named-register storage classes) a
>> compiler shall provide a capability for creating such qualifiers
>> thus you may create variables in any kind of a memory device (with
>> any kind of interface to the memory). Such identifier can be then
>> used with any data types, including structures, unions, arrays, and
>> pointers etc. So it is a matter of compiler not the actual hardware.
>> Having such compiler you can extend MCU memory via SPI to
>> fram/mram/sram or a punched card. We do not discuss a potential
>> execution speed penalty here, of course :)
>
> With the AVR32, we found that the speed penalty between executing from
> internal flash and executing in external SDRAM was a factor of 6.
> I'd hate to think what the penalty would be for an SPI transfer,
> albeit only for data accesses. Any figures?

I'd rather not give myself nightmares thinking about that :)

Best,
Bogdan

>
>    M
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

Worstcase scenario - random access to "char":
Except data/addr preparation there is an overhead with access to a
standard SPI sram/fram/mram, usualy 4/5bytes +1byte data (22%
efficiency). Then, the SPI clock is slow, usualy 1/2 to 1/4 of the
MCU clock max. In total I measured 7usec for a random r/w to a
single byte in an external 256kByte SPI fram (SPI clocked at
12.5MHz, no waitstates with r/w,  pic24hj clocked at 50MHz).
Internal ram may access the byte in ~40ns (or 20ns?).

With reading larger types the ratio/efficiency goes better, as the
fram/mram has an autoincrement feature. For example int64 needs
4/5bytes + 8bytes (63% efficiency). I achieved 1000kBytes//sec with
r/w to a 512bytes large continous block with above setup.
p.

----- PŮVODNÍ ZPRÁVA -----
Od: "Martin Guy" <[hidden email]>
Komu: "eLua Users and Development List (www.eluaproject.net)"
<[hidden email]>
Předmět: Re: [eLua-dev] Extending MCU memory with SPI?
Datum: 6.6.2012 - 4:35:42

> On 5 June 2012 19:56, pito <[hidden email]> wrote:
> > According to the IEEE Embedded C standard
> > ISO/IEC TR 18037 (see p.74
> > > Annex B - Named address spaces and
> > named-register storage classes) a
> > > compiler shall provide a capability for creating
> > such qualifiers
> > > thus you may create variables in any kind of a
> > memory device (with
> > > any kind of interface to the memory). Such
> > identifier can be then
> > > used with any data types, including structures,
> > unions, arrays, and
> > > pointers etc. So it is a matter of compiler not
> > the actual hardware.
> > > Having such compiler you can extend MCU memory
> > via SPI to
> > > fram/mram/sram or a punched card. We do not
> > discuss a potential
> > > execution speed penalty here, of course :)
>
> With the AVR32, we found that the speed penalty
> between executing from
> internal flash and executing in external SDRAM was
> a factor of 6.
> I'd hate to think what the penalty would be for an
> SPI transfer,
> albeit only for data accesses. Any figures?
>
> M
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

Best case estimation: with stm32f4 @168MHz and SPI @ 40MHz (this is
the typical max  SPI speed for today's fram/mram serial memories)
you may r/w access a single random char in fram/mram in ~1.5usecs,
int32 in ~2usecs, int64 in ~3usecs. Or better :)  /p.

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Paul Curtis]

> Best case estimation: with stm32f4 @168MHz and SPI @ 40MHz (this is the
> typical max  SPI speed for today's fram/mram serial memories) you may r/w
> access a single random char in fram/mram in ~1.5usecs,
> int32 in ~2usecs, int64 in ~3usecs. Or better :)  /p.

You your blistering 168 MHz Cortex-M device would then run at, say, 500 kHz
assuming 2 bytes/instruction?

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk
SolderCore running Defender...       http://www.vimeo.com/25709426 


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 6 June 2012 09:49, pito <[hidden email]> wrote:
> Best case estimation: with stm32f4 @168MHz and SPI @ 40MHz (this is
> the typical max  SPI speed for today's fram/mram serial memories)
> you may r/w access a single random char in fram/mram in ~1.5usecs,
> int32 in ~2usecs, int64 in ~3usecs. Or better :)  /p.

Many thanks for the research.
The most frequent case is a 32-bit access for pointers and ints, and
between 20-40ns and 2us there is a factor of 50-100 slowdown.
It would be useful only if you were so short of RAM that, without it,
you could not run your application at all, and that the application
have modest CPU requirements.

When we found the unexpected factor of 6 slowdown we stopped
development in that direction for general release.
Hats off to Marcus for getting it ("emBLOD") to work though - quite a
feat of hackery!

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Antti Lukats]

http://www.trioflex.ee/index.php/services/portfolio/6-comp2hdmi

on the bottom of that PCB there is CortexM0 that is executing CortexM0
code from SPI flash...

updates to those images are done via web browser access from WII
console, point to update page, start flash movie.. the sound is
decoded in real time while the M0 is generating onscreen graphics in
background.. updates are written to the SPI flash, and then new code
is executing from spi flash

Antti

On Wed, Jun 6, 2012 at 12:19 PM, Martin Guy <[hidden email]> wrote:

> On 6 June 2012 09:49, pito <[hidden email]> wrote:
>> Best case estimation: with stm32f4 @168MHz and SPI @ 40MHz (this is
>> the typical max  SPI speed for today's fram/mram serial memories)
>> you may r/w access a single random char in fram/mram in ~1.5usecs,
>> int32 in ~2usecs, int64 in ~3usecs. Or better :)  /p.
>
> Many thanks for the research.
> The most frequent case is a 32-bit access for pointers and ints, and
> between 20-40ns and 2us there is a factor of 50-100 slowdown.
> It would be useful only if you were so short of RAM that, without it,
> you could not run your application at all, and that the application
> have modest CPU requirements.
>
> When we found the unexpected factor of 6 slowdown we stopped
> development in that direction for general release.
> Hats off to Marcus for getting it ("emBLOD") to work though - quite a
> feat of hackery!
>
>    M
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

There is always a mix of accesses to an external SPI ram
(fram/mram/sram) and to internal ram and internal flash. So 2us
int32 access to an external SPI ram does not mean the whole system
will run @ 500kHz :)

I do not know how it is with eLUA, but I guess when accessing
external SPI ram 20-30% of time you may get  _much_  better overall
average speed..

p.
----- PŮVODNÍ ZPRÁVA -----
Od: "Martin Guy" <[hidden email]>
Komu: "pito" <[hidden email]>
Předmět: Re: [eLua-dev] Extending MCU memory with SPI?
Datum: 6.6.2012 - 11:19:23

> On 6 June 2012 09:49, pito <[hidden email]> wrote:
> > Best case estimation: with stm32f4 @168MHz and
> > SPI @ 40MHz (this is
> > > the typical max  SPI speed for today's fram/mram
> > serial memories)
> > > you may r/w access a single random char in
> > fram/mram in ~1.5usecs,
> > > int32 in ~2usecs, int64 in ~3usecs. Or better :)
> >  /p.
> >
> Many thanks for the research.
> The most frequent case is a 32-bit access for
> pointers and ints, and
> between 20-40ns and 2us there is a factor of
> 50-100 slowdown.
> It would be useful only if you were so short of
> RAM that, without it,
> you could not run your application at all, and
> that the application
> have modest CPU requirements.
>
> When we found the unexpected factor of 6 slowdown
> we stopped
> development in that direction for general release.
> Hats off to Marcus for getting it ("emBLOD") to
> work though - quite a
> feat of hackery!
>
> M
>

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Paul Curtis]

> http://www.trioflex.ee/index.php/services/portfolio/6-comp2hdmi
>
> on the bottom of that PCB there is CortexM0 that is executing CortexM0
> code from SPI flash...
>
> updates to those images are done via web browser access from WII console,
> point to update page, start flash movie.. the sound is decoded in real
> time while the M0 is generating onscreen graphics in background.. updates
> are written to the SPI flash, and then new code is executing from spi
> flash

It doesn't actually say that it executes from SPI flash.  It states it runs
a virtualized CPU with the emulator fetching virtual instructions from SPI
flash.  At no point is hard Cortex-M0 running its own instructions from SPI
flash.  Note that the blurb is actually quite loose because it says it
fetches ARM instructions for a Thumb-2 processor--in general, neither the
ARM instruction set nor the "full" Thumb-2 instruction set will run on a
Cortex-M0 device because they are different architectures.  (Ok, the Thumb
subset will run on a Thumb-2-capable processor, please don't be pedantic).

Well, that's what I read from the article.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk
SolderCore running Defender...       http://www.vimeo.com/25709426 

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

> It doesn't actually say that it executes from SPI
> flash.  It states it runs
> a virtualized CPU with the emulator fetching
> virtual instructions from SPI
> flash.  
Paul, it is a common understanding here we do not plan or discuss to
run a code directly out of SPI. It is always a kind of
emulation/virtualisation..

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev