Switching the use of PB7 <-> PB0 on the board

[GoogleCodeExporter]

That would be nice to switch PB5 <-> PB0 because with the toogle property of 
PB5 port PPM could be handle by hardware without any latency regarding the 
timming datagram whatever the cpu workload and TIMER1_COMPA_vect interrupt 
would be keep only for scheduling the next event and not for swiching by 
software the PB0 pin .

Vincent

Original issue reported on code.google.com by vinceofd...@gmail.com on 11 Aug 2011 at 12:18

[GoogleCodeExporter]

You may well be right Vincent -- if the TIMER1_COMPA interrupt can also be used 
alongside the PWM hardware mode in order to reload the next compare value, that 
would be much better than the present system.

We are only using PB0 because that's the way the original factory board was set 
up. In fact, in the early days, I assumed these projects would already be using 
the PWM method for controlling the pin. I was surprised to learn it was not so 
(and could not be so because of the wrong pin selection.)

As it happens, I've have just yesterday discovered that there is not enough CPU 
power to keep jitter/latency acceptable and also process incoming fr-sky 
telemetry packets. I'm very disappointed. The only possible fix I see now is to 
do exactly as you suggest, if it can be done. Unfortunately, all out new 
hardware design are using PB5 for other uses though. So I'm not sure how to 
proceed, yet.

Meanwhile, we have plans to move to a much (much!) more powerful ARM-based MCU 
for the V5 board. That will help a lot. But first, we must try to complete the 
V4 board as promised.

Original comment by gru...@gmail.com on 12 Aug 2011 at 2:36

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 12 Aug 2011 at 2:36

• Changed state: Accepted

[GoogleCodeExporter]

I finally realised that the ATmega chips automatically auto-block interrupts on 
each jump vector. The simple fix to the above mentioned problem was to un-block 
them again in the USRAT receiver interrupt service routine. No more jitter. 
Thank goodness! We're back in business.

Original comment by gru...@gmail.com on 12 Aug 2011 at 4:37

[GoogleCodeExporter]

That nice to hear you have find a solution :)
You are right about keeping TIMER1_COMPA just for scheduling the next interrupt 
compare value and the beauty is that you can be late on TIMER1_COMPA scheduling 
as long as timing offset is not higher as the next entry pojnt timing.
I went thru those trouble on an other AVR related project that was suppose to 
decode FRSKY and translate to Royal Evo telemetry display and by the way also 
accept incoming PPM. I finally land on a solution based on scheduling the work. 
For example i can see that you handle on the fly the decoding of FRSKY input 
ISR(USART0_RX_vect), i would suggest to keep interrupt as short as possible and 
implement a circular buffer to store data and call later on a function to 
decode that data. Having big code segment in interrupt leads to a lot of 
register to store and restore on each interrupt that at the end cost a lot more 
that just storing data and handle them in a procedure way it also keep at 
minimum the timming offset of other interrupt.
Also the TIMER3_CAPT_vect for PPM input could quiet eat a lot of CPU and on my 
project i just store ICR3 in a buffer and handle them at a better timming. As 
there no free meal this lead to consume a bit of memory to store those value.  

Vincent 

Original comment by vinceofd...@gmail.com on 12 Aug 2011 at 8:32

[GoogleCodeExporter]

By looking at the Atmega Datasheet there is another option quiet more simple in 
terme of rewiring the board.
The PB7 (Backlight) as also the property to be hardware toggle based on TIMER1 
COMPC. This would be an easy soldering hack and would resolve all the problem 
of PPM out Precision and could also stay as an option because even with the 
hack in place and a wrong firmware this should not create any shortcut as both 
pin are not supposed to connected to ground like the actual PB5 button .
I can provide help for coding on this. 
Vincent

Original comment by vinceofd...@gmail.com on 12 Aug 2011 at 10:25

[GoogleCodeExporter]

Yeah -- seems you're reading to old original test code. It was never intended 
to leave all that stuff in the ISR routine. There's now a three level buffering 
system and very short USART_RX function.

That's great news about PB7 and COMPC -- even better that it's still on TIMER1. 
I haven't had a chance to get to the data sheet myself yet, but I was really 
hoping for something just like that. Thanks for letting me know and saving some 
work. Sounds very encouraging.

