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

Pico-Perl

by rje (Deacon)
on Jul 12, 2005 at 22:30 UTC ( #474409=perlmeditation: print w/replies, xml ) Need Help??

Fellow Gentle Contemplators of Perl,

A co-worker and I were discussing microcontrollers, wireless automation, and BASIC. It seems as though many microcontrollers have a built-in BASIC interpreter, for those who don't like programming in assembly language, perhaps. There's even one that has a JVM.

We reasoned that it need not be hard to write some sort of barebones sub-Perl interpreter to use instead of BASIC. (In fact, if there are microcontrollers with embedded Linux, there might already be a Perl available in this area, eh?).

A simplified, Pico Perl, or subPerl, or Perl-- could be just the ticket: something which supports C-like control flow and provides the Three Data Types ($@%) would be a gigantic step forward from BASIC.

So, anyone know of anything like this? Of course, as I said earlier, if they've embedded Linux, perhaps Perl 5 is already available. Anyone know anything about that?

Or how about a Parrot embedded in a microcontroller?

Gratias a vos,

rje
j a p h

Replies are listed 'Best First'.
Re: Pico-Perl
by halley (Prior) on Jul 13, 2005 at 02:23 UTC
    You're referring to Parallax Inc's "BASIC Stamp" products. I'm not aware of any other embedded BASIC interpreter, though maybe they've licensed out their core. These have been around since 1994 at least. Very cool hobby/prototyping devices.

    Those who design circuitry must know every single bit which is allocated for every single purpose. Every state needs to be proofed, every branch of logic, every possible allocation of data must be predicted and reviewed. A worst-case must be known. All of this is because you really don't want to require a re-flash or replacement of the firmware. "Stateless transactions" is not just a goal, it's often a requirement.

    As "high level" as BASIC is, you can still budget every byte: DIM the arrays, can't swap integer i% and real types and s$ strings. Strings are arbitrary in length, but early versions limited you to a 255 byte length, and I think Parallax is even more stingy. I don't think an array of strings is possible or recommended, unless perhaps in ROM.

    The same limitations have been put into the PicoJava implementations. You can't just say Vector v = new Vector() whenever you feel like it. For solid designs, you need to know the world intimately, all the way down to each bytecode. At least the variable-sized automatic allocation stuff is mostly implemented in the class library: ditch those data structures classes, and you're almost back to a cannable language.

    Perl's scalars are oriented towards arbitrary sizes for different types, as well as arbitrary capacity for arrays and hashes. Arrays grow and shrink, and you don't even want to know the number of ways a hash's internals must be able to be resized. All of this is purposely hidden from your view of the developer. It's not even clear how you'd manage to handicap the Perl language to provide fixed-sizing on it, while keeping it valuable and high-level, since it's all in the language, not the class library. And though some people know the Perl bytecode and SV/HV data types, etc., it's far from the everyday Perl when you have to live or die by direct use of them.

    Just my feedback-- I'd like to hear others' take on it.

    --
    [ e d @ h a l l e y . c c ]

      I love microchip processors, grew up programming the 16C84 (which later became the 16F84).

      Their assembly is so easy to learn.. in fact the chip documentation has to be some of the best and most straightforward I've ever come across.. something which I would have liked to think contributed to their success.

      I can't ever imagine using BASIC on these processors though..

Re: Pico-Perl
by greenFox (Vicar) on Jul 13, 2005 at 01:50 UTC

    I don't know much about it but miniperl/microperl might be a possible starting point for you, there was an article by Simon Cozens about it in The Perl Journal titled "Microperl" (this issue), I think you can register to read that version or you can find it online elsewhere with google :)

    --
    Murray Barton
    Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho

Re: Pico-Perl
by samizdat (Vicar) on Jul 13, 2005 at 13:17 UTC
    The BASIC Stamp is only the latest. I was (un)fortunate enough to be required to use 8052AH-BASIC (Intel 8052 with BASIC in ROM) on an embedded project, and, of course, needed to have a judicious dose of assembly in the interrupts and several other routines as well.

    What Ed says is very true, although less so now. Most microcontroller work is really bit-specific, and for most of my career in embedded work, I never even bothered with C. Pure assembler is plenty, because you never have more overhead or syntax than you need. Nowdays, the chips that have grown up from micros, such as the ARM, XScale, AVR and whatnot, are both word-oriented and have much more available RAM. Much more often these days, one drops in a SBC with a whole PC or ARM, and one can expect to have a minimum of 64K and usually a gob of FLASH. Even the 8051 variants now have a gob of FLASH.

    All that said, I, too, would like to have something more than assembler. Something with the scheduler core of an OS, the stack handling and extensibility of FORTH, and built-in data types and I/O routines. Say what you will about BASIC, but PRINT is a heckofalot easier to grasp than:
    MOV DPTR, #MYSTRING PLOOP: MOVX A, @DPTR JZ DONE MOV #PPORT, A INC DPTR JMP PLOOP DONE:
    The catch to languages in micros is that languages are compiled with assumptions about hardware configuration. The only reason BASIC Stamps et al can exist is that they pretty much assume that certain hardware will always be available. In the AH BASIC, for example, the on-chip serial port was always the console. If you added another serial chip, you had to roll your own access routines.

    Should you decide to proceed, there are ways to target microcontroller targets with GCC. You need to really study the micro's architecture to configure your compiler, but it can be done.
Re: Pico-Perl
by Courage (Parson) on Jul 13, 2005 at 13:02 UTC
    from my own experience, a linux-enabled device not necessarily has perl.

    I have satellite receiver that is linux-enabled (kernel version is 2.6.9, processor is PowerPC) but it has no Perl.
    However, I copied binaries from elsewhere and perl was running just fine.

    OTOH perl supports cross-compiling of miniperl.

Re: Pico-Perl
by schweini (Friar) on Jul 13, 2005 at 20:14 UTC
    AFAIK, these embedded BASIC dialects are very reduced subsets of e.g. QuickBasic, so maybe it would be more feasible to program a simple perl-subset to basic-subset translator? if performace isn't THAT much of an issue (although it usually is, so assembly is the Right Thing in this case anyhow), i doubt that emulating hashes, etc. would be that hard in basic.
      When I was programming the 8052AH (as dwildesnl did), built up as much "HLL" on top of BASIC that I could, using things like awk and the m4 macro processor. (There was no Perl at that time.) It worked OK, but I always felt like I was using RATFOR rather than FORTRAN, or RPG rather than COBOL — i.e. a strange step-sister of a langauge.
        Wow, JD, I never thought of those (awk and m4), didn't have the 'NIX background then ('87). I was always more concerned with how fast I could get OUT of BASIC and into assembly so I could process the interrupts. My first exposure to the 8x51 was with the ancient Intel iPDS systems in '82, which were 8080A based and had plug in emulators (yes, I missed the ISIS frames with 8" floppies, but not by much. I saw them!). No 'NIX at all, just a monitor-like OS that was mostly a _subset_ of what later became DOS (if you can believe THAT!). They were kinda cute, actually were portable all-in-one boxes like the original KAYPROs and COMPAQs.

        I would be much more inclined to target the actual machine language, i.e., cross-compile with GCC. AH and Stamp BASIC are both so crude and so lacking in facilities to control the hardware features that it'd be a crime to write to the BASIC interpreters built in. An Intel '51 has a rich set of bit-oriented booleans that it's a crime to lose. Also, most of the newer 51-variants have lots of built-in peripherals (anybody ever work with the late much-lamented 87C452?) like A2D, high-speed timers, etc., that are the main reason for going with a micro.

        Most micro work involves developing a single application that will then be ROMmed (or at least EPROMmed). Thus, all development happens on the PC. Speed of compilation is mostly irrelevant, but flexibility of resource use and execution speed are EVERYTHING. All of these serial-console oriented BASIC chips that store your userland program in RAM are really just toys. The applications in the real world where they actually FIT are few and far between.

        One target more worth considering is the Cypress EzUSB 8051 variant. No BASIC, but it has a built-in bootstrap downloader and a full USB engine. Another possible target is the set of new FLASH-based micros with bootstrap downloaders. Some, especially the Dallas Semiconductor (now MAXIM) devices have lots of program storage headroom. Also, even though it is C-oriented, the RABBIT chip and its associated C compiler look really useful. Build your Perl interp in C and compile to the chip. Some of their boards have Ethernet and the Berkeley TCP/IP stack, also.

        In summary, there are two classes of what's called "embedded" computing these days. Single chip micros and small extended setups are usually so hardware dependent that making an interpretation layer is a mistake. Learn to make your chip dance in assembly! (It's FUN to make things go bump in the night!!!) The other class ranges from about 32K of (EP)ROM up to embedded SBCs, and there, the sky's the limit. When you get up into this class, look at the embedded 486 and ARM SBCs. With the high clock rates these have, you no longer have to give a damn about code speed or bit banging. You can then cross-compile PicoBSD AND PicoPerl and have at it!
      This is probably the easiest place to start. After all, we all know where print() came from...
Re: Pico-Perl
by kgraff (Monk) on Jul 14, 2005 at 15:42 UTC

    In 1994 I was called into a project for programming controllers because I knew BASIC. Things may have changed, but the commands were fairly rudimentary:

    ' Variables
    ' Analog Tattletale control
    AnalogRun$ = "\8\RUN" + CHR$(13)
    AnalogOn$ = "\8\GOTO200" + CHR$(13)
    AnalogOff$ = "\8\11" + CHR$(13)
    'AnalogPause$ = "\8\33" + CHR$(13)
    AnalogResume$ = "\8\99" + CHR$(13)
    

    We then sent these to the controller through a serial port. We ended up using QuickBASIC to write an interface for two controllers and ran it on a PC laptop. I think Perl would be an excellent tool to manipulate the strings sent to and from such a device.

    Of course, I may be totally off the mark too. 8^)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://474409]
Approved by itub
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2022-05-25 10:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (90 votes). Check out past polls.

    Notices?