JETI display does not work

[GoogleCodeExporter]

Sorry for my short answer. My English is not very good.

Which board (stock / gruvin9x / sky9x) are you using?
= tested with m64 and m128 (stock)

What is your open9x FW version?
= tested with r1651, r1855, r1894. With version r1650 the Jeti menu works 
perfectly.

What is your open9x EEPROM version?
= 212

What steps will reproduce the problem?
1. Flash the firmware version r1651 or later.
2. Something is wrong with the "return" command in the firmware r1651.

What is the expected output? What do you see instead?
= The Jeti menu flickers. The key commands are not accepted.

Please provide any additional information below.
= Here is the topic has already been discussed: 
http://9xforums.com/forum/viewtopic.php?f=45&t=2604

Original issue reported on code.google.com by fabian.b...@gmail.com on 26 Jan 2013 at 11:21

[GoogleCodeExporter]

Excellent investigation, it should be easy to fix now!

Original comment by bson...@gmail.com on 26 Jan 2013 at 11:50

• Changed state: Started

[GoogleCodeExporter]

This is great!

Original comment by fabian.b...@gmail.com on 26 Jan 2013 at 1:15

[GoogleCodeExporter]

I don't see any evident bug in revision r1651. Did you try to put again the 
break instead of return?

Original comment by bson...@gmail.com on 26 Jan 2013 at 1:55

[GoogleCodeExporter]

Hi in my case only you can see the JETI main menu and keys on the left are 
inoperative

Original comment by camach...@gmail.com on 26 Jan 2013 at 2:40

[GoogleCodeExporter]

I have now tested the version R1651 with "break" in jeti.cpp. The text is no 
longer flickers, but the keystrokes are not accepted.

Original comment by fabian.b...@gmail.com on 26 Jan 2013 at 4:27

[GoogleCodeExporter]

Is it perhaps a timer problem? At line 2959 of file open9x.cpp lot has changed:
https://code.google.com/p/open9x/source/diff?spec=svn1651&r=1651&format=side&pat
h=/trunk/src/open9x.cpp

Original comment by fabian.b...@gmail.com on 26 Jan 2013 at 4:42

[GoogleCodeExporter]

Would you try to remove the full block like that?

#if 0
  switch(event)
  {
    case EVT_KEY_FIRST(KEY_EXIT):
      JETI_DisableRXD();
      chainMenu(menuMainView);
      return;
  }
#endif

Original comment by bson...@gmail.com on 26 Jan 2013 at 4:43

[GoogleCodeExporter]

I tested your idea. The problem remains. The ESC and MENU key will no longer 
function well.

Original comment by fabian.b...@gmail.com on 26 Jan 2013 at 5:03

[GoogleCodeExporter]

Would you try something like that, you will get the idea:

  if (JetiBufferReady)
  {
    JETI_EnableTXD();
    if (switchState((EnumKeys)(KEY_UP))) { 
      jeti_keys &= JETI_KEY_UP;
      lcd_putc(10*FW,   4*FH, 'U');
    }
  ....

Original comment by bson...@gmail.com on 26 Jan 2013 at 7:01

[GoogleCodeExporter]

I tested this code:

if (JetiBufferReady)
{
  lcd_putc(10*FW,   4*FH, 'U');
}

Nothing happens... Something's wrong with "JetiBufferReady".

Original comment by fabian.b...@gmail.com on 26 Jan 2013 at 8:03

[GoogleCodeExporter]

Interesting. Do we enter in the RX interrupt? Do we display something on screen 
(which comes from the JETI module)?

Original comment by bson...@gmail.com on 26 Jan 2013 at 9:33

[GoogleCodeExporter]

Yes, it appears some of the Jeti module. New values ​​are also transferred. 
However flickers all.

When I connect an external JETIBOX and change the page, then shows me the 
remote control to the new page.

Only the input of the keys being blocked.

Original comment by fabian.b...@gmail.com on 26 Jan 2013 at 9:58

[GoogleCodeExporter]

Would you try to set this var as volatile?

volatile uint8_t JetiBufferReady;

Original comment by bson...@gmail.com on 26 Jan 2013 at 10:14

[GoogleCodeExporter]

I only declared the variable "JetiBufferReady" with volatile. Then the 
variables "JetiBuffer" and "jeti_keys". Unfortunately without success.

Something must be in the other files have changed with the R1651.

Pretty jinxed :-).

Original comment by fabian.b...@gmail.com on 26 Jan 2013 at 10:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've just tried the following:

switch(event)
  {
    //case EVT_KEY_FIRST(KEY_MENU):
    //  break;
    case EVT_KEY_FIRST(KEY_EXIT):
      JETI_DisableRXD();
      chainMenu(menuMainView);
     // return;
     JetiJumpOver = 1;
  }

  if (JetiJumpOver == 0)
  {
  for (uint8_t i = 0; i < 16; i++)
  {
    lcd_putcAtt((i+2)*FW,   3*FH, JetiBuffer[i], BSS);
    lcd_putcAtt((i+2)*FW,   4*FH, JetiBuffer[i+16], BSS);
  }

  if (JetiBufferReady == 1)
  {    
    JETI_EnableTXD();
    if (keyState((EnumKeys)(KEY_UP))) jeti_keys &= JETI_KEY_UP;
    if (keyState((EnumKeys)(KEY_DOWN))) jeti_keys &= JETI_KEY_DOWN;
    if (keyState((EnumKeys)(KEY_LEFT))) jeti_keys &= JETI_KEY_LEFT;
    if (keyState((EnumKeys)(KEY_RIGHT))) jeti_keys &= JETI_KEY_RIGHT;

    JetiBufferReady = 0;    // invalidate buffer

    JETI_putw((uint16_t) jeti_keys);
    _delay_ms (1);
    JETI_DisableTXD();

    jeti_keys = JETI_KEY_NOCHANGE; 
  }
  }

  JetiJumpOver = 0;