I'm happy to report that even with the software bit-bang on PB0, we are 
presently processing PPM_in and full speed "full on" fr-sky telemetry data with 
no more than max 2us total jitter on PPM_out. Once your suggestion is 
implemented, things should be as perfect as they can get. For me, it's just a 
case of prioritising the time and getting around to it now. It feels good to 
know there's a better solution just waiting there for us. :D

(This current development code is at /branches/frsky/src. There's been many, 
many hours of extra work done in there since the trunk/src version you might 
have been looking at. Though actually, the introduction of the three layer 
buffering system to release precious ISR processing time has only gone in over 
the past three days, since before then, I simply had too many other priorities 
(unrelated to this project.)) 

Original comment by gru...@gmail.com on 12 Aug 2011 at 10:55

• Changed title: Switching the use of PB7 <-> PB0 on the board

[GoogleCodeExporter]

Yeah my apologize i was looking at ER9X FrsSky that is i believe way older that 
the gruvin branch.
I will anyway try also the gruvin9x on my 9X fact is i buy recently the 9X for 
geek and curiosity purpose and in the meantime i did fry my main TX (my beloved 
Royal evo) that as put me in an urge to build up the 9X so i did not take an in 
deep look at every version right now.
If you want some help (to spare some time for you) i really can deliver PPM 
output based on PB7
Vincent

Original comment by vinceofd...@gmail.com on 12 Aug 2011 at 11:40

[GoogleCodeExporter]

Sorry to hear you fried your evo! I've not owned one, but everyone who has them 
says they're very good.

I (we) would enjoy your offer of assistance with the PPM_out-PB7 changes. We do 
our development in the /branches/frsky/src area, while keeping /trunk exclusive 
for mature and tested code versions. I have added you as a committer. (Don't 
worry -- if you destroy everything, I'll just remove you again and revert the 
code. It's not the end of the world! *smiles*)

You will be the forth committer. Currently there is Cam (UK), working mostly on 
PCB design to date, Bertrand (France) contributing LOTs of stuff, including 
quite a bit of experimental code and finally myself (NZ), working mostly on 
telemetry and SD/MMC card related stuff -- much more slowly than Bertrand.

Obviously, the PPM_out changes will need to be an option, controlled from the 
Makefile. Let's say, -DPPMPB7 or something like that.

With three active code committers, it will be all the more important to ensure 
as regular as practical update/commits take place, to prevent too much hard 
work with possible merges. I am supposed to be project manager, so ideally any 
area of code you wish to work on should be cleared through me first, so that I 
can help ensure others do not conflict. However, I have been giving Bertrand 
great latitude up to now to pretty much just do whatever he wants -- because 
had massive changes in mind, which I wanted to just give him the space to 
complete. So we have to keep that in mind for now. (He is on holiday for two 
weeks presently, just left today I think.)

Welcome aboard! It need not be a long term thing. Should you ever wish to be 
removed from the committers list, just say so. No problem.

Original comment by gru...@gmail.com on 12 Aug 2011 at 1:36

[GoogleCodeExporter]

You know this crossed my mine some time ago about using a hardware generated 
PPM_OUT, unfortunately it crossed and kept on going. Clean forgot.

Changes implemented on V4.1, uncommitted yet, check your inbox Bryan. 

Original comment by th9...@gmail.com on 12 Aug 2011 at 10:48

[GoogleCodeExporter]

Vincent -- I forgot that on the v3.2 and v4 boards, we're already using timer0 
hardware output for the speaker driver. Cam and I will try to find a solution 
to that shortly. Will let you know. (Obviously PPM_out trumps a speaker! 
Hopefully we can move it to another OC pin without too much trouble. Sheesh)

Original comment by gru...@gmail.com on 12 Aug 2011 at 11:15

[GoogleCodeExporter]

Thanks for the invitation i am glad to be onboard.
Regarding V3.2 or V4 board as they use atmega256X we got lot of 16bit timer 
with so maybe PPM could be implement on another timer hardware pin. I will work 
first on the PB7 for atmega64 then you just have to tell me regarding your new 
board and the intend use of the new hardware ouput . We have as potential 
candidate
PL3,PL4,PL5 with TIMER5 or PH3,PH4,PH5 with TIMER4. 
As he future option this is easy with one timer to output 3 distinct PPM so 3 
is maybe to much but being able to have a second PPM output to handle channel 
8-16 could be useful for some configuration. That would be a smart move to use 
the  new timer for there hardware capacity and keep the (old timer atmega64) 
for software interrupt only as much of the hardware pin are already allocated.

Vincent

Original comment by vinceofd...@gmail.com on 13 Aug 2011 at 9:10

[GoogleCodeExporter]

Sounds good to me. I clearly misread the data sheet. I though this function was 
only possible on timer 1 (and the 8-bit timer 2). Good to now timer 4 and 5 
could be used also. (There has been murmurs of maybe supporting two TX modules 
some day -- most likely not for aircraft use.)

We ended up settling on PB6(OC1B) for the V4.1 board. But you needn't really 
give that a second thought right now, as there's zero code written for the V4 
board as yet. There will in fact be many changes needed because we've moved 
stuff all over the place. (Don't bother with PCB v3.2 either. That board 
officially does not exist and will not be reproduced beyond the current users, 
who are all aware it is to be obsoleted at some point soon. So for now, it's 
real simple. Just a build option for the factory board and the accompanying 
solder-hack. Cheers.)

[Further comment moving to detached email.]

Original comment by gru...@gmail.com on 13 Aug 2011 at 11:44

[GoogleCodeExporter]

Work is ongoing i got a clean PPM on my PB7 with only about 2lines of code 
(still keep all the interruption that are in place and just added the toogle 
property for PB7 at the start sequence and copy OCR1C=OCR1A in the actual 
interrupt.
The hack could be eventually a software option as in my case if i trow a PPM 
stream to my LED backlight controled with a 2N7000 this will not harm anything 
but would it be the same with an invert pullup for 115V backlight  maybe you 
could answer that electronic question as i am not very confident on this area.

I need now to :
1) Handle the choice of polarity of the signal.
2) Find a smart soldering hack (should not involve close CPU scary soldering 
like the FRSKY mods)
3) Compare the signal precision with the original one with my logic digital 
analyzer to give a clue of how valuable this hack could be in the worst case 
scenario (PPM IN + FRSKY TELEMETRY). Trouble is to test i have also to catch 
the worse moment wich is when we at the same time UART from FRSKY + PPM output 
+ PPM input.
4) do some test and submit for aproval to the DEV Branch.

