A different idea relating to scripting (not LUA)

openTx has introduced a range of new features, ideas and bling. It is fast becoming the firmware of choice for many users. openTx will run on ALL current hardware platforms, including the gruvin9x and sky9x boards. Work has already started to support the new FrSky X9D radio!
nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Fri Apr 25, 2014 8:52 am

I'll put together another archive of opentx firmware, editor and example script tomorrow. The stuff I've included here doesn't have much support.
I've had a few more ideas on how the scripts could run. One thing I'd like to implement is a way for the scripts to terminate themselves once a particular condition is met. They could then perform a task (e.g. add a mixer) and then terminate. At the moment, the loaded script runs forever.


nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Fri Apr 25, 2014 10:04 am

OK, another archive of the latest work. The OpenTX firmware is (still) based upon 'master' branch, so don't forget to save data if changing versions. The file 1.ddc just has a simple script to play /SOUNDS/en/system/0000.wav when the script is loaded. countdown.ddc (needs to be named to /ddc/1.ddc on the SD card before it will run) will start counting down from 32 seconds when SW A is UP. You should hear it count down the time left at 30, 20, 15, 10...1 seconds while SW A is left up. Moving SW A stops the countdown. The archive contains 64bit and 32bit linux versions of the editor. Note that there are more objects available than is visible in the pop up window. Just scroll down to see the others appear. The .txt files need to be in the same directory as the editor executable.
Remember that this is all new and pretty much untested, so don't be surprised if you find a bug.
example editor command: ./dedit -f countdown.ddc -o edit
Attachments
ddc-25-4.tar.gz
(191.9 KiB) Downloaded 117 times

mstrens
Posts: 1366
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by mstrens » Fri Apr 25, 2014 3:03 pm

Nischris,
Thanks for sharing your work.

I am interested in your development because it add some more flexibility to openTx.
Still I have not yet 100% understood how it works.
I am running Win 7 64.
I installed all files from your original post in a directory.
I added all dll you provided in other posts.
I open a command shell and key in : dedit -f 1.ddc -o edit

I get then the message
operation: edit
Error opening terminal: cygwin

I am currently trying to install Cygwin but it takes a long time.
When it is finished, I will try again.

I still already have some questions:
- in your example 1.ddc from your original post and looking at the pdf, it is not clear for me if for one set of positions of the pots, the prog will generated several beeps or only one.
Which modification must be made in the program to switch from one logic to the other. It is not to difficult?
- is it possible to implement some kind of "if then else" and "loop (while- until)" in your logic
- is it possible to implement some kind of "function" (defined once but called from several places)
- is it possible to implement the editor in openTx itself (adding a new menu similar to customs function)

As alternative, did you had a look to other solutions?
I think e.g. at:
- picoc (a mini C interpreter)
- implementing an interpreter for a language like IL (Instructions list) or ST (Structured Text) that are used in automatisation project.
I presume that such interpreters would integrate well in C and offer enough power for openTx.

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Fri Apr 25, 2014 7:24 pm

Hi mstrens
I've attached the latest editor built for win64 (it needs to be updated whenever support for new objects is added) so that you can see/edit the latest ddc files on your win64 machine. Not sure if you will need to include ncurses as you already have those dlls. Not certain how all that stuff works. Anyway.
The idea behind that example script is this:
for a given position of the RHS pot, the Taranis will beep (once) as the LHS pot is moved to positions above where the RHS pot is positioned. I don't have the picture in front of me, but I think the idea is that it will beep when the LHS pot is same as RHS pot, and at positions 10,20,30,40% to the right of the position of the RHS pot. The Taranis will not beep as the LHS pot is moved to the left passed those same positions.
If you wanted to change that logic so that for a given POT position, the Taranis beeped multiple times, that would require some extra timers to make the beeps occur at the correct time, and some logic to start the timers. Not too difficult if you know what you're doing. ;)
The if-else question:
The short answer is 'yes', but it pays not to think like you're about to write code for your usual programming language like C/LUA/BASIC etc (with while loops, if-else, that sort of thing). If you had an operation that needed to occur when certain conditions were met, you would use the appropriate logic blocks (or,and,xor,comparator,timers etc) whose output would turn ON when the conditions were met. If you wanted somethng else to happen as long as those conditions were NOT met, then you could use a NOT object connected to the output of that same logic, which would be ON when the conditions were not met.
As for 'while' loops, you have to imagine in your mind that _all_ of the DDC is executed one object block at a time at regular intervals (~10ms at the moment). The processor starts with the first object in sequence, and steps through the objects executing each one in turn. So no, there is no while loop.
The function question:
Again, don't think like you're about to write code for a regular language. The short answer is no, but that is only because support for that sort of thing hasn't been invented yet. If there was some logic that needed to be repeated for multiple IO, there is no reason why some sort of subroutine functionality couldn't be built in. There would be a logic block that took all of the input IO and output IO and a position to jump to. Once completed processing ddc at that new sequence, the processor would jump back to the original DDC, write the outputs to the defined IO and continue on. That is the sort of functionality that can be added in afterwards. I'm not sure there would be a great need for on the Taranis either. If you're thinking about using the function call in something like a loop (e.g. while something != something else call function()) then you're still approaching things the wrong way. In DDC you would achieve the same thing other ways.

