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.
| [reply] |
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!
| [reply] |
This is probably the easiest place to start. After all, we all know where print() came from...
| [reply] |