Vince

Original comment by vinceofd...@gmail.com on 16 Aug 2011 at 6:06

[GoogleCodeExporter]

I have just publish in the /branches/frsky/src/ the ppm mods.
there are 4 files involved 
Makefile  // adding option HARDPPM to define DPPMPB7_HARDWARE that is use in 
the code to activate the mods
gruvin9x.cpp  // one insert at the start of the program and one in the interrupt
gruvin9x.h // handle switch PB0<->PB7 definition 
menus.cpp // handle the control and adjustment to produce the right ppm polarity
Vince

Original comment by vinceofd...@gmail.com on 20 Aug 2011 at 9:15

[GoogleCodeExporter]

Thanks. Job well done. Please see my comments elsewhere.

One thing I thing would be an improvement would be to manipulate the "next 
edge" bits at each call to the ISR, rather than relying on the toggle remaining 
on the correct phase.

I'm talking about the bits that control what the pin will do at the next 
compare event -- switch to low or switch to high. I think this would be 
preferable than simply using toggle, as if gives precise and definite control. 
However, what you have should also work fine. No no urgency. I look forward to 
when I can test it properly myself. 

Original comment by gru...@gmail.com on 21 Aug 2011 at 11:08

[GoogleCodeExporter]

Your probably right but i am a lazy coder ;) and on my other project i did use 
toogle property for PPM as it allow the minimum of code into the interrupt, but 
i am a bit extremist on interrupt optimization.

Vincent

Original comment by vinceofd...@gmail.com on 22 Aug 2011 at 9:21

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 22 Aug 2011 at 11:12

• Changed state: Started

[GoogleCodeExporter]

