Finally a PIC32 with FPU for embedded Lua on MIPS

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Finally a PIC32 with FPU for embedded Lua on MIPS

KHMan
Hi all,

A bit of good news for embedded Lua users, specifically on the
topic of Lua on a MIPS chip :-)

A PIC32MZ EF Family data sheet recently popped up on Microchip's
data sheet RSS feed [1]. FPU on the chip finally! No official
announcement yet, and it's not in the PIC32 parts table, so
probably no customer samples etc yet. It's just a data sheet drop
before PR releases, advance info, but I think we should be able to
buy it this year.

So finally there will be a MIPS part that can run standard Lua
with floating point hardware, and minimal source code changes, and
can be easily purchased by normal folks [2]. For those who don't
want to peruse the data sheet, it's 200MHz, up to 512KB SRAM [3]
and up to 2MB flash on chip. FPU throughput is mostly 1 cycle,
latency for ADD/SUB is 4/5 cycles. Downside: the errata doc for
its predecessor PIC32MZ EC family was very long...

[1] http://www.microchip.com/RSS/Recent-DataSheets.xml
[2] there is Ingenic, but it's kinda hard to source
[3] a goodly amount of RAM for Lua on an easily solderable TQFP
(everything else with >=512KB SRAM on Farnell is a BGA part)

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

BogdanM
The new Cortex-M7 from ARM supports double precision FPU as an implementation option too:

http://www.bdti.com/InsideDSP/2014/09/25/ARM

We just need to wait a bit for the chips to appear. Also, double-precision FPU existed on Cortex-R parts for a while now, see for example http://www.ti.com/mcu/docs/mcuproductcontentnp.tsp?sectionId=95&familyId=2056&tabId=2841&DCMP=hercules&HQS=hercules-rm4x-pr-pf.
Indeed, the Microchip parts have an impressive amount of on-chip RAM, which definitely makes them suitable for Lua. I've looked at porting eLua to these for a while, but every time I got put off by various licensing issues with Mircrochip's not-exactly-open-source tools and libraries. Too bad.
In any case, things are looking good for Lua on this front :)


On Fri, Jan 9, 2015 at 12:54 PM, KHMan <[hidden email]> wrote:
Hi all,

A bit of good news for embedded Lua users, specifically on the topic of Lua on a MIPS chip :-)

A PIC32MZ EF Family data sheet recently popped up on Microchip's data sheet RSS feed [1]. FPU on the chip finally! No official announcement yet, and it's not in the PIC32 parts table, so probably no customer samples etc yet. It's just a data sheet drop before PR releases, advance info, but I think we should be able to buy it this year.

So finally there will be a MIPS part that can run standard Lua with floating point hardware, and minimal source code changes, and can be easily purchased by normal folks [2]. For those who don't want to peruse the data sheet, it's 200MHz, up to 512KB SRAM [3] and up to 2MB flash on chip. FPU throughput is mostly 1 cycle, latency for ADD/SUB is 4/5 cycles. Downside: the errata doc for its predecessor PIC32MZ EC family was very long...

[1] http://www.microchip.com/RSS/Recent-DataSheets.xml
[2] there is Ingenic, but it's kinda hard to source
[3] a goodly amount of RAM for Lua on an easily solderable TQFP (everything else with >=512KB SRAM on Farnell is a BGA part)

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

Enrico Colombini
In reply to this post by KHMan
On 09/01/2015 13.54, KHMan wrote:
> [3] a goodly amount of RAM for Lua on an easily solderable TQFP
> (everything else with >=512KB SRAM on Farnell is a BGA part)

I really wish somebody would find a practical way to easily make DIY
prototypes with BGA and flip-chip packages... most of the times I see an
interesting chip, I cant't play with it.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

Roberto Ierusalimschy
In reply to this post by BogdanM
> The new Cortex-M7 from ARM supports double precision FPU as an
> implementation option too:
>
> http://www.bdti.com/InsideDSP/2014/09/25/ARM

Well, one of the key points of Lua 5.3 is that you should not need a
double precision FPU to run it (both because it uses less floating
point and because it is viable to use single-precision floats :-)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

BogdanM

On Fri, Jan 9, 2015 at 1:31 PM, Roberto Ierusalimschy <[hidden email]> wrote:
> The new Cortex-M7 from ARM supports double precision FPU as an
> implementation option too:
>
> http://www.bdti.com/InsideDSP/2014/09/25/ARM

Well, one of the key points of Lua 5.3 is that you should not need a
double precision FPU to run it (both because it uses less floating
point and because it is viable to use single-precision floats :-)