An editor on the TX itself?
I've been thinking al little bit about that. I think that it might be possible to come up with something, but (because the LCD screen isn't that large), I'm thinking that you would only get one object on the display at any one time, so you wouldn't be able to get a visual representation of the complete DDC. So yes, I think there is scope for including some kind of editor. Reasonable amount of work involved in doing that though, and might be an issue for devices that are a bit short on FLASH.
There is currently no text editor for LUA on the Taranis either (do you really need one?). I wonder which one would be easier to implement.
One thing I thought might be quite handy is to show the 'live' IO values for a specific logic block on the display as the DDC is running. That might help give clues as to why the DDC is (or isn't) doing what is expected of it.

Other solutions:
No, I haven't looked at anything else at all.

Hope that answers some of your questions.
Attachments
dedit-win64-26-4.zip
(14.67 KiB) Downloaded 40 times

User avatar
tilmanb
Posts: 347
Joined: Thu Oct 11, 2012 9:36 pm
Country: Germany
Location: Karlsruhe, Germany

Re: A different idea relating to scripting (not LUA)

Post by tilmanb » Fri Apr 25, 2014 7:26 pm

This is going to be a 1% solution. But I love it.


nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Fri Apr 25, 2014 7:38 pm

I think that one great advantage that the scripting languages have over this 'DDC' (I might need to call it something else as that is the name given to it by the company that (I think) invented it) is that you can look at great chunks of the program on the screen using a simple text editor. With this DDC, it's pretty difficult to look at the objects one object at a time and understand how the DDC will operate. To get a decent picture of how it works, you need to draw the program out on a bit of paper or something. And then, if you change the program, your picture is already out of date. Once you have the picture though, I find that it's usually pretty easy to figure out how it works. Imagine a picture with lots of ORs and ANDs, delay-on-make timers and things. To me that is easy to follow.
1% solution? Hmm, I think I can understand why.

mstrens
Posts: 1366
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by mstrens » Fri Apr 25, 2014 8:42 pm

nischris,
thanks for the explanation.
Now I understand a little better how it works.
After installing cygwin I am now able to run you dedit program and to analyse the ddc files you provided.

Still, having experience only with languages like C, basic, javascript,... it is not so easy for me to see how to program quite complex algorithm with DDC logic.

I ask myself if it is easier to create a simple language with just a few basic instructions (ADD, SUB, MUX, <,> , ...), 2 structures ( if then else / while) and the ability to call functions (that would be predifined in C) allowing to pass/get parameters.
If the number of instructions and functions are limited, it would be possible to edit the program to be run on the TX with an editor like the one you made based mainly on drop lists. The editor could then create a program that would be run by a kind of virtual machine on the Tx side. The virtual machine could be very simple because (nearly) all checks would already be performed by the editor when it generates the code to be run on the virtual machine.

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Fri Apr 25, 2014 8:57 pm

Glad you're able to run the program. :) Sad that the example DDC seems complex. :(
Of course there would be a learning curve if it is something you haven't experienced before. I find that once the penny drops as to how to approach things the DDC way, people find it very easy to understand. Again, I understand that it's not always easy to follow the logic when viewing it one object at a time within the editor. It is often best to draw the logic on a piece of paper.
It's also helpful to have a go at making some of your own code.

If you think it might be easier to come up with another language, have a go! :). I only started having fun with this because I thought there might be some significant advantages over using an interpreted language like LUA.

User avatar
Kilrah
Posts: 10416
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: A different idea relating to scripting (not LUA)

Post by Kilrah » Fri Apr 25, 2014 9:30 pm

I think there are some "simplified" programming methodologies that work fine for novices to get into it quickly, but once you're trained to "conventional" methods with a higher level of control just don't go through anymore.

I remember getting some course on programmable logic controllers, for guys who didn't really have any programming experience it wasn't much of a problem, they just needed "normal" training. For us who had experience in "common" sequential programming languages where you have exact control of the order things were done that cycle-based, concurrent-within-a-cycle approach where you can't really decide or know in what order things are done was very weird and kind of needed an "unlearning" period before we could join the others. We'd see straight away how to program the assignment in C in a few minutes, but it was a huge pain to try and do it in that totally different state-based way.

User avatar
tilmanb
Posts: 347
Joined: Thu Oct 11, 2012 9:36 pm
Country: Germany
Location: Karlsruhe, Germany

Re: A different idea relating to scripting (not LUA)

Post by tilmanb » Fri Apr 25, 2014 9:45 pm

Agree with that. I never got my head around those industrial programmable logic devices.
My brain does imperative programming.

Written on my mobile. Please excuse my brevity.

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Fri Apr 25, 2014 11:21 pm

Yes, I've also seen people struggle with this concept before, but either way is fine for me, so I sometimes struggle to see where the difficultly lies.
Anyway, although I hadn't intended for this thread to become a tutorial on DDC, as somebody has taken the time to download and look through one of my example scripts, I thought that it might be a good time to explain a little more about how it all works, and walk through the countdown.ddc script.
A (hopefully) brief lesson:
DDC knows about two types of 'thing'; IO and devices (or objects, or blocks). Once the DDC file has been loaded, the DDC objects are processed at regular intervals and in sequence from the first to the last. For each object, the inputs (if any) are read, the operation the object is designed for (if any) is done, and the outputs (if any) are written. There is (currently) no jumping forwards and backwards through the objects to try and achieve loops etc.

IO are what objects read from and write to. IO can be either analog values or boolean (ON|OFF) values. They are analog or boolean depending upon how they are used. An IO with a value of 0 is OFF. An IO with a non-zero value is ON. This can be handy to know (countdown.ddc makes use of this fact).
Currently, the code I have written has knowledge of a very limited set of IO:
Constants
Branches
calstik
extsw
sys
lai

Constants are just that. They're a fixed value that the programmer enters by hand (e.g 32).

Branches are like variables. The intention is that they store values that are private to the DDC code. They are typically used to join outputs of one object to the inputs of another. Importantly, their value is retained between sucessive scans of the DDC. This means that the last value written to the branch in the previous scan is available to objects in the current scan. All branches start out life with the value 0.
Note that all IO values are (currently) integers (32 bit). There is no concept of floating point values. This isn't usually a massive issue. I may be wrong, but I think the rest of of the OpenX firmware also deals with integers of one size or another and manages to survive. It does mean that there is usually some scaling of values required to get things presented to the user the way they expect.

calstik IO read calibrated stick values from the Taranis TX. They return a value in the range -1024 -> 1024 depending on the position of the associated pot/stick.

extsw IO read the position of the various external switches on the TX. extsw:1 maps to Switch A UP (if my memory serves me). extsw:2 maps to SW A - (from memory) and so on.

sys IO are intended to contain system information. There is currently only one sys IO. sys:0 returns the uptime (in 10ms units) of the TX.

lai. These are rather like branches, but the intention is that these values would be visible to the rest of the OpenTX firmware, so could be used (for example) as inputs to mixers, custom functions, that sort of thing. This support has not (yet) been added.

For each IO, there is also the concept of a modifier. When an object reads an IO value it can take a modified version of it before the processing is done. The current set of modifiers is none (does nothing), NOT (non-zero or ON becomes OFF, 0 becomes 1), and neg (+ve values becomes -ve, -ve becomes +ve). The outpu value of an object can also be modified before being written to the actual IO as well.

There is really no limit to the number and type of IO you wish to have. I imagine things like trim settings, channel outputs, telemetry values could all be presented as IO to the DDC code.

Note that although it makes no sense to do so, objects can write to IOs that appear to be read-only. Generally all that happens is that nothing is written. Writing a value of 1 to IO constant 3 does nothing. Writing a value into calstik 1 does nothing.

Objects:
There are many objects, and again, the sky is the limit as to what the objects 'do'. Objects "do" something. They generally read input values, perform an operation and write the result to an output (or outputs).
No prizes for guessing that a 2 input OR block reads two inputs, performs logical OR on them, and writes the result to the output.
Some objects (e.g. flipflop and comparator) need to remember some state information between passes. They keep this information within themselves.
I have created a few OpenTX specific objects that do things like beep, play values, play files, and read mixer settings. Other possible objects could include ones that add mixers, change mixers, perform complex maths, write to the LCD, whatever you like really.
As I say, objects are generally connected together using branches, combining them together until you get the combination of logic you're after, which is then written to some physical IO or object that _does_ something like play a track.

I have just created a rather clever little object (if I do say so myself) which contains a string value. This string may be passed around between objects (using branches for example). Objects like the play file object can read this IO value into the filename IO and use it to identify the track to play. Multiple string objects may be defined, and the appropriate string value to use could be determined by other DDC.

To keep the size of this post down, I have attached a wee document that tries to describe how the DDC in countdown.ddc works. Hope it helps.
Attachments
countdown.txt
Explanation of how countdown.ddc works.
(4.73 KiB) Downloaded 118 times

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Sat Apr 26, 2014 3:56 am

it is not clear for me if for one set of positions of the pots, the prog will generated several beeps or only one.
That actually gives me the idea of building in some sort of 'repeat' functionality into the beep object. Simple enough to add a repeat count and repeat interval into the object.

mstrens
Posts: 1366
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by mstrens » Sat Apr 26, 2014 8:09 am

nischris,
Thanks for the (long) explanation.
I now understand your countdown sample.

I just noticed 3 attention points in the explanation you put in your attachment:
- you refers always to LAI 1 but the ddc file I had got uses LAI 0
- the ddc file I had have an instruction 170 (xfer) but it does not play a role in the logic I presume
- in your text you says:

"As the delay time of 100ms hasn'
t elapsed yet, the output (also branch 0) is written to OFF. After 100ms
elapses, the timer will write a value of ON (1) to branch 0."

I presume it must be read

"As the delay time of 1 sec (= 100 X 10 millisec) hasn'
t elapsed yet, the output (also branch 0) is written to OFF. After 1 sec
elapses, the timer will write a value of ON (1) to branch 0."

I now understand the sample but it would have be quite difficult for me to create it.
As Kilrah said, having an experience in sequential programming, it is not so easy to switch to the logic of controllers.

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Sat Apr 26, 2014 8:23 am

My bad. Yes, should be lai 0. Yes, timer is 100 × 10ms, or 1 second.
oh, I think the transfer at 170 might have been to remember that the script has been processed at least once. Check the destination branch to see if it is referenced in any of the earlier objects.
Glad to see you were paying attention, and spotted my intentional errors. ;)
I would suggest starting with something simple like just using 1 or 2 objects to make a beep or something.
I always start with a drawing.
Put the outputs on the right, and the inputs on the left.
Say you wanted to make a beep if sw a is up or sw a is down. Put swa up and swa dn on the left, and the beep object on the right.
Because we want to beep if swa up OR swa dn, we need an or object. Connect the inputs to the or, and connect the output of the or to the input of the beep. In short, that's the complete ddc. You still need to set the frequency and length of the beep, but use constants for that. That ddc is done.
Last edited by nischris on Sat Apr 26, 2014 8:51 am, edited 1 time in total.

ReSt
Posts: 1533
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by ReSt » Sat Apr 26, 2014 8:37 am

As far as I understand this from all these explanations and descriptions (and even though I have not downloaded and tried your examples), this strongly reminds me to programming small SPS'es like the Siemens Logo!

It's more like rebuilding a hardware logic in software than programming in software

And the only sequence seems to be, that the logic blocks (that have a sequence number) are worked on in the sequence of their numbering

Reinhard

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Sat Apr 26, 2014 8:41 am

I think you understand correctly.
The good thing about the logic blocks in this case is that more can be defined as needed.

mstrens
Posts: 1366
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by mstrens » Sat Apr 26, 2014 9:40 am

Here some more ideas.

Each object (controller) has inputs and outputs.
As input/output you have:
- constant
- branch (= internal variable)
- calstick
- extsw
- sys
- lai (= shared variable with openTX)

I ask myself if it would not be more logical:
- replacing calstick 1, 2, 3... by a list of all opentx sources (as defined in the "mixes" menu). I presume that you can get acces to all those values calling the function getValue(source) foreseen for Lua. So there would be no need more for your object "Value". Therefore you probably need some help from opentx developpers in order to have enough documentation
- allowing only branches and LAI as outputs; as you said, constant, calstick, ... have no sense as output

About the objects:
- it is not clear what is the reason for "ana" and "anaraw" if you already would have getValue(source)
- is it not useful having an objet to simulate "equal" (between 2 inputs with an optional third input as tolerance), less, lessor equal, ...
- is it not useful having less but a little more flexible objects (e.g. removing xfer because gxfer exists, removing negate because you can achieve the same with gxfer using the neg on input or output)

Adding an object to generate a jump would probably make it easier to program with a sequential logic in mind (without adding to much "AND"). Still, it is probably not acceptable having a jump to an previous object because it would then be possible to create an endless loop. So, it is probably more a kind of "skip" object that could be useful.

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Sat Apr 26, 2014 10:05 am

Hi
Mostly good ideas. Remember that this code is all brand new, and I haven't had the time to create all of the objects/io id like to. The work I've done so far was really only meant as a proof of concept, and to gauge whether people think it has a place in opentx. So far, all I've heard is that it's difficult to understand.
I know already about getValue (). Yes, I probably will get around to making them an io. Yes, having an equality object would be handy. It would work much like the subtract object.
The gated transfer is different from the regular transfer. The gated transfer only writes the output when the control is on. There is no problem having access to more objects. They don't take up much space in firmware to support. Yes, there isn't much need for NOT and Negate blocks, but they do no harm. Some ppl like to use them. Good ideas about the less than, greater than type objects. Objects like that are easy to create.
Not sure I agree about the jump/skip. The basic idea with this system is that each object is executed with each scan because they _need_ to be executed. Subroutines are doable, but even they get executed every scan. Often it is possible to achieve the operation of one object by combining other objects. This doesn't mean the object isn't required though.

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Sat Apr 26, 2014 6:21 pm

Btw, the getvalue object is required. Here's why. The getmixer object returnd the source input number, not its value. How do you get its value? You use the getvalue object. A 'value' io is still a good idea though.

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Mon Apr 28, 2014 10:13 pm

Support for more object types added recently including popup on LCD, up and down rate limiting, min, max, equals, high/low limit, exit. Can now read key events when the popup is displayed on the LCD. (I currently have the DDC running in the mixer task, not the menu task, which makes it a pain to read key events all the time without disrupting normal menu operation).
I would like to hear about how these LUA 'custom templates' are meant to work with LUA, and perhaps an example of how a user might use one of them. If they're anything like the example LUA scripts I've seen (e.g. elevon mix), I don't see any reason why I couldn't make this DDC system work like them. With the elevon example, should that script be running all the time? It inserts a mix into the mix table doesn't it? What happens to the mix if the script stops? Is it removed? Does the mix remain but just not work? I'm reluctant to install V2.0 onto my Taranis at present because I use it to fly models, and don't want to be bothered with switching between firmware/EEPROM versions.
It looks like the LUA scripts might be making use of some OpenTX v2.0 support (e.g. insert Input), which makes it difficult for me to replicate at the moment because I'm working with the 'master' branch, but there's nothing stopping this system making use of those same features in the future.

User avatar
Kilrah
Posts: 10416
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: A different idea relating to scripting (not LUA)

Post by Kilrah » Mon Apr 28, 2014 10:29 pm

Lua templates will run once and simply populate inputs, mixer, Logical switches etc. They're not needed anymore afterwards although you can re-run them to make changes.
Continously running scripts would only be used for secondary, non essential functions.

Sent via mobile

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Mon Apr 28, 2014 10:35 pm

Ah. I see. So a reasonably complex template might require a certain amount of user input, then create inputs, mixes based upon that.
Hmm, populating inputs etc is no problem, dealing with user input might take some thought.

User avatar
tilmanb
Posts: 347
Joined: Thu Oct 11, 2012 9:36 pm
Country: Germany
Location: Karlsruhe, Germany

Re: A different idea relating to scripting (not LUA)

Post by tilmanb » Tue Apr 29, 2014 5:09 am

If DDC has deterministic timing and memory consumption it might be better suited for run at runtime scripts.
Perhaps lua template script sets up DDC runtime.
Just a thought. ;)

For now I will put some thought into mixer based templates, sorry.

Written on my mobile. Please excuse my brevity.

mstrens
Posts: 1366
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by mstrens » Tue Apr 29, 2014 5:35 am

It could be possible I presume creating a new special function (like Play value) which should "Run a DDC".
This function could have 2 parameters:
-the name of an SD ddc file (the DDC to be run)
- the frequency of running (only once, continuously,every 1,2,3 sec)

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Tue Apr 29, 2014 5:39 am

Memory consumption is easily determined. Apart from a bit of stack (of course), the memory required is the same as the file size. The file size depends entirely on the type and number of objects used. So a two input or block requires something like 48 bytes of memory, but a rate limiter block needs something like 80 bytes. A test program I made that beeped with a frequency rising at one rate up to 2khz and falling at a different rate back down to 1khz used around 650 bytes of memory.
A bit more difficult to determine execution times because some operations may or may not result in calls to existing opentx code. As long as io operations resulting in calls to time consuming operations like lcd operations) are kept to a minimum, or not used at all, execution times will depend (again) primarily on the type and number of object blocks used. The basic objects (e.g. and, or, max, limit) should be pretty snappy. I would imagine that execution times would compare favourably with mixer times.
I haven't looked, but is there a high speed timer I can query to get an idea of actual processing time?

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Tue Apr 29, 2014 5:43 am

I kind of figured the could work in a similar fashion to lua scripts. I.e. if they're configured to run by the user, they run. I figured if the file extension was .lua we could assume it was a lua script, and if .ddc then run as ddc.
But yes, no reason why lua couldn't initiate them from the script if desired.

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Tue Apr 29, 2014 6:37 am

I also figured there might be two types of ddc program. 1) something that performs in a similar fashion to inputs/mixers/custom functions/switches, with no user input/lcd operations. I figured these could run in the mixer task. Mixers could use ddc outputs as sources, that sort of thing. I guess that outputs from the ddc would need to adhere to a convention that io values fit within a certain range (-1024 - 1024?) if they'll be used that way.
2) those that need to make use of the lcd, and read user input. They could run from the menu task. Perhaps extend the current menu system.

User avatar
tilmanb
Posts: 347
Joined: Thu Oct 11, 2012 9:36 pm
Country: Germany
Location: Karlsruhe, Germany

Re: A different idea relating to scripting (not LUA)

Post by tilmanb » Tue Apr 29, 2014 6:39 am

If ddc is suitable for user interface stuff

Written on my mobile. Please excuse my brevity.

nischris
Posts: 48
Joined: Sat Feb 08, 2014 10:39 pm
Country: -

Re: A different idea relating to scripting (not LUA)

Post by nischris » Tue Apr 29, 2014 6:45 am

Agreed. I've got it displaying a popup which is cleared by user pressing exit button, but I'm not sure how easy it will be for a user to construct a full blown template. If lua suits that task better, we could just not put the effort into getting ddc to support it.

User avatar
Kilrah
Posts: 10416
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: A different idea relating to scripting (not LUA)

Post by Kilrah » Tue Apr 29, 2014 7:29 am

nischris wrote:I haven't looked, but is there a high speed timer I can query to get an idea of actual processing time?
getTmr2MHz()


Post Reply

Return to “openTx”