Fair enough. Your input to date is certainly appreciated and I'll be perfectly 
happy for you to leave it as it is and let me address this myself, some time 
later. Meanwhile, I will try to convince you why I think this actually does 
need to be addressed in the first place -- if only for interest's sake.

My specific concern is that it is possible for power spikes (especially likely 
under low or failing battery conditions or faulty connector/solder joints etc 
-- all real world possible scenarios) to affect latch outputs, potentially 
reversing the polarity without user knowledge or intention. In practice, this 
could amount to a model going out of trim, at best or a straight out spiral 
into the ground, at worst.

I would suggest this is why the existing bit-bang code follows this very same 
recommended practice of not simply toggling the existing output state, but 
rather more safely checking and asserting the correct polarity on every pass.

  if(pulsePol)
  {
    PORTB |=  (1<<OUT_B_PPM);
    pulsePol = 0;
  }else{
    PORTB &= ~(1<<OUT_B_PPM);
    pulsePol = 1;
  }

As an industry example, I can't speak for Atmel, but I know that Arizona 
Microchip (PIC(tm) chips) expressly recommend that all mission critical digital 
outputs be continuously re-asserted in any noisy or safety related application. 
I believe this should be standard practice in all embedded electronics 
applications where safety or otherwise critical devices are involved. Since our 
application is both mission critical and involves safety, that to me must 
therefore take priority over everything else -- especially when we're only 
talking about what, four machine level instructions inserted in the above, 
quoted code?

On the topic of keeping ISR functions compact and efficient, I only just 
recently noticed the seemingly extreme amount of code the setupPulses() 
function and that this is called from within the PPM_out ISR. Possible in-line 
compiler optimisation aside and only as at a first glance, this all looks 
pretty poor coding practice to me. If early memory of TH's original code serves 
me right, I think the ER team has bloated this code out much more than was ever 
originally intended. My initial impression is that setupPulses() probably 
doesn't even need to be in the ISR at all -- or maybe it does. Anyway, this is 
on my to-do list for some time down the track. For now, "It aint broken so I 
aint fixing it." See, I can be a lazy coder too, sometimes. :D

Original comment by gru...@gmail.com on 23 Aug 2011 at 11:51

[GoogleCodeExporter]

I get your point but we do correct polarity at every time we forge a new pulse 
so about 50 time per second so if we have a glitch producing a reverted signal 
it would be corrected at the next PPM pulse.
And even if we correct inside a PPM pulse the polarity due to a glitch the 
receiver would anyway probably be offset of one channel.

Yeah you absolutly right about the PPM setuppulse being inside the interrupt 
make no sense. I would rather trigger the PPM after having perform the perOut 
function that update the position and they seem actualy to work without sync 
witch could produce an additional delay of 25ms between computation and signal 
writing.

The only interest is if the program hang somewhere we still send a PPM output 
but then watchdog would trigger a reset so the idea of keep compute position in 
sync with signal production is still good one.

I could maybe miss something but i do think that we probably perform several 
perOut Calculation during the time of 1 PPM signal.

I will try to monitor the PerOut exec in regard with the PPM to watch the sync 
but i am pretty sure that i will observe a continuous sync drift.

Original comment by vincent....@5emegauche.com on 23 Aug 2011 at 3:06

[GoogleCodeExporter]

Vincent wrote: "but we do correct polarity at every time we forge a new pulse"

Ah. My apologies. I must have misread the context of the polarity sync code. I 
thought the polarity was only synced once, at start-up. So that's good to know 
and I'm sure it will suffice, since as you suggest, any corrupted pulse is soon 
to be an irrelevant event in history, anyway. Good.

Let's indeed work on getting setupPulses() out of the ISR and into perOut, 
where it was probably originally intended. Browsing TH's code via his project 
site is always a good idea for things like this. He seems to take great care 
with these things. 

Original comment by gru...@gmail.com on 23 Aug 2011 at 10:37

[GoogleCodeExporter]

Will do scope  test to watch the sync between PPM_PULSE and Mixer Calculation.
The correction if needed should be easy

Original comment by vincent....@5emegauche.com on 25 Aug 2011 at 12:10

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 5 Sep 2011 at 11:12

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 23 Sep 2011 at 1:52

• Changed state: Verified