BASIC-like Interpreter for Arduino

I started a BASIC-like interpreter for Arduino located here: https://github.com/Pualware/serialBasic.

The BASIC program is stored in EEPROM, and commands are accepted over the serial port.

Comments are appreciated.

Ultimately I want to create an OS that has a master atmega interacting with slaves over the I2C bus.

I will be making updates hopefully daily for awhile and if anyone would like to contribute an I2C device to the command set please let me know.

I try to use PSTR strings everywhere so that RAM is not used too much.

Have you seen bitlash?
You could be duplicating that.
http://bitlash.net/

Thank you for that link, I was not aware of bitlash, and this gives me an opportunity to clarify the intent of where I would like to go and highlight the difference between this and bitlash.

First of all bitlash is much farther along as an interpreter than mine will ever be. But I don't want to make a c compliant interpreter.

Rather than allowing people to store their c functions in eeprom rather than Flash (why?), I would like to create an intermediate language that bridges the gap between component complexity and language complexity. I'd like to make a dumber language with a smarter component interface.

I'd like to be able to build projects in this language that have a Master I2C component and n slave I2C components. Some kind of standard interface to the components would be created with hopefully wiring diagrams and maybe stackable shields. The intent would be to make something that could be appropriate for junior-high level students by hiding as much of the unnecessary complexity as possible.

The BASIC program is stored in EEPROM

A UNO has 1K of EEPROM. That severely limits the size of the program that can be created/uploaded/stored.

"The intent would be to make something that could be appropriate for junior-high level students by hiding as much of the unnecessary complexity as possible. "

Some questions:

You've got 2 wires, power, ground. Isn't that pretty non-complex already with I2C?

How are you going to get kids into hardware engineering if everything is turned into one software only effort?

1000 bytes of EEPROM will not severely limit the size of the program because the complexity is pushed to Flash. The commands themselves will be 1 byte each followed by n bytes of parameter.

There are a 100 reasons why students don’t make electronics. I think they can all be boiled to 4 main categories:

  1. I don’t know what to build
  2. Its too complex
  3. It doesn’t work
  4. Somebody else might “steal” my idea

Get rid of those 3 and electronics will be more “fun”, and that’s really what kids care about. So in response:
1=> This is our partly our responsibility to get the word out and show people what can be done.
2=> The language will be simple
3=> This will have to be watched carefully.
4=> Who cares. Shift to open source model. Make something cooler with more people watching quality above.

What do you think?

I am not sure what I think.

I see kids programming for FIRST Robotics competition in non-simplified language, and programming in drag/drop Lego programming.

I see kids who just want to slap something together quick and make a motor jump around, quickly losing interest because its not texting or graphics on a computer to poke & click.

I see the kids here in the forum putting in the effort to learn somewhat simplified C. The Arduino IDE C seems like fancier BASIC to me, but I've been exposed to a lot over the years.

I think interpretive programming could fit in there somewhere.

A friend wanted to set a relay when temperature of a pipe was around room temperature.
I added thermistor and relay (just digital output) to components, and uploaded to github https://github.com/Pualware/serialBasic
The EEPROM Basic-like “program” that runs on Arduino is just:

thermistor
ifA<80
relay3on
endif

The Arduino will be powered on a 24 hour automatic timer and run for 1 hour so a real time clock and loop is not necessary

(note from moderator - what showed up in e-mail notification is:

thermistor
ifA<80
relay3on
endif
ifA>90
relay3off
endif
wait10
jump1

)

Paulware:

if A<80

relay3on
endif

I’m not a big fan of trying to simplify things “to make it easier” because ultimately you have to learn more complex things.

For example, the above could be written in C as:

if (A < 80)
  relay3on ();

Is that so much harder to understand? I think not.

The trouble with simplified languages is that, although you may do simple programs marginally faster, once you have moved past that and want to do interrupts, timers, I2C, SPI etc. you then need to learn other stuff, and interface with your interpreted language.

Then the simplification works against you.

I remember when my dad showed me a FORTRAN program for the first time. I was 15or16 and couldn't make any sense out of it. I typed it in on the computer terminal and I think it displayed some error message. It was just gibberish to me. Hopefully a simple language like this might keep a student from turning away especially if there was something blinking or moving on the other side.

Yes, well the Blink example isn’t particularly hard to follow:

void setup() {                
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  pinMode(13, OUTPUT);     
}

