It compiles!

With Alan's help managed to compile the 5139 tree under Eclipse. First thing after you download the last svn source is to download Jennic's "JN-RD-6004 Wireless" example and extract the Audiolib_JN5139R1.a file and copy it into ./rc24/rx24/source/
After that just import project & compile & download & solder & fly.

Thanks Alan

New Jennic Modules
I just noticed that Jennic have announced a new wireless processor JN5168 and modules. The modules are slightly smaller and will require pcb redesign I haven't found any for sale yet but when I do I'll give them a go. The processor is interesting as it is smaller and has built in flash so a much smaller rx should be possible if a custom board were made. There are also 5 hardware pwm outputs which has got me thinking about a board with 4 brushed motor outputs and gyro/accelerometer for a micro quadcopter

I never did finish this project, so I STILL have the bits left over including 3 modules, some pcbs and other sm parts.
Make me an offer to purchase ;-)

Texy

I have finally uploaded code to allow scripts to be run on either the receiver or the pc. On the receiver the script is run just before the servo outputs are sent, it could be used for all sorts of things. The script has access to any variables marked as 'routed' i.e. anything you can see from the pc interface can be scripted. Script on the pc can access the tx, rx and any sensors connected.

This video shows crude script running on the pc making the bottom half of a robot walk.

http://www.youtube.com/watch?feature...&v=oiiNwSm9mbY

I have also added code to access a mpu6050 gyro over i2c on the receiver.

Alan

Interesting - thanks
Mike

Some notes on rc24 scripting in lieu of proper documentation

The same script can be run on the pc or receiver and eventually the transmitter.
On the rx it can be used for things like flight stabilization or turning a speed command from the tx into synchronised moves of a robots leg joints.
e.g.
num main(TX tx, RX rx,IMU imu,Pilot pilot)
{
// limit servo output of channel 1

RX.setMixedDemands(1,limit(RX.getDemands(1),1000,3 000))
}


On the tx it will be used for mixing and doing stuff with telemetry data, e.g. making a variometer sound.
On the pc ( and hopefully,eventually, smart phone or raspberry pi ) It can do things like control the movement of a connected model or log sensor data.

The scripting language is compiled to byte code which then runs on a simple virtual machine.
It was done this way because on the tx or rx the script will be run repeatedly with limited resources so it makes sense to parse the script just once.

The script can be downloaded over the radio link or through a serial link, so in flight updating is possible if you are mad enough.

The virtual machine is designed to be small and fast and could be implemented easily on pretty much any 32bit c platform and probably on lower bit width devices with some effort.
I guess it would run easily on a DEVO tx.

The parser and compiler are small enough that compilation on the rx or tx should be possible if ported to c, they currently only exist in c# and java.
I'm not sure how useful this would be, but there is some attraction in storing source code where it is used so you could always edit whatever you left on the tx or rx 3 years before.

The basic syntax is rather like c,c#,java or javascript but with no semicolons at the end of statements.

I've tried to make a simple clean syntax whilst keeping the basics familiar.
Variables don't need to be pre declared and their type is inferred from their first use.

There are no control structures such as for loops or if statements, these are all replaced by allowing functions to accept blocks of code as parameters e.g.

int a=20;
while(a>1)
{
print(a);
a=a-1;
}

is achieved by

a=20
while(a>1,
print(a)
a=a-1
)


parameters are optionally named, so if you prefer you can write

while(test: a>10,
do:
print(a)
a=a-1
)

curly brackets {} are only used to define the body of a function.

functions can be defined to accept blocks of code, so new control structures ( closures ) can easily be created.

while, if,ifelse and for are just functions defined by default.

currently the only variable types supported are:-
num - a 32bit integer ( will probably rename to 'int')
code - a block of code with access to the variables of the function that it is defined in.
external routed objects - eg RX TX IMU Pilot

Priorities on the type wish list are a fast float library and strings and then some sort of local object or struct type.

External objects are currently passed to the script through the main function
e.g.
num main(TX tx, RX rx,IMU imu,Pilot pilot)
{
}
The properties of each of these objects are discovered at compile time by interrogating whatever is connected to the serial port.
This means that if you add extra exposed variables to the rx or tx bin files, they will be available in the script.

The compiler knows nothing special about the tx and rx, if you connect something else that uses the same protocol, it can be controlled from script.

Passing these external objects to the main function as parameters is a bit of a fix and means the have to be passed on to other sub functions that need them, the plan is to make them either global to the script or treat them as fields of the script object.

external object fields can be accessed with a dot and a get or set function
eg rx.setRXDemands(0,2000) sets the first element of the RXDemands array to 2000.

High on the todo list is to add array notation and remove the get set stuff so this will become

rx.RXDemands[0]=2000

On the receiver the script is called every 20ms just before the servo outputs are set. At some point I want to add an option for faster servo frame rates.
The c virtual machine is fairly well optimised but a faster one is in the pipeline. If speed becomes an issue, calls to native c functions are easily added for complex operations.

On the PC the code is just run on demand. The virtual machine on the pc was originally written just to make testing easier, the fact that it can be used to control connected stuff was an unplanned bonus! It was written to mimic the c code, so it looks a bit odd in c#.
It could be made far faster but the coms is so slow in comparison that speed is not a issue, this might change if I add access to pc features such as graphics and sound.

It is proving to be a good learning tool as my 7 year old son seems ok with the syntax and the results of code changes can be seen almost instantaneously on hitting the go button. I do need to improve the error reporting from the compiler though.

Alan

You have been a busy boy
Memories of a long ago Q&D script I wrote for debugging, which became a feature of the laser once I'd got it working,
It was written to allow detailed checks of asm code by simulating the hardware while running the code in a propriety PC based MPU simulator, in pseudo real time, Then more uses appeared !
Congratulations.