Absoultely! I can't wait to get my hands dirty with that :) The addition of bitwise operators is also a huge plus in the context of Lua on MCUs.

Thanks,
Bogdan
 

-- Roberto


Reply | Threaded
Open this post in threaded view
|

RE: Finally a PIC32 with FPU for embedded Lua on MIPS

John Hind
In reply to this post by KHMan
I would be very interested in a single-chip Lua implementation like this:

http://www.espruino.com/Pico  - for JavaScript

or this:

https://micropython.org/  - for Python

But it seems that Lua's relative extravagance with RAM is still the major
roadblock (it has always been possible to build Lua for integer numbers, so
lack of an FPU has never really been a showstopper). 512KB RAM is plenty to
run Lua, but only with very simple scripts.  Bogdan's eLua is fun to play
with and a brave effort, but in my experience it is not really practical for
real-world applications without at least a two-chip platform (processor and
RAM). One of the great advantages of Lua however is that it is relatively
easy to compile it for bare-metal deployment (i.e. without an operating
system).

What is needed is for the core team to have another look at the memory
allocation strategy so it is easier to build Lua to allocate volatile data
such as numbers and tables in RAM but non-volatile (or less volatile) data
like strings and function bytecodes in EPROM. On these microcontroller chips
it is usually possible to write to EPROM, but you want to minimise that
because it is relatively slow and the memory has limited write endurance.
The big development on the horizon is FRAM which combines the non-volatility
of EPROM with the endurance and speed of RAM bringing back unified memory
architectures (von Neumann rather than Harvard for the computer science
majors amongst you). However only TI are offering FRAM single-chip
microcontrollers at the moment and these do not yet have sufficiently large
unified memories for Lua (or other interpreted languages).


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

BogdanM
Hi John!

On Fri, Jan 9, 2015 at 7:40 PM, John Hind <[hidden email]> wrote:
I would be very interested in a single-chip Lua implementation like this:

http://www.espruino.com/Pico  - for JavaScript

or this:

https://micropython.org/  - for Python

But it seems that Lua's relative extravagance with RAM is still the major
roadblock (it has always been possible to build Lua for integer numbers, so
lack of an FPU has never really been a showstopper).

True for the FPU part. As far as RAM goes, I haven't looked closely at MicroPython yet, but JavaScript also needs a lot of memory. I don't think Lua is taking lot of RAM, all dynamic languages that I know of need a lot of RAM (for good reasons). I wouldn't expect the platforms you mentioned to be much more memory friendly than (e)Lua, but this is just intuition, not facts.
 
512KB RAM is plenty to
run Lua, but only with very simple scripts. 

I dispute that, at least with eLua. You can write fairly non-trivial eLua programs in 512K RAM.
 
Bogdan's eLua is fun to play
with and a brave effort, but in my experience it is not really practical for
real-world applications without at least a two-chip platform (processor and
RAM).

While this obviously depends on the kind of real world applications you have in mind, I believe a chip with 512k of RAM is good for a lot of real world eLua applications.
 
One of the great advantages of Lua however is that it is relatively
easy to compile it for bare-metal deployment (i.e. without an operating
system).

What is needed is for the core team to have another look at the memory
allocation strategy so it is easier to build Lua to allocate volatile data
such as numbers and tables in RAM but non-volatile (or less volatile) data
like strings and function bytecodes in EPROM.

The upvalue-free C functions introduced in 5.2 are already a step in the right direction. The emergency garbage collector helps too. eLua already executes bytecode directly from Flash and reads strings from Flash (partially for now, hopefully completely in the future). I'm about to restart doing some memory analysis for Lua and port my LTR patch to 5.3 and I'm looking at other optimizations. I truly believe that all this + 512k of RAM or even less would make for a pretty awesome eLua single chip.
 
On these microcontroller chips
it is usually possible to write to EPROM, but you want to minimise that
because it is relatively slow and the memory has limited write endurance.
The big development on the horizon is FRAM which combines the non-volatility
of EPROM with the endurance and speed of RAM bringing back unified memory
architectures (von Neumann rather than Harvard for the computer science
majors amongst you). However only TI are offering FRAM single-chip
microcontrollers at the moment and these do not yet have sufficiently large
unified memories for Lua (or other interpreted languages).


I wouldn't hold my breath for FRAM, but let's hope I'm wrong. I'd like to see that too (or any other persistent RAM solution for that matter).

Best,
Bogdan

Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

John Hind
In reply to this post by KHMan
> I believe a chip with 512k of RAM is good for a lot of real world eLua
applications. <Bogdan Marinescu>

Have you considered doing a Kickstarter like the Python and JavaScript
examples I referenced?

