Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!

by ait (Friar)
on Feb 28, 2018 at 14:03 UTC ( #1210076=perlquestion: print w/replies, xml ) Need Help??
ait has asked for the wisdom of the Perl Monks concerning the following question:

Hey there Perl Monks,

I am honestly sick of seeing "Circuit Python" and Lua take over the microcontroller/embedded scene. I am not sure how to help but would be willing to put some time and effort into this.

All I am looking for in this thread is for brainstorming and references on this topic.

For example, how easily or how hard to created an OpenWRT MicroPerl package that can provide a basic and lightweight interpreter and a set of packages to do the most common tasks (Web server, Web Client, MQTT, etc.). How hard is that?

Who is willing to help make this happen? Maybe it's already happening and I just need to join that effort?

TIA,
Alex

P.S. I am already using Perl in OpenWRT (I refuse to use Python or Lua) although it's a pain in the ass given the curated selection of packages. Ideally, a single Circuit Perl package would be awesome, but perhaps this is not the right approach.

  • Comment on What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!

Replies are listed 'Best First'.
Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by Corion (Pope) on Feb 28, 2018 at 14:24 UTC

    The first thing I would look at is App::Staticperl, which mostly builds a Perl without dynamic module loading. Adding a selection of modules to that build should be fairly easy.

    Another approach would be to just build the miniperl from source and then use that. This gives you a minimal Perl without any loadable modules and wiull give you a lot of headaches once you want to add more modules that need a C compiler.

    I would at least talk to the people maintaining other Perl distributions to learn about their experiences with building and maintaining Perl binary distributions. For example the authors of Perl::Dist::Strawberry likely have experiences with how to add modules from CPAN into their build.

Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by stevieb (Abbot) on Feb 28, 2018 at 14:28 UTC

    I'm no authority, but I highly doubt that even the most trimmed down version of perl could "fit and run within just 256k of code space and 16k of RAM". I would stand corrected if it were possible.

    Not embedded, but for Raspberry Pi, we've got RPi::WiringPi (tutorial) and WiringPi::API, but that's not microcontroller.

    Personally, I sometimes do my microcontroller prototyping on a Linux box with Perl, then port it over to C/C++ when the code does what I want, but the whole point of using a microcontroller is to run extremely efficiently. Adding in a whole extra layer would slow things down at best, and add in an entire new software layer for things to go wrong at worst.

    I haven't heard of any ongoing projects like this, so I'm interested to see what other's takes are though...

      > I'm no authority, but I highly doubt that even the most trimmed down version of perl could "fit and run within just 256k of code space and 16k of RAM"

      Depends on how much trimmed down is still acceptable.

      Flavio Glock's perlito project is realizing a portable "subset of Perl" implementation which targets JavaScript, Perl 6 and Java engine.

      I don't see a reason yet why Lua couldn't be added.

      It's also unclear for me if the Perl compiler also needs to be fitted into the 256k.

      Executing a cross compiled OP tree (excluding all eval variants) might be sufficient.

      Cheers Rolf
      (addicted to the Perl Programming Language and ☆☆☆☆ :)
      Wikisyntax for the Monastery

      Sure, I get what you're saying. I am not thinking so much for 8 bit AVRs but rather in archs where you may have 2 chips (think Arduino Yśn that's why I mention OpenWRT) or in larger microcontrollers like ESP8266 which is where most of the Circuit Python is working right now AFAIK.

        I don't think "where Python is working".

        I've done my job.

        I don't believe that low-level hardware hackers need to think that hard core embedded stuff should be done with Python/Perl/whatever. If it isn't a micro-controller, its something more high-level, and I didn't think your question leveraged that.

        You may want to rephrase your question, as having extra power and double CPUs to make it 'capable' to run a high(er) level language makes things a microcontroller doesn't quite do that. Items that 'power up' to allow these higher level languages completely take away from their true purpose.

        A microcontroller is like a PLC (Programmable Logic Control)... sway from their basic purpose so they accept anything but basic commands, and you may as well have a full-blown computer :)

Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by LanX (Bishop) on Feb 28, 2018 at 14:23 UTC
    I would start by defining what "Micro Perl" or "Circuit Perl" is supposed to mean and which features need to be covered.

    Having to look up "Circuit Python" and "Lua" is of no big help other than promoting these projects.

    Maybe a question to facilitate the answer:

    If Micro Perl is just "a very basic Perl", what is then the difference to JavaScript with just a different parser on top?

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Wikisyntax for the Monastery

Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by afoken (Abbot) on Mar 03, 2018 at 16:15 UTC

    "Real programmers can write assembly code in any language."

    -- Larry Wall

    I write embedded code for a living, and because it can be fun. While I technically write in C, the way I write code is clearly affected by Perl. So far, C was sufficient for all projects. Yes, C has sove very nasty corners and edge cases, but so does Perl. You need to know them and the ways to write safe code. Yes, I would like to see some more features in C, but that won't happen any time soon.

    One of our next projects will have a way to run "programs" (note the quotes!) on a microcontroller system. We thought of having a small interpreter, but any interpreter would offer far too many features. After all, the "programs" are just sets of a few parameters that are played back in fixed order at run time. The user can adjust the parameters, and name those sets. Nothing more than an array of structs per program. No call, no goto, no if, no stack.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
      "...No call, no goto, no if, no stack."

      Hard life. Any example(s) available for further enlightenment?

      Best regards, Karl

      «The Crux of the Biscuit is the Apostrophe»

      perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

        Any example(s) available for further enlightenment?

        No, sorry. Confidential information.

        But if the device was a MIDI player, you could adjust playback speed, volume, pitch, and repeat count for each folder of MIDI files stored in ROM. "Programs" would be composed of the playback settings and a folder name. You could have a "program" named "sad" that plays one ROM folder slowly, in a low pitch and at a low volme. And a "program" named "happy" that plays the same folder much quicker, louder and faster.

        "...No call, no goto, no if, no stack."

        Hard life.

        Well, not for us. ;-) And to stay with the MIDI player example, you could select a folder of MIDI files to be played, but they would always be played in the same order.

        Yes, this looks crazy. But trust me, the device won't be a MIDI player. And when it is used as intended, those restrictions make perfectly sense.

        The users don't want to change the play order. Being able to modify the "playback" settings is sufficient for them. So they do not need call, goto, if or a stack.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by marto (Archbishop) on Mar 09, 2018 at 12:32 UTC

    A recent Rust internals post touches on their Embedded and Portability work groups, the goals (some common) each has. I don't know if p5p currently has something similar.

    Confusion arises when a vendor ships (or symlinks) something called perl which is different to what one would expect from a standard perl release, which tends to cause issues.

Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by wjw (Priest) on Mar 10, 2018 at 12:01 UTC

    First off, I like the idea of being able to write micro-controller code in Perl, or as is more likely, having my Perl code converted to the subset of C(++) that is then compiled and uploaded to whatever micro-controller I happen to be using.

    That said, and with the Yun being a retired product (and not so many affordable alternatives that I have found on the market), it may be a hard sell to get the time and effort put into something like this.

    I 'mess around' with various micro-controllers, mostly the Uno, Feather, Trinket Pro, and the radio (RFM) capable modules. From a cost perspective as well as a 'division of functionality' perspective, I have found that an RPi connected to a micro-controller via USB does a fine job.

    The RPi does the processing of incoming data, both receiving the data(Serial), processing it(using whatever I need from CPANm or whatever), and displaying it (apache2). This leaves all the more 'bloated' work to the RPi. The micro-processor just does what it is good at: and that is handle IO through the digital and analog ports, basic data manipulation(mostly math conversions like tempC to tempF or analog value to other measurement unit) along with some data organization such as formatting the output to JSON for transfer to the RPi.

    For the money, it seems the most reliable approach right now. I have at times added the web-server to an Uno or Mega which works fine, but find that the overhead is really not worth the effort. It cuts down on the real power of the micro-controller, which is in my mind its ability to gather a lot of data very fast.

    I really would like the ability to write Perl and have good controller code end up on the micro-controller. That would be a great advantage to me as I am no C(++) programmer. That tied in with the fact that the documentation of the libraries for some of the C code that has been written for the micro's just plain sucks, makes the idea of Perl for MC's really attractive.

    I am no C programmer, don't really understand compilers in any meaningful way either. So my 'picture' of this is something like

    • 'Perl->C->existing C compiler->micro-controller'.
    though the Arduino IDE. Not sure if that is what is being talked about here(sorry for my lack of in depth knowledge) but that seems to me like the most affordable approach based on the hardware available, the cost of that hardware, and the effort it would take to make Perl really usable as a language for micro's

    I should probably clarify here that I have avoided using the RPi as a micro-controller, though I know that is often done via GPIO etc... . This is again, because of my bias of 'division of function', where I think of the RPi as a nice Linux box and the micro as a pure data-acquisition and device/sensor controller.

    <Hope this is not too far off-topic...

    ...the majority is always wrong, and always the last to know about it...

    A solution is nothing more than a clearly stated problem...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1210076]
Approved by marto
Front-paged by marto
help
Chatterbox?
[marto]: good morning all
[LanX]: Btw no Dutch Perl Workshop in Utrecht
[LanX]: Arnheim rulez!
[LanX]: (3 provocations in 2 words xD )
[erix]: ahem, Arnhem
[karlgoethebier]: provocation in 2: market garden
LanX Hi hi hi
[erix]: german provocations seem visible to germans, I guess it's an improvement

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (11)
As of 2018-04-24 08:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?