openrcforums

I'm starting to think about rolling in some major changes.
Something along the lines of v1 -> v2.

I want to fix a couple of things that have been bugging me. Here's just a prelim list.
1) The whole way we deal with MODE. It's done badly insides. It's complex and hard to understand and confuses me. Apparently I'm not the only one.
2) The myeeprom.h structures. Since we tried to maintain backwards compatibility it looks like patchwork. It can be improved upon. Improving it will help us allow better compression.
3) A change in how the menus are built.
4) Changing how the mixers are saved. Again, a bit too complex perhaps.
5) Timer 2 - allow it to be triggered the same.
6) Sources. I think that sources should be sources. They could either be variables (like stick inputs) or binary (like switches)


Now I'm just thinking out aloud here. This does not mean imminent changes and yes, I will include a translator so you would be able to convert all your models (via eePe). Also, not all of these changes are doable/feasible. Some may have to wait for ERSKY9x.

I'd like to hear your thoughts on these issues or any other issue you think is worth reexamining. Chime in and give us your opinion.

This all excites me somewhat

I think it will be a good opportunity to correct areas that have caused problems - and still create a clear line between versions so that people can migrate their models effectively.

Rob

Sounds pretty good to me, I like thinking out loud as well.
Mode - I agree, have to watch the trims with the sticks.
Myeeprom.h IS very messy, if we can make it larger, but compress it better for eeprom storage that would be a big gain. More model specific data storage.
The menus are LARGE, if they worked better we might save a lot of code space, they are around 34K in FrSky at present, 10% smaller would give us 3.4K for enhancements.
Not sure what you have in mind for the mixers, but there is a spare byte in each of them, 32 bytes in total.
Timer 2 triggering could definately be better, possibly able to use a channel output, not just a stick input.
Sources? is this related to the mixers?

We might re-visit flight mode trims, I implemented them in a backward compatible method, but if we change myeeprom.h we may be able to do better.
Just possibly, we might look at the eeprom file system, the linked list bytes use up 128 bytes of eeprom and don't provide storage for model data.
If we have more model data storage, we might manage a customisable FrSky telemetry display, choose what you actually want to see, but would need more menus.
We have used a lot of bit fields in myeeprom.h, saves eeprom storage, but adds to flash space due to packing/unpacking them. May be able to split these up a bit.

Mike.

I think the best way is to start a new folder called v2 and copy the contents to it.
That way we don't break the current version.

I'll do that soon.

I've added the v2 folder.
Try to commit your stuff as much as you can. That way we'll stay in sync.

Surely it would be better to create a V1 freeze on development?

Leave it as a stable version.. then commit all new work to V2?

I think , if you hand coded all of it in assembler , you could find lots of extra space.
...just think ... when was the last time you got to PoP your Stack ?

Mmmm... Assembly... I miss programming assembler... Punch cards too...


---
I am here: http://maps.google.com/maps?ll=44.003067,-79.457256

Ahem... Phlem..... Assembly....

Think I remember doing verticla sync on my 4 color CRT (XT for those who know)

Nevereverveveveeve again!
The optimizer in code does it ssoooo much better than me. And then there's Mike who optimizes the optimizer better than anyone.


Assembly.... Pfffttt.
Back on track now!

I've been wondering why all the open source firmwares dont have a shared development base. Then compile time options or (if it is even possible), a modular structure. Handled by the end user thru the eepe interface (or similar). Of course my understanding is very limited. Sorta a everyone scratch their own itch but use and maintain a common tree/api/gui firmware loader.

Mostly because we all want to do our own thing. Besides, what you suggest is way more complicated to do than it sounds.

Thanks for the reply. I see where you are coming from.

3, A change in how the menus are built...

Of course.... I just took pictures of all of them and posted them to the manual! DOH!


How often does modes issue come up though???? Seems to me not very.

No doubt we will need a manual...

v1. series
v2. series

wheelspinner20 wrote:

3, A change in how the menus are built...

Of course.... I just took pictures of all of them and posted them to the manual! DOH!


How often does modes issue come up though???? Seems to me not very.

It's better to have taken pictures and posted, then to have taken them a week ago and not had the time to post them...

Rob Thomson wrote:No doubt we will need a manual...

v1.101,102,103,...690..701,702... series
v2. series

Fixed...



---
I am here: http://maps.google.com/maps?ll=44.003067,-79.457256

Erazz,
can we have channels as input for mixes and timers?

And is it possible to extend the maximum number of mixes?


Reinhard

It would be nice that we could trigger mixes with the values from the telemetry.

ReSt:
You already can have channels as inputs to mixes.
More mixes will be easy on ersky9x, memory may still be tight on er9x.

jhsa:
You already can! Custom switch - v>ofs - you can then select AD1 or AD2 as possible inputs.

Mike.

Common guys, Mike already did that. We're talking bigger things

-the audio mod fully configurable
-when we move to a telemetry screen, it could actually stay there on that screen.. also making the screens configurable so it displays whatever we want, where we want, and configurable per model
-it should also clean my house, get me some beer and cook for the entire family.. and also walk the dog specially when is bloody freezin like today bbrrrrrrrr

Any chance for a DSM(Dx6,7,8) translator to convert Spektrum settings to ER9x values?
(Just wishful thinking).

Next idea:
Move THR warning to model settings. My glider brakes (crow) on THR stick at -100. But starts w/o brakes.

MikeB wrote:ReSt:
You already can have channels as inputs to mixes.

Mike.

My fault.
You are right. I just knew there was something with channels as input.

It was another 'mix' that I was thinking off.

Throttle timer can run with relative speed of throttle position.
But not, if you use a switch (throttle cut) on that channel.
The timer runs relative to the position of the stick, not relative to the position of the output channel.

With a switch, you can only run the timer at full speed (without doing several mixes to get a rather proportional result).

I would like to be able to select the real throttle output channel% (even it this was only one fixed single virtual channel) as input for the timer, allowing me to have the % Timer run with the real output signal position, not with the stick position.

Reinhard

While we are thinking about making a clean break, can I suggest something to accompany V2?

As a noob the forum is pretty much an overload of info. I am helping to get the wiki populated, and from a late joiner's perspective, I cant seem to get a grasp on
- what the latest version of the firmware contains
- new features included
- issues addressed
- "approved" features in develpment and possible delivery timeframes
- etc

I *do* know where to get the latest version though, that is well posted, but the overall sense is that you dont know what it includes. I see a lot of threads asking if this or that is included in the current build.

I understand that we have not only ER9x being worked on, there are the special builds to consider as well as eePe etc. I am sure since this is all voluntary, people dont have time to keep lists up to date. I am just prompting a discussion on the subject.

Is this something we can address in the wiki? It does not have to be extensive or VERY detailed. I just think that it adds a lot to the trust someone puts into the FW they have downloaded and it gives a good sence of progress in what you provide. Especially since you do so much work and no-one really appreciates how far you've come with this.

If you go to the er9x home page, select source, then browse, then trunk, you will find a file called:
changelog.txt
Since November last year (2011), we have been logging info on the changes made when we commit them in this file. It is therefore a good initial source of what changed.

Mike.

Thanks for pointing that out. I will try and integrate it into the wiki on some level.

Ockert