> I don't think Lua is taking lot of RAM, all dynamic languages that I know
of need a lot of RAM (for good reasons) . <Bogdan Marinescu>

There is an idea that has been rattling about in my mind for a few years
now, but it may still be a little half-baked. This is that it should be
possible to allocate the bytecodes of functions/closures separately from any
required volatile storage (for example upvalues). The latter would be stored
in RAM, while the bytecodes would be stored as immutable strings (strings in
Lua already being  byte-safe and immutable). Then all you'd need is the
ability to compile the memory allocation functions to allocate strings in
EPROM. Not only does this take the bytecodes (and the strings) out of the
RAM budget, but it also allows string fragment compression/deduplication to
be used on bytecode sequences as well. If source is recompiled and generates
the same bytecode sequence, the deduplication automatically eliminates it
using no more memory. On von Neumann architectures everything would be
allocated from RAM but still benefit from compression, while on
microcontrollers the memory allocation function could be replaced by one
with access to both EPROM and RAM. Garbage collection would also need to be
modified so strings/bytecodes (if allocated in non-volatile memory) are only
collected on demand.

I'm still waiting for the JavaScript kickstarter chip to be delivered so
time will tell how useful it is. JavaScript has the big advantage that being
intrinsically event-driven it fits well with interrupt-driven
microcontroller applications, but compared to Lua it is an ugly, bloated
language, and Python is barely better without even the advantage of being
event-driven. But I think it would be relatively easy to write an
event/interrupt driven scheduler for Lua coroutines.


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

KHMan
On 1/11/2015 12:01 AM, John Hind wrote:

>> I believe a chip with 512k of RAM is good for a lot of real world eLua
> applications. <Bogdan Marinescu>
>
> Have you considered doing a Kickstarter like the Python and JavaScript
> examples I referenced?
>
>> I don't think Lua is taking lot of RAM, all dynamic languages that I know
> of need a lot of RAM (for good reasons) . <Bogdan Marinescu>
>
> There is an idea that has been rattling about in my mind for a few years
> now, but it may still be a little half-baked. This is that it should be
> possible to allocate the bytecodes of functions/closures separately from any
> required volatile storage (for example upvalues). The latter would be stored
> in RAM, while the bytecodes would be stored as immutable strings (strings in
> Lua already being  byte-safe and immutable). Then all you'd need is the
> ability to compile the memory allocation functions to allocate strings in
> EPROM. Not only does this take the bytecodes (and the strings) out of the
> RAM budget, but it also allows string fragment compression/deduplication to
> be used on bytecode sequences as well. If source is recompiled and generates
> the same bytecode sequence, the deduplication automatically eliminates it
> using no more memory. On von Neumann architectures everything would be
> allocated from RAM but still benefit from compression, while on
> microcontrollers the memory allocation function could be replaced by one
> with access to both EPROM and RAM. Garbage collection would also need to be
> modified so strings/bytecodes (if allocated in non-volatile memory) are only
> collected on demand.
[snip snip]

It can be done, but it may be hard to justify the effort. A more
likely solution is simply to choose an appropriate product.

If say a Lua scripted app is likely to hit the limits of a PIC32
with 512KB SRAM, then it would probably make more sense to use an
SBC instead. A PIC32 with an FPU would make it easier for me to do
calculations and drive a robot arm directly (and Lua scripting
will make it much more fun) but I would find an SBC if I wanted to
do robot vision. In short, pick parts based on a target
application and not the other way round.

Today, a non-FPU PIC32 512KB SRAM is about USD10 for 10+ pieces.
Looking at a nice Wikipedia page [1], I can dig a bit and find at
Olimex an Allwinner A13 board for EUR18 (qty 1), it has 256MB DDR3
RAM. Both are very affordable.

So although it's possible to modify Lua for optimal SRAM/Flash
utilization, I would just pick an SBC if an app is too big for a
single IC. IC manufacturing advances wins again. :-)

[1] http://en.wikipedia.org/wiki/Comparison_of_single-board_computers

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

BogdanM
In reply to this post by John Hind


On Sat, Jan 10, 2015 at 4:01 PM, John Hind <[hidden email]> wrote:
> I believe a chip with 512k of RAM is good for a lot of real world eLua
applications. <Bogdan Marinescu>

Have you considered doing a Kickstarter like the Python and JavaScript
examples I referenced?

There was some activity in this area, but we have nothing to show for it yet.
 

> I don't think Lua is taking lot of RAM, all dynamic languages that I know
of need a lot of RAM (for good reasons) . <Bogdan Marinescu>