Mike
(Q&D == Quick and Dirty)

Originally Posted by Alan Hopper

Some notes on rc24 scripting in lieu of proper documentation

The same script can be run on the pc or receiver and eventually the transmitter.
On the rx it can be used for things like flight stabilization or turning a speed command from the tx into synchronised moves of a robots leg joints.
e.g.
num main(TX tx, RX rx,IMU imu,Pilot pilot)
{
// limit servo output of channel 1

RX.setMixedDemands(1,limit(RX.getDemands(1),1000,3 000))
}


On the tx it will be used for mixing and doing stuff with telemetry data, e.g. making a variometer sound.
On the pc ( and hopefully,eventually, smart phone or raspberry pi ) It can do things like control the movement of a connected model or log sensor data.

The scripting language is compiled to byte code which then runs on a simple virtual machine.
It was done this way because on the tx or rx the script will be run repeatedly with limited resources so it makes sense to parse the script just once.

The script can be downloaded over the radio link or through a serial link, so in flight updating is possible if you are mad enough.

The virtual machine is designed to be small and fast and could be implemented easily on pretty much any 32bit c platform and probably on lower bit width devices with some effort.
I guess it would run easily on a DEVO tx.

The parser and compiler are small enough that compilation on the rx or tx should be possible if ported to c, they currently only exist in c# and java.
I'm not sure how useful this would be, but there is some attraction in storing source code where it is used so you could always edit whatever you left on the tx or rx 3 years before.

The basic syntax is rather like c,c#,java or javascript but with no semicolons at the end of statements.

I've tried to make a simple clean syntax whilst keeping the basics familiar.
Variables don't need to be pre declared and their type is inferred from their first use.

There are no control structures such as for loops or if statements, these are all replaced by allowing functions to accept blocks of code as parameters e.g.

int a=20;
while(a>1)
{
print(a);
a=a-1;
}

is achieved by

a=20
while(a>1,
print(a)
a=a-1
)


parameters are optionally named, so if you prefer you can write

while(test: a>10,
do:
print(a)
a=a-1
)

curly brackets {} are only used to define the body of a function.

functions can be defined to accept blocks of code, so new control structures ( closures ) can easily be created.

while, if,ifelse and for are just functions defined by default.

currently the only variable types supported are:-
num - a 32bit integer ( will probably rename to 'int')
code - a block of code with access to the variables of the function that it is defined in.
external routed objects - eg RX TX IMU Pilot

Priorities on the type wish list are a fast float library and strings and then some sort of local object or struct type.

External objects are currently passed to the script through the main function
e.g.
num main(TX tx, RX rx,IMU imu,Pilot pilot)
{
}
The properties of each of these objects are discovered at compile time by interrogating whatever is connected to the serial port.
This means that if you add extra exposed variables to the rx or tx bin files, they will be available in the script.

The compiler knows nothing special about the tx and rx, if you connect something else that uses the same protocol, it can be controlled from script.

Passing these external objects to the main function as parameters is a bit of a fix and means the have to be passed on to other sub functions that need them, the plan is to make them either global to the script or treat them as fields of the script object.

external object fields can be accessed with a dot and a get or set function
eg rx.setRXDemands(0,2000) sets the first element of the RXDemands array to 2000.

High on the todo list is to add array notation and remove the get set stuff so this will become

rx.RXDemands[0]=2000

On the receiver the script is called every 20ms just before the servo outputs are set. At some point I want to add an option for faster servo frame rates.
The c virtual machine is fairly well optimised but a faster one is in the pipeline. If speed becomes an issue, calls to native c functions are easily added for complex operations.

On the PC the code is just run on demand. The virtual machine on the pc was originally written just to make testing easier, the fact that it can be used to control connected stuff was an unplanned bonus! It was written to mimic the c code, so it looks a bit odd in c#.
It could be made far faster but the coms is so slow in comparison that speed is not a issue, this might change if I add access to pc features such as graphics and sound.

It is proving to be a good learning tool as my 7 year old son seems ok with the syntax and the results of code changes can be seen almost instantaneously on hitting the go button. I do need to improve the error reporting from the compiler though.

Alan

I've just uploaded some improvements to the scripting.

Array and property syntax now works so setting a channel value is now cleaner

tx.TXInputs[2]=2000

string constants can be used and function overloading now works so
print(23) and print("hello") now works

I've added speech output on the pc ( at the demand of the project director, my son)

say("speed is")
say(123)

The rx now has some extra properties

rx.frameCounter - can be used as a clock
eg. rx.RXMixedDemands[5]=abs(rx.frameCounter%80-40)*40
will scan a servo from side to side

rx.missedFrames contains how many frames ago data was received so can be used to do clever failsafe code

pilot.vars[0..39] is a array that can be used to store stuff between frames

Originally Posted by empeabee

You have been a busy boy
Memories of a long ago Q&D script I wrote for debugging, which became a feature of the laser once I'd got it working,
It was written to allow detailed checks of asm code by simulating the hardware while running the code in a propriety PC based MPU simulator, in pseudo real time, Then more uses appeared !
Congratulations.

Mike
(Q&D == Quick and Dirty)

Thanks Mike, I find it very addictive and keep having to remind myself to keep it small and simple and not try and grow it into lua or python!

Alan

Aaaha - WIBNI rules ok
When someone says Wouldn't It Be Nice If it did this that and/or t'other, think about the minimum system requirements of Windows, which grew out of a DIY dos for an little known cludge up on a failed pocket calculator chip ((((two 4040's glued together --> 8080)*2 -> 8086)*2 -> 486)*2 -> pentium ) ad nausium onwards and upwards but don't look down, it will make you dizzy.
Mike