The problem still exists. Where the function jumps when leaving with "return"?

Original comment by fabian.b...@gmail.com on 28 Jan 2013 at 12:23

[GoogleCodeExporter]

Where is initialized JetiJumpOver?

EVT_KEY_FIRST(KEY_EXIT) is the event when the user presses [EXIT], at the 
moment the button is pressed (not released as KEY_BREAK).

When you write it flickers, do you mean that the JETI menu directly returns, or 
the JETI menu is displayed, but completely blinking?

Original comment by bson...@gmail.com on 28 Jan 2013 at 12:35

[GoogleCodeExporter]

JetiJumpOver is initialized under JetiBufferReady and "jeti.h" (uint8_t). The 
[EXIT] Key works perfectly.

I made a short video to show the problem:
http://youtu.be/I71MDYuhHBY

Original comment by fabian.b...@gmail.com on 28 Jan 2013 at 1:16

[GoogleCodeExporter]

I have just tested the version r1906. The error is still unfortunately. There 
are still some errors when compiling. 

"jeti.h" > line 45+47 > "volatile" missing
"open9x.h" > line 1062 > "volatile" missing

What could be wrong yet?...

Original comment by fabian.b...@gmail.com on 2 Feb 2013 at 9:45

[GoogleCodeExporter]

I just commited the fix for the compilation errors. However I don't think it 
will fix our problem.

I think we need to add some more traces to help us to track the bug. Obviously 
JetiBufferReady is never set to 1 (or during a too short time). Unless hmmmm. 
suppose the frame length is the same than the PPM frame, well perhaps no, not 
always. It would be good to have something in the if (rl == 0xff) { // here } 
code, perhaps you just add a new variable "uint8_t stopConditionMet" and set to 
1 there. Later in the display code, you display this variable stopConditionMet.

Ok?

Original comment by bson...@gmail.com on 11 Feb 2013 at 8:40

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

There ist another compilation error:
"open9x.h" > line 1092 > "volatile" missing

I tested the trick with "stopConditionMet". I added "uint8_t stopConditionMet = 
0;" on line 40. 
After "if (rl == 0xff) { // here }" code I've packed a "stopConditionMet++;".
Lastly I wrote the following after line 199: "lcd_putc(10*FW,   5*FH, 
stopConditionMet);"

The display was shown perfectly with all the letters (stopConditionMet). "if 
(rl == 0xff) { // here }" is apparently not as a problem...

Original comment by fabian.b...@gmail.com on 12 Feb 2013 at 9:13

[GoogleCodeExporter]

You are right for the compilation error, but I can't commit this fix now as my 
workspace is plenty of other mods that I cannot commit in the current state...

It's good to see that we reach that code (r1==0xff). Would it be possible that 
my comment "Unless hmmmm. suppose the frame length is the same than the PPM 
frame" could be right? Would you try to change the PPM frame length?

Original comment by bson...@gmail.com on 12 Feb 2013 at 9:22

[GoogleCodeExporter]

I just discovered a very strange error.

If I flash the Companion9x code the remote control works perfectly. But with 
the self-compiled code following happens:
http://youtu.be/_62unJNxdwI

Something is wrong with the servo outputs. Where can I check the PPM frame 
length?

Original comment by fabian.b...@gmail.com on 12 Feb 2013 at 9:28

[GoogleCodeExporter]

Do you mean that the "official" jeti flavor FW works correctly?

Original comment by bson...@gmail.com on 12 Feb 2013 at 9:58

[GoogleCodeExporter]

No, the official firmware does not work either. But the servo output problem 
(video) exists only when compile yourself ...

Original comment by fabian.b...@gmail.com on 12 Feb 2013 at 10:02

[GoogleCodeExporter]

Ok understood. It depends on the compiler you use, I suggest only gcc 4.7.2

Would you try to change the PPM frame length? In ModelSetup screen, at the end

Original comment by bson...@gmail.com on 12 Feb 2013 at 10:11

[GoogleCodeExporter]

That's it :-). Wonderful...
I turned the frame length to the bottom.

PPM 8CH
12.5ms 300u -

But JETI makes problems with too short frame lengths. Thats a other problem :-).

Original comment by fabian.b...@gmail.com on 12 Feb 2013 at 10:31

[GoogleCodeExporter]

Mmh... I just put all the channels on the throttle stick. Is the stick all the 
way down the JETI display works correctly. If the throttle stick is above 
nothing works.

Original comment by fabian.b...@gmail.com on 12 Feb 2013 at 11:37

[GoogleCodeExporter]

It makes sense now :) It's a design bug which is here since the very beginning!

Original comment by bson...@gmail.com on 12 Feb 2013 at 1:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It is easy to fix the problem? Or it is very complicated.

Original comment by fabian.b...@gmail.com on 13 Feb 2013 at 8:30

[GoogleCodeExporter]

Top bar added in the JETI screen

Original comment by bson...@gmail.com on 13 Feb 2013 at 8:31

• Changed state: Fixed