There is an idea that has been rattling about in my mind for a few years
now, but it may still be a little half-baked. This is that it should be
possible to allocate the bytecodes of functions/closures separately from any
required volatile storage (for example upvalues). The latter would be stored
in RAM, while the bytecodes would be stored as immutable strings (strings in
Lua already being  byte-safe and immutable).
[snip]

Again, eLua already does that. When you compile a Lua program to bytecode and upload it to the internal flash, the bytecode is executed directly from flash. You can also use strings directly from flash, in which case a TString has two parts: a header (dynamically alocated) and a pointer to the actual content (in flash). It's even possible to put the whole TString structure in flash, but this sacrifices elegance and portability (which is not to say that I'm not going to do it eventually). Similary, an eLua rotable lives completely in flash. I believe there are other things than can be moved to flash. This fails (or at least is useless) on pure Harvard archictures, but personally I don't know of any modern 32 bit MCU based on a pure Harvard architecture (except maybe the new ESP8266, I'm still trying to understand that thing).
 
I'm still waiting for the JavaScript kickstarter chip to be delivered so
time will tell how useful it is. JavaScript has the big advantage that being
intrinsically event-driven it fits well with interrupt-driven
microcontroller applications, but compared to Lua it is an ugly, bloated
language, and Python is barely better without even the advantage of being
event-driven.
But I think it would be relatively easy to write an
event/interrupt driven scheduler for Lua coroutines.
 
Yes. Strictly speaking, JavaScript isn't more event driven than Lua. It's just that a lot of things around JavaScript happen around node.js and its event loop (which is something very interesting and I'd like to see that in eLua at some point). But you can implement that model equally well in Lua, Python and many other languages.
 
Best,
Bogdan 

Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

cyber9270
In reply to this post by KHMan

A lua based firmware for wifi-soc esp8266
Features:
1. Arduino-like hardware IO
2. Nodejs style network API
3. Lowest cost WI-FI

Build on ESP8266 sdk 0.9.5
Lua core based on eLua project

fyr~
Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

BogdanM
On Sun, Jan 11, 2015 at 4:25 AM, Hori Liu <[hidden email]> wrote:

A lua based firmware for wifi-soc esp8266
Features:
1. Arduino-like hardware IO
2. Nodejs style network API
3. Lowest cost WI-FI

Build on ESP8266 sdk 0.9.5
Lua core based on eLua project

Yup, saw that, thanks. If the ESP8266 is a pure Hardware architecture though, vanilla Lua would've probably been a better choice, since all the memory optimizations that I did assume that the CPU can access data from code memory directly (this is a simplification, but illustrates the basic idea). I'll take a look at that when I have some time. I do like the node.js-like APIs quite a bit,

Beest,
Bogdan


fyr~

Reply | Threaded
Open this post in threaded view
|

Re: Finally a PIC32 with FPU for embedded Lua on MIPS

Tony Bauer
In reply to this post by KHMan


On Sat, Jan 10, 2015 at 9:59 AM, KHMan <[hidden email]> wrote:


If say a Lua scripted app is likely to hit the limits of a PIC32 with 512KB SRAM, then it would probably make more sense to use an SBC instead. A PIC32 with an FPU would make it easier for me to do calculations and drive a robot arm directly (and Lua scripting will make it much more fun) but I would find an SBC if I wanted to do robot vision. In short, pick parts based on a target application and not the other way round.

Today, a non-FPU PIC32 512KB SRAM is about USD10 for 10+ pieces. Looking at a nice Wikipedia page [1], I can dig a bit and find at Olimex an Allwinner A13 board for EUR18 (qty 1), it has 256MB DDR3 RAM. Both are very affordable.

So although it's possible to modify Lua for optimal SRAM/Flash utilization, I would just pick an SBC if an app is too big for a single IC. IC manufacturing advances wins again. :-)

[1] http://en.wikipedia.org/wiki/Comparison_of_single-board_computers


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


You bring up some interesting points.  The cost of high volume open source SBC's is pretty amazing.  For example, both boards John H mentions (espruino and micropython) are ~$40,while RPi's range from $20->$35, and the BeagleBone Black with 4G flash is $55 -- and you can run full Lua, Python, JS, etc on them.

On the flip side, if you want to connect with the real world, many low cost SBC (including the Allwinner and RPi) are sorely lacking (the BBB is the exception), and the software complexity is higher than say hacking with an Arduino.  Another disadvantage is the SBC form factor often won't fit into a custom product (unlike a single-chip MCU solution or using a SOM (system on module; typically priced higher than the SBC, e.g. RPi Compute Module is $40).

Tony