|
Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by Corion (Patriarch) 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.
| [reply]
[d/l] |
Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by stevieb (Canon) 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...
| [reply] |
|
|
| [reply] |
|
|
> 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.
| [reply] |
|
|
| [reply] |
|
|
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 :)
| [reply] |
Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by LanX (Saint) 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?
| [reply] |
Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by afoken (Chancellor) 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". ;-)
| [reply]
[d/l]
[select] |
|
|
| [reply]
[d/l] |
|
|
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". ;-)
| [reply]
[d/l]
[select] |
|
|
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'sI 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...
| [reply] |
|
|
Thanks for your comprehensive response!
BTW there is a new Yśn which just came out. I think this will wind up being the best approach to IoT stuff. In other words the two-tiered approach with a WiFi chip running OWRT and an AVR running the actual control with a bridge between them just like the Yun has.
I guess what I would love to see stripped down, lightweight Perl at the OpenWRT level for HTML-based UI development and MQTT and stuff like that. Some simple, fast, lightweight Perl combo that has some Web-UI development stuff and MTTQ stack too, plus some common crypto stuff.
Also your approach using rbpi and an avr via serial is great too. But I think that the two tiered approach using owrt and the avr on the same board is awesome.
| [reply] |
|
|
I just finished writing a single-file HTTP server with literally 1 required dependency (IO::Socket), running on the very resource constrained Atheros chip with OpenWRT on an Arduino Yłn (second generation) win under 200 lines of code. I would say that pretty much beats Python and Node.js by a wide margin, and the code is so elegant and slick. Well, of course, it's Perl ;-)
| [reply] |
Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by marto (Cardinal) 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.
| [reply] |
Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by TheloniusMonk (Sexton) on Aug 30, 2018 at 11:43 UTC
|
The problem is that embedded things have to be built in a different environment than where they will be used. Even microperl seems to be configured with the opposite expectation (build here to use here). So if microperl is to become embedded, that seems to be the first hurdle to jump. | [reply] |
|
|
For microperl for sure, and the other issue is memory fragmentation. But right now I think that Perl 5 is a great alternative at the intermediate embedded level and that's where I'm focusing right now: for example, the Linux side of an Arduino Yłn or on a Raspberry PI. I think that is not too much work to create some light weight packages that are targeted to these architectures and to help maintain some of the existing Perl distributions on those platforms (e.g. the perlbase packages on OpenWRT).
I think that to revive attention on Perl and gain some traction, is to provide simple solutions for hacking in the Maker's ecosystems. We found for example, that if you want to hack a simple microservice on OpenWRT you'd have to spend a lot of time studying Luci and learning LUA, or use Node.js perhaps. But both these approaches require a steep learning curve, are resource hungry, and mostly overkill for the Maker's mentality. People on these platforms want simple and light weight stuff with very few dependencies. I think that Perl 5 can fill this gap so this single file HTTP server was our first step in this direction. I think we may publish on the CPAN and perlbase packages on OpenWRT. We will also spend some time porting Mojolicious to OpenWRT for those Makers that outgrow our one script server.
Think about why Arduino is so popular? It's because it's easy, fun and simple to work with and experience in minutes. These are the same attributes that made Perl popular on the Web to begin with.
But in the Arduino Yłn for example, all your are left with on the Linux side is Python and LUA. I think that we have a good chance of reviving interest in Perl for the Yłn crowd and the larger OpenWRT ecosystem first, and then take it from there into more and more Maker spaces.
| [reply] |
|
|
You'd need to package a memory manager for the fragmented memory issue. But any embedded system has to have memory management delivered with it - it needs in fact a dedicated super-simple ultra-lite OS packaged in. An embedded distro is self-contained for empty hardware as if straight off the presses.
| [reply] |
Re: What do we have to do to resuscitate micro Perl? I want Circuit Perl NOW!
by rje (Deacon) on Mar 26, 2019 at 21:12 UTC
|
Late to this party, but:
How about forking Perl 2, modding it (and perhaps modernizing some of the C source) as needed, and calling it "CircuitPerl"?
| [reply] |
|
|
| [reply] |
|
|
Why Perl 2 in particular? Where are these sources kept? I tried finding the source with no luck.
It's all in the same repository.
I also tried building Microperl in 5.30 and it doesn't build on my Mac.
Microperl has been broken for quite a while, IIRC sometime since like 5.12-5.16. perl5180delta says "microperl, long broken and of unclear present purpose, will be removed."
| [reply]
[d/l] |
|
|
|
|
|
|