void loop() {
  digitalWrite(13, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // set the LED off
  delay(1000);              // wait for a second
}

We had to do FORTRAN programming freshman year in college on punch cards, mostly for the experience of it. Would get back what seemed like totally unintelligible error messages back. Don't recall if girlfriend (now wife) had to do the same a couple years later, of if they had moved on by then. If they did, I would have helped her with it. Didn't see it again until FORTRAN-77 running on military program computers when I started work in 1985.

I agree with Nick tho - if you make it too simple it becomes to hard to do complicated stuff. We have Lego Mindstorm computers for the kids, I always found the drag & drop programming difficult to understand vs just typing out what I wanted it to do. Think that's part of the reason I never liked Apple/Mac's either - too used to having control under DOS and being able to do what I wanted. That and they bombed out with the little bomb icon and no chance to recover.

Created a video to demo some features http://www.youtube.com/watch?v=lPwVqcmw6bM&feature=plcp

No offence intended, but I think the two moderators are being a little hypocritical here. Was not the whole Arduino platform for which this forum is based on, built to SIMPLIFY the coding of AVR's?

Should the "simplification" stop here at what Arduino is now, and not go any further?

A professional AVR programmer would say the same about Arduino, as what the moderators are saying about "Paulware".

I think there is value in these smaller languages (it's why I wrote Bitlash), and I think they should be encouraged by the community.

While we're playing code golf, here's blink written in bitlash… small, forces a little thinking about the algorithm, and doesn't explicitly introduce delay() as a bad habit to break later:

function t13 {d13=!d13;}
function setup {pinmode(13,1); run t13,500;}

Let there be a thousand small languages.

-br http://bitlash.net

No offence intended, but I think the two moderators are being a little hypocritical here.

Perhaps. Maybe its just a point of view. For me, with a BSEE, it is oversimplified. For non-engineers, maybe not.

OZ_Willy: No offence intended, but I think the two moderators are being a little hypocritical here. Was not the whole Arduino platform for which this forum is based on, built to SIMPLIFY the coding of AVR's?

I don't believe I am being hypocritical. I think the whole IDE does an absolutely great job of simplifying coding for AVRs. With an easy-to-use interface you can be programming without Make files, complex linking, and needing to know a lot of detail.

Let me tell you a story ...

A little while back (couple of years) I had a PICAXE board. That used Basic rather than C. It was even simpler than C, right?

My son and I got some blinking lights going. Fine. So far so good. It went something like this (from here ).

 do
    high B.1    ; switch on output B.1
    pause 1000  ; wait 1 second
    low B.1     ; switch off output B.1
    pause 1000  ; wait 1 second
   loop            ; loop back to start

Now the equivalent code on the Arduino is:

void setup ()
  {
  pinMode (1, OUTPUT);
  }  // end of setup
void loop ()
  {
  digitalWrite (1, HIGH);
  delay (1000);
  digitalWrite (1, LOW);
  delay (1000);
  }  // end of loop

I seriously don't think that is much more complicated.

But anyway, back to the story ... Then we wanted to make a "morse code" player. We wanted to make some subroutines (that you called with "gosub") to play the beeps for each letter. Then we hit a snag.

We made a subroutine to play a dot. And one to play a dash. And then one for each letter (eg. gosub dot, gosub dash, gosub dot, etc.)

There is a limit on PICAXE of the total number of gosubs you can have in a program.

http://www.picaxe.com/BASIC-Commands/Program-Flow-Control/gosub/

In the case of our part (the PICAXE 08M) it was:

All 'M' parts (obsolete) number:15 1 nested:4

That is, you could have a maximum of 15 gosub statements in the entire program! Whether or not they were nested (if you nest them you can only nest 4 deep).

That's a pretty amazing limitation. It means you can use them for blinking lights and doing simple stuff, but when you want to do something semi-serious you can't - not easily. So, suddenly it is more complex. Because you are working around limitations in the "simpler" system.

PaulS:

The BASIC program is stored in EEPROM

A UNO has 1K of EEPROM. That severely limits the size of the program that can be created/uploaded/stored.

The good old days of the ZX81 (less the 16K wobbly RAM pack)

I understand where you're coming from, i started off programming in GFA BASIC - an old german written interpreter in BASIC ,i then graduated to Pascal (Object Pascal/Delphi) where I lived for a long time..

but...

Sometimes you have to accept 1 language does not fit/do all :) you'll pick up the language in no time.

cjdelphi: I understand where you're coming from, i started off programming in GFA BASIC - an old german written interpreter in BASIC ,i then graduated to Pascal (Object Pascal/Delphi) where I lived for a long time..

I also programmed using this and I consider GFA as my first decent structured basic. It was the first language I could use without the need of goto's and the ability to inline assembler code was very handy. I almost feel like digging my A4000 out of the cupboard and giving it a 'for old times sake' bootup.