openrcforums

Ok, thanks. I never use Companion for anything but installing firmware.

I understand that there are some new sounds needed when using v2 firmware. Is there a link to these new sound files?
I have found a link to some 'amber' sounds, but I gather that these aren't the standard sounds.
I have done a search, but didn't find anything obvious.
Thanks

bertrand35 wrote:That's said, I would be really happy if it was possible to reduce the memory footprint, any idea is welcome

I found this link today...
http://www.eluaproject.net/doc/v0.8/en_arch_ltr.html
They're talking about eLua, but perhaps there is an equivalent patch for regular Lua.

Well explained Imrich. I'd argue pretty much the same thing. 'Whiteware' is another one of those 'uncountable' words. A laundry doesn't have whitewares in it, it has whiteware.
As you say, probably a bit late now, unless both directory names are allowed.

(I still think it should be "firmware" as I wrote. Fwiw, I agree. I think one argument for calling it firmwares was that firmware for different devices might one day be located in there. If that's the case, each device should have its own firmware directory shouldn't they? I think the 'ee...

Yep, I understand that. I've never been able to flash my device from windows, so the new bootloader/flash from sd card features will be handy.

gall of the throngs emerging from their caves to throw stones at the fatted calf when they never lifted a finger to evaluate and give suggestions prior to it's release. I'm not emerging from a cave. I'm not throwing stones. I also don't need to take part in any testing process to have a preference....

Many (but not all) of the questions in this thread could be answered if people paid more attention to https://docs.google.com/document/d/1lL89b3yNXFGbtK5Z15L-oQHhGJEeY1HFAJQCN25RQGA/edit If I understand that document correctly, users will need to be in the bootloader to access files on the sd card ...

Hi During my investigations into my wee 'DDC' project, I noticed that the build size (I always build for Taranis btw) didn't seem to reduce even though I removed all references to a particular object file. It seemed that if the code was compiled, it was included in the output image. I wondered why, ...

Ok, thanks.. I'll have to build and run next some time, and time some lua scripts to see what their execution times are. I see about the same sort of time with my basic average 6 channel setup on master.

Ok, thanks. Didn't spend too much time looking at the timer thing.
Btw, do you know what typical mixer times you see?

Ok, thought I might report on my recent progress. A few things I noticed along the way. . If I understand the code correctly, getTmr2MHz () always returns 0. I scratched around a bit, and I think I've managed to set up a new timer running at 1MHz, copying what was done by a delay_01us () function . ...

Ta

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.

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 tha...

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 ...

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 ...

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.

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 rea...

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.

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'...

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

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 attent...

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.

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 m...

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 ...

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 thi...

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 stu...

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 o...

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...