er9x development

[MikeB]

Yes, I had seen that, I didn't know why. I thought I was using the same code as the burn|configure menu. I have just found a bug in that, which was carried over!

Mike.

[Malapell]

Hi,
I just installed the r817 for 128 at my 9Xr and i found a bug into mixer using "USE OUTPUT" that i use in some models.
Just setup this program to simulate the bug for "Use output":
MIXER:
CH1 +100 Thr
CH2 +100 OP1 "Use output" ON

At Safety sw setup a stiky for CH1 with THR
CH1 X !THR -100

Then look at the behaivor of CH2 when move the Thr stick;
the channel 2 value change from -100 to 100 every 1/10th of travel Thr stick. Behaivor CH2 is erratic....

Could anone confirm that is not my faulth?
Regards Jordi

[jhsa]

Is it intended that CH2 use its own output as source? Because that is what you have there..

[Malapell]

Sorry, i edited my post

[jhsa]

I confirm the problem on the latest test version for m128.
It doesn't matter the the sticky T-Cut is ON or OFF.
It looks like when I move the stick, CH 2 alternates between -100 and +100?

João

[jhsa]

If I set ch2 to follow OP3 (instead of OP1) which I programmed as Thr as well, CH2 just doesn't work..
I hope this helps finding the problem

João

[Malapell]

I made a temporal work around dissabling "USE OUTPUT" and adding a line with replace to keep -100 at output to keep woorking my models.
The problem may be related to last changes at trottle with the new options in general menu.

Regards Jordi,

[MikeB]

I'll post new test versions, with this fixed, in a few minutes, just building them now.

Mike.

Edit: Posted!

[jhsa]

Thanks Mike..

João

[Malapell]

Tested and bug killed in a record time !!!!!
Thank you Mike & João,

[MikeB]

It was just a small typing error. Since it was working fine in ersky9x I only needed to compare the code for er9x and ersky9x and the error was obvious.
When this all moves to Github, I'm hoping to merge the source code for er9x and ersky9x somewhat so this sort of error might be less likely to happen.

Mike.

[jhsa]

Thank you Mike..

João

[planger]

Hi,
I'm trying to compile er9x rev 817 under Windows found here: http://er9x.googlecode.com/svn/trunk/. After upgrading WinAVR with avr-gcc to 4.9.2, I've been able to build er9x with no parameters. I've not tested the hex file generated but it's not equal to the one available on the repository (even with PHASES=YES)...
Note: with avr-gcc 4.9.2 there are 2 warnings in menus.cpp which do not appear with avr-gcc 4.8.1.
But if I try to build with CPU=128 for my 9XR, I'm getting an error which I think is due to the missing file named optiboot.cpp. I can compile with MCU=atmega128 but I don't think it's the right way to go...
I'm thinking the repository does not contain the latest source code.
Can someone help?
Thanks, Pascal

[MikeB]

I forgot to add a couple of files before the last commit. I posted them here:
viewtopic.php?f=5&t=6976&p=96452&hilit=optiboot#p96452.

I'm using AVR-GCC 4.8.0. I tried upgrading to 4.9.2, but found the resulting code was larger than with 4.8.0. Since we are already struggling to fit everything into the M64 FrSky version, I've stayed with 4.8.0.
If you use 4.9.2, the resulting hex file will therefore be different to the one on Googlecode.

Mike.

[planger]

Thanks Mike for your quick reply.
I'm now back to AVR-GCC 4.8.0.
1. Compiling with only PHASES=YES still does not give the same hex which sounds strange. In fact it's similar but some bytes have a value with + 0x20. I don't know if you ever seen this...
2. I tried to compile with CPU=128 PHASES=YES: in menus.cpp I'm getting an undeclared "c = onoffMenuItem( b, y, PSTR(STR_FRSKY_MOD), sub==subN ) ;" on line 7892. When looking at the code, I think the "#endif" from the "#ifdef FRSKY" is missplaced and should be moved after the "#endif" of "#if defined(CPUM128) || defined(CPUM2561)". But that's a wild guess since I don't really understand why there is a difference between 64 and 128 for that part... At least moving it gets me an hex file that I will be able to try later today.
- Pascal

[MikeB]

The 128 version should be built using:
make CPU=128 EXT=FRSKY PHASES=YES
The 128 always has the FrSky code in, and you select whether you have done the hardware mod or not in the menu.

Feel free to post the hex file for the 64 you have compiled and I'll try to see what is different.

Mike.

[planger]

Hi Mike,
Ok the difference was nothing apart that my username was longer, subversion a bit shorter,... creating a shorter/longer code which is affecting the offsets. So nothing to worry about in fact...
I'll compile the 128 as you suggested and upload it.
Question for you: If I make changes to er9x code which is of interrest for multiple people of course, are you willing to include them in future releases? If yes, is a zip with the new src folder is ok so you can make a diff and see what has been changed?
Thanks, Pascal

[MikeB]

Yes, new ideas and changes are welcome. The only problems, as I mentioned above, are the version for the Mega64 with FrSky telemetry doesn't have much space left in the flash memory, and the '128 version doesn't have much space left in the RAM. For the RAM, we need space for the stack. The insta-trim function is one of the largest stack using functions. The code does include a compile option to find out how much spare stack space there is, but you need to do things like using the insta-trim operation to make sure the stack reaches the largest size it might.
I recently had a stack overflow problem on the '128 and had to reduce the RAM usage to fix it.

Mike.

[planger]

Hi Mike,
I've started to implement my changes. I don't really need a lot of more space but still a little more flash and memory...
When I will have something working on my 9XR, I'll send it to you for review and test. At that stage you could confirm if it fits in both Flash and RAM for mega64/128 and all possible compile options. I hope this is ok with you.
Regards, Pascal

[MikeB]

Yes, this is fine.

Mike.

[jhsa]

Mike, I have just revived a dead 9x board with m64 processor and realized that when you flash er9x the beeper defaults to "Quiet" that leaves the radio alarms OFF. Wouldn't it be better to make it default to"NoKey" for example?

Thanks

João

[MikeB]

Just committed r818.
Changes:
Save some flash and RAM
Commit missing source files - bootloader
128/2561 Add "keyboard" text entry
Rename PPM "Shift Sel" to "Polarity"
Add ALL and ONCE rate options to voice alarms
128/2561 add Monostable to custom switches
On disabling extended limits, channel limits reduced to +/-100
French translation, thank you "willhac"
Source file addition of "Multi" protocol

I have included a build of "er9x-frsky-fr.hex", although this is not handled by eepe at present.
If you need any other versions in French, I haven't built them as I could end up with too many versions to build. Currently I'm only building "er9x-no.hex" for Norwegian.

Mike.

[jhsa]

Thanks Mike..
I guess the monostable is the 1-Shot and 1-ShotR, right?
Polarity sounds good.
João

[MikeB]

Yes!

Mike.

[MikeB]

For general information I just ran er9x on a '128 processor and checked the stack usage. The bottom of the stack gets to within about 40 bytes of the end of the data. This is about as low as I'm comfortable with given there may be code that runs and causes the stack to grow even larger.
Basically, this means that unless I can find some RAM saving, there isn't much more we can add that needs more RAM to work. I have had a look for RAM saving and I haven't found anything.

Mike.

[jhsa]

Glad I bought another m2561.. It has the double of the m128 RAM..

João

[MGeo]

For general information I just ran er9x on a '128 processor and checked the stack usage. The bottom of the stack gets to within about 40 bytes of the end of the data. This is about as low as I'm comfortable with given there may be code that runs and causes the stack to grow even larger.
Mike.

Hi Mike,

Is there a description of the new for r818 MULTI_PROTOCOL? Looking at pulses.cpp this looks of great interest.

Also, would you be able to share the procedure for monitoring stack usage? (Apologies if this is posted elsewhere, I was unable to locate via search).

Thanks!
George

[MikeB]

The MULTI-PROTOCOL is related to this thread: http://www.rcgroups.com/forums/showthread.php?t=2165676.

There is a line near the top of er9x.h:
//#define STACK_TRACE 1

If this is uncommented when compiling then the stack is monitored and the free stack space is shown on one of the STAT displays.

Mike.

[MikeB]

I've managed to reduce the stack usage a bit by re-arranging from where certain routines are called.
E.g. The mixer, called trace() that called timer() that called timerbeeps(). Neither of these last two need to be called that way so now the mixer calls each in turn.

The DSM pulse generation code used a fixed array, creating the data, then coding it into output pulses. I've chnaged that to code directly to the output pulses. This saves 13 bytes of RAM.

I'm looking at the mixer as a whole. Currently it has an array of 32-bit values, one entry for each channel, a total of 64 bytes. Again, with some re-arranging, then I can remove this array. I've just tested this in eepe and all seems to work the same.
This change will need a bit more testing than some other changes.

Also, in the mixer, in noticed the swash ring code appeared twice (being investigated on another thread). I think it only needs to be there once. This code is common to er9x, ersky9x and openTx. I believe the code doesn't actually work correctly either.

So, I seem to be able to save some flash (200 bytes) and some RAM (77 bytes) and reduce the stack a bit.

Mike.

[jhsa]

Magic Again

João