AVR Freaks

Have you looked at things like Scratch? This generates a bytecode that is simple to implement. It is a bit like Basic Stamp - the user interface is on a PC and downloads the ‘compiled’ bytecode for execution.

Interesting project.

 

If the program runs on the micro, what stores the program so the user can re-run it without retyping it in?

 

You likely are aware of both Bascom and ZBasic, both of which have commercial license options.

(And both of which have a compiled version, while ZBasic original Z-chips ran an on chip interpreter, IIRC.)

 

I'm not sure why the language needs to be extensible?

I'd have thought that the core instructions would be sufficient for handling simple I/O logic as you mentioned above.

As new HLL instructions are added to Basic it is usually to simplify something like an interface to a WiFi chip, or a digital LED, etc.

Not likely a requirement for your project.

 

I'd have thought your approach might be to define a list of I/O pins, and type, (digital, analog, etc.).

Define a few PWM channels, and some standard modules, (LEDs, LCD, input switches, etc.).

 

You then define a list of instructions, (an example of which you gave above).

The User is merely filling in the blanks on the standard equations available.

 

The micro is actually running its own program, (written in any language), to parse the "program", (list of instructions), provided by the end user, and perform their action.

 

The program running on the micro is essentially a big parser, except you know ahead of time the list of options for the commands, so it is much easier than parsing random language or math equations.

 

You would have a menu / "IDE" for the console, running from the micro, which included "Save" to a microSD card, EEPROM, or whatever.

 

So in essence, you would be writing your own language I guess, with some similarities to the Arduino setup.

 

Also some similarities to a CNC machine interface.

 

JC

 

 

I think a large part of any interpreter is the tokenization.  It seems that it would make more sense if that part were on the PC end of things (though I do see the benefit of having it on the AVR side).  If on the AVR side you would at least benefit from having very rigid and restricted variable and keyword naming conventions, nesting depth, allowed operators, etc. 

 

"I can find plenty of 'tiny-basic' clones, lots of abandonware and lots written in assembly. But nothing fit for a commercial product."

 

I humbly suggest that take these half-baked and nearly-useless code items and turn them into your own commercial product.

 

 

"IF (digi-input4 = HIGH) AND (ana_input7 > 100) THEN digi-output3 = ON"

 

I suggest that result of rewriting and rearranging of the above code clones and junkware  be limited to a tiny number of keywords and variables.  In the line above, (which, if interpreted, would not use any resources that are not in the line of code) there are two GPIO boolean variables, one (I assume) 16-bit variable, five keywords  (if,=,and,>,then), and two pre-defined logic states(HIGH, ON).   I assume that boolean variables are getting their values from sensors.  The integer value comes from either an serial terminal input (the input value in ASCII representation), or, from an analog-to-digital convertor.  

  Try the simplest possible approach by having no more than, say, eight keywords, 3 or 4 boolean variables, and 1 or 2 integer variables.  Input a text line and parse it into keywords and variables, then use the techniques described in the junkware.

 

I,too, once studied FORTH.  With all respect, FORTH is a disaster of programming language.   It is like Esperanto: a perfectly designed language that too much of a pain in the poot to be taken seriously and used by anyone.  Except for the (very few) people who could learn it.   In the early 1980s, FORTH was the only advanced language available for one of the new "home computers"; the Commodore VIC-20.  And only available on ROM cartridge.  And only where game cartridges were sold.  Which was in toy stores.  So, to get your advanced computer language, you had to go to Toys'R'Us and browse through all the dolls and plastic children's toys to find your advanced computer operating system.   Which could be hard to find in the store.  And the sales clerk won't be much help when you asked if they carried FORTH, an advanced computer operating system.  I showed my first FORTH program to the other programming students in the community college engineering school that I went to then, and they all agreed that it was the product of a sick mind.

If using BASIC is not an absolute requirement, then looking at Lua may be worthwhile.

I've not used it myself but know that it's added quite often to 3D games, for example,

as an extension language.

 

--Mike

 

I forgot to say, the compiler was on PC.

The device had only a loader on the serial port (kind of bootloader) to get the byte code and store it in the eeprom.

But the compiler was very simple, a command line .exe (a plain C application (mingw))

We planned to put that C application inside the microcontroller but never did that...

There was two ways of thinking:

- some thought that having a better PC/host program was the best, a program having some debug facilities too

- some thought that having the compiler inside the device was best. Here there was a problem: was the text source needed to be stored too inside the device or not? Having the text at hand was nice if we decide to develop a embedded debugger too, but the real hardware didn't support that (we didn't have an external eeprom/serial flash).

 

Exactly what would make such a thing "fit for a commercial product"?

Ah.  If I might answer my own question, in perhaps a interesting way:

 

A "suitable commercial SW product" essentially "crowd-sources" the development and support costs of software.  Instead of paying big bucks (internally or otherwise) to someone to develop the SW, and more big (and unpredictable) bucks for a consultant to fix anything that goes wrong, you want to have a predictable and much lower cost (license fees, or a "subscription") to someone who is hopefully collecting those fees from a number of customers, enough to do "continuous" fixes and development.  Sort of the RMS model of Open Source, without needing to be "Open."

I would be very surprised if there isn't a BASIC written in pure C. (probably made to show what you can make in C, I kind to remember that there was a book how to make interpreters. )

And when you have that it should be easy to add things.

And the benefit with C and not ASM is that you will get FP etc. for free.    

 

Add:

And today it's not a problem if the interpreter take up 16K flash, for most chips it would be the amount of RAM that would set the limit.

I would go for a mega1284 mostly because I have one but the 16 KRAM is nice.

My first computer had 7168 bytes free for basic as I remember. (PET) and that could hold a lot. 

So do we take that 8~12k as the maximum available code load added ?

What about RAM ?

What about Debug using  such a feature ? - you could  ask a better question of the one asking you 'how easy' is hack and hope ok to them ?

 

 

Mandating C seems a little strange, ok for some 'nice to have' tickbox but the cornerstone need here, seems to be able to link with the build of you 'industrial controller unit'

 

ie abandonware is ok if the source is clearly coded ad commented

The IL (instruction list) example given in #22 looks a good start, because it uses an industry standard 

 

 

Wow, so you expect those PC/Mac/Linux users to be ok to write low level PLC code, but not ok to install or run any software ?

 

The Debug/Development angle that was totally skipped over in #1,  looks to be well supported by the links in #24, but the base hardware they target in

https://openplc.discussion.commu...

is a 'TrimPI', so their firmware overhead is not really sounding anywhere near that 8k Binary

 http://wiki.friendlyarm.com/wiki...

Of course, that compact module with Ethernet, might just be small/cheap enough to include as a plug-in revision to your 'industrial controller unit'

 

Hehe, yes, meanwhile  I was musing on other pathways using this "but the cornerstone need here, seems to be able to link with the build of your 'industrial controller unit'"

 

So I took this command line 

 

fbc.exe" -g -gen gcc -r -v Test.bas

 

to compile this snippet

 

Function RdCNT()  As uinteger

  return CUint(Timer/tP1_CLK)

end function

 

Sub WAITCNT (WaitForwardValue As uinteger)

  VAR SleepRounded = ((WaitForwardValue-RdCNT())/t1ms)-21   ' 20ms OK, Experimental trim-down, need finite loops 16,18ms fail 19ms is marginal, choose 21ms - test on other PC's ?

  if SleepRounded >= 0 then 

    Sleep(SleepRounded)  'round down, so most of time is Sleep, 

  end if  

  Var AbsDiff = ABS(WaitForwardValue-RdCNT() )     ' 99% of time this is small, but in rare cases, RdCNT will be MAX, and WaitForwardValue will have wrapped 

  PollCheck = 0

  StartD = Timer()

  While AbsDiff >= ABS(WaitForwardValue-RdCNT() )  ' look for reversal of setpoint diff, diff decreases until it hits match, then starts to increase.

   AbsDiff = ABS(WaitForwardValue-RdCNT() )

   PollCheck = PollCheck + 1

  wend 

  EndD = Timer()

end Sub

 

creates :

 

 

static uint32 POLLCHECK$

 

void __stdcall fb_End( int32 );

double __stdcall fb_Timer( void );

void __stdcall fb_Sleep( int32 );

 

 

uint32 __stdcall RDCNT( void )

#line 134 "Test.bas"

{

#line 134 "Test.bas"

uint32 fb$result$1;

#line 134 "Test.bas"

__builtin_memset( &fb$result$1, 0, 4 );

#line 134 "Test.bas"

label$65:;

// return CUint(Timer/tP1_CLK)

#line 135 "Test.bas"

double vr$1 = fb_Timer(  );

#line 135 "Test.bas"

fb$result$1 = (uint32)fb_D2L( vr$1 / 0x1.AD7F29ABCAF48p-27 );

#line 135 "Test.bas"

goto label$66;

#line 136 "Test.bas"

label$66:;

#line 136 "Test.bas"

return fb$result$1;

#line 136 "Test.bas"

}

#line 138 "Test.bas"

void __stdcall WAITCNT( uint32 WAITFORWARDVALUE$1 )

#line 138 "Test.bas"

{

#line 138 "Test.bas"

label$67:;

// VAR SleepRounded = ((WaitForwardValue-RdCNT())/t1ms)-21 

#line 139 "Test.bas"

double SLEEPROUNDED$1;

#line 139 "Test.bas"

uint32 vr$0 = RDCNT(  );

#line 139 "Test.bas"

SLEEPROUNDED$1 = ((double)(WAITFORWARDVALUE$1 - vr$0) / 0x1.388p+16) + -0x1.5p+4;

// if SleepRounded >= 0 then

#line 140 "Test.bas"

if( SLEEPROUNDED$1 < 0x0p+0 ) goto label$70;

{

// Sleep(SleepRounded)  

#line 141 "Test.bas"

fb_Sleep( fb_D2I( SLEEPROUNDED$1 ) );

// end if

}

#line 142 "Test.bas"

label$70:;

#line 142 "Test.bas"

label$69:;

// Var AbsDiff = ABS(WaitForwardValue-RdCNT() )    

#line 143 "Test.bas"

uint32 ABSDIFF$1;

#line 143 "Test.bas"

uint32 vr$6 = RDCNT(  );

#line 143 "Test.bas"

ABSDIFF$1 = __builtin_abs( (WAITFORWARDVALUE$1 - vr$6) );

// PollCheck = 0

#line 144 "Test.bas"

POLLCHECK$ = 0u;

// StartD = Timer()

#line 145 "Test.bas"

double vr$9 = fb_Timer(  );

#line 145 "Test.bas"

STARTD$ = vr$9;

// While AbsDiff >= ABS(WaitForwardValue-RdCNT() )  

#line 146 "Test.bas"

label$71:;

#line 146 "Test.bas"

uint32 vr$10 = RDCNT(  );

#line 146 "Test.bas"

if( ABSDIFF$1 < __builtin_abs( (WAITFORWARDVALUE$1 - vr$10) ) ) goto label$72;

{

// AbsDiff = ABS(WaitForwardValue-RdCNT() )

#line 147 "Test.bas"

uint32 vr$13 = RDCNT(  );

#line 147 "Test.bas"

ABSDIFF$1 = __builtin_abs( (WAITFORWARDVALUE$1 - vr$13) );

// PollCheck = PollCheck + 1

#line 148 "Test.bas"

POLLCHECK$ = POLLCHECK$ + 1u;

// wend

}

#line 149 "Test.bas"

goto label$71;

#line 149 "Test.bas"

label$72:;

// EndD = Timer()

#line 150 "Test.bas"

double vr$17 = fb_Timer(  );

#line 150 "Test.bas"

ENDD$ = vr$17;

#line 151 "Test.bas"

label$68:;

#line 151 "Test.bas"

}

 

..

// Var LoopC = 0

#line 122 "COM4_Test.bas"

int32 LOOPC$0;

#line 122 "COM4_Test.bas"

LOOPC$0 = 0;

// WHILE LoopC < 60

label$63:;

if( LOOPC$0 >= 60 ) goto label$64;

{

LOOPC$0 = LOOPC$0 + 1;

// WEND

}

goto label$63;

label$64:;

 

Looks like a coarse skeleton is there, but default types may be an issue, and it may be better to give them compatible subroutines like the Scaled timer here, that a simple dictionary table script 

With an example framework that shows what your system does support, maybe something usable could be crafted ?

 

A benefit of their c generated code, is you could debug the whole linked binary in Atmel Studio. (once it all finally compiled and linked  ;) ) 

 

LoopC looks portable, but PollCheck is declared Shared in FreeBASIC, so seems to have different declaration.  Maybe that's fine in GCC ?

 

...and I checked other type-casts, with 'interesting results'. Looks like they expect a native UInt32 Mathops target, so whilst the VAR declaration is  precise, the generated code is not going to be compact of fast ?

Or you just use a rule, like let them have a few 32b variables ?

 

// Var Loop8u = Cast(UBYTE, 0)

uint8 LOOP8U$0;

LOOP8U$0 = (uint8)0u;

// WHILE Loop8u < 60

label$65:;

if( (int32)LOOP8U$0 >= 60 ) goto label$66;

{

// Loop8u = Loop8u +1

LOOP8U$0 = (uint8)((int32)LOOP8U$0 + 1);

// WEND

}

goto label$65;

label$66:;

// Var Loop16u = Cast(USHORT, 0)

uint16 LOOP16U$0;

LOOP16U$0 = (uint16)0u;

// WHILE Loop16u < 60

label$67:;

if( (int32)LOOP16U$0 >= 60 ) goto label$68;

{

// Loop16u = Loop16u +1

LOOP16U$0 = (uint16)((int32)LOOP16U$0 + 1);

// WEND

}

goto label$67;

label$68:;

 

 

// Var Loop16i = Cast(SHORT, 0)

int16 LOOP16I$0;

LOOP16I$0 = (int16)0;

// WHILE Loop16i < 60

label$69:;

if( (int32)LOOP16I$0 >= 60 ) goto label$70;

{

// Loop16i = Loop16i +1

LOOP16I$0 = (int16)((int32)LOOP16I$0 + 1);

// WEND

}

goto label$69;

label$70:;

The first Arduino is the ‘master’. Oh, my!