ERSKY9X Coding

[cre8tiveleo]

Thanks, will try that out.

It's er9x for ersky that's in m emory right now, but after trying to flash companion. I'll try again and see what happened... weirdness... off to work I go, yeah, to pay for this hobby!

[MikeB]

I'll have a look, I'm guessing the EEPROM contents is confused, switching between the different softwares. You clearly have an incorrect value for the display type (Optrex/Stock), hence the black down the left, what else is wrong in the EEPROM?

Mike.

[Romolo]

The yagarto toolchain I have is yagarto-bu-2.21_gcc-4.6.0-c-c++_nl-1.19.0_gdb-7.2_eabi_20110429.exe. It looks like There is a more recent version that uses gcc 4.6.2 (not 4.6.0). By following the link to SourceForge, you can find this older version. I shall stick to it for now as it is working.
Not sure which boards you are referring to.

Mike.

We are using the 4.6.2 version ported to linux and it works, I have compiled it personally and if someone needs an help just ask.
It compiles rather out of the box on 32 bit systems, a little more complex on 64 bit ones.
Open9x is compiled directly on the server using 4.6.2 version at 32 bits.

[Romolo]

I'll have a look, I'm guessing the EEPROM contents is confused, switching between the different softwares. You clearly have an incorrect value for the display type (Optrex/Stock), hence the black down the left, what else is wrong in the EEPROM?

Mike.

We are adding optrex display type support in companion9x, then it will be possible to reset it easily.

[cre8tiveleo]

I'll have a look, I'm guessing the EEPROM contents is confused, switching between the different softwares. You clearly have an incorrect value for the display type (Optrex/Stock), hence the black down the left, what else is wrong in the EEPROM?

Mike.

I know the display is incorrect, the default on the eeprom is stock, i have an optrex.

What else is wrong, it keeps resetting. Let me reset the cpu, and reload it all and see if i can duplicate what just happened.

[gohsthb]

Romolo,
Would you consider making a thread about how you ported yagarto to linux? I would like to know, and I'm sure there are others too.
Thanks,
Gohst

Sent from my LG-P999 using Tapatalk 2

[Rob Thomson]

Pretty sure you don't need to port it. Linux has most compilers in by default?


Sent from my iPhone using Tapatalk

[Romolo]

I do not have found an updated arm compiler for the distributions we are using (fedora and opensuse)
so I compiled myself, I will attach here a modified build script that should works out of the box on fedora 32 bit

you have to decompress it in a subdir...
then enter in the download directory and do an sh script.sh (it will retrieve automatically sources for yagarto
i have update source list to binutils 2.21.1
after the download finish
cd.. (go to the previous dir)
and do a
. xx-build-all.sh (please note the dot)
after build will finish you will end with a yagarto installation in the install directory.
I moved the contents of it to /usr/local
that's all, very easy

[Romolo]

I'll have a look, I'm guessing the EEPROM contents is confused, switching between the different softwares. You clearly have an incorrect value for the display type (Optrex/Stock), hence the black down the left, what else is wrong in the EEPROM?

Mike.

I know the display is incorrect, the default on the eeprom is stock, i have an optrex.

What else is wrong, it keeps resetting. Let me reset the cpu, and reload it all and see if i can duplicate what just happened.

Companion9x is now updated you can set display type from general settings.
Thanks Leo for highlighting the missing setting.

[MikeB]

Just for info, I have some progress on the SD card interface, I have the hardware set up, and I am getting some responses from a SD card. Now learning the exact sequence things have to be done in, it's very specific. Reading (and writing) data may happen tomorrow, spent several hours on it today.

Mike.

[Rob Thomson]

Well done


Sent from my iPhone using Tapatalk

[ReSt]

Now learning the exact sequence things have to be done in, it's very specific. Reading (and writing) data may happen tomorrow, spent several hours on it today.

Mike.

I found that there is a sd library available on the Arduino.cc pages.
http://arduino.cc/en/Reference/SD

Maybe it could help you somehow?


Reinhard

[cre8tiveleo]

WTG Mike!! It will be an added bonus for things to come when the sd card is functioning. Very cool.

[MikeB]

SD card coming along nicely, I can now read data blocks. 1 512 byte block read in under 125 uS using a 9 MHz clock, we can go to 18 MHz. This is mainly test code, but all the hardware on the ersky9x board for the SD card is working. Checking this was my aim number 1.
Next, I'll package up my test code into a 'proper' driver. Then we can look into grabbing FAT file system code and putting that in.

Mike.

[Clivew]

A big step forward!

Well done Mike! Looks like we have a "killer" transmitter in the making

[Rob Thomson]

Great stuff . Looking forward to seeing this in action.


Sent from my iPhone using Tapatalk

[SkyNorth]

The Co-processor (ATtiny167) is also working and sending its internal temp to the ARM on the I2C bus.
That is all the on board hardware features now working... Mike also has the Rotary encoder input working for testing

The Rev B1 boards can now be built up ...we are almost there....
-Brent

[Clivew]

Now what was that proverb?
Was it "Build a bettter mousetrap and the world will beat a pathway to your door"?
Something like that anyway

Well done Brent

[MikeB]

I'm going to suggest a slight re-arrangement of the main code used in both open9x and ersky9x for use on the ARM (ersky9x) board.
Something like:

mainLoop()
{
uint8_t event ;
event = flightControlProcess() ;
userProcess( event ) ; // menus etc
}

flightControlProcess() should read all the switches, sticks, pots etc. do all the mix processing, generate the outputs, handle timers.
It should also call the background tasks (often every 10 mS) such as audio and (in ersky9x case) eeprom processing.

userProcess(event) should process the menus, and be responsible for handling tasks like logging to SD card.
Should an operation be required that will take more than a few milliseconds then such an operation should call flightControlProcess() ; frequently enough to ensure full control is maintained, and timers run at the correct speed.

This is easier to implement, rather than a RTOS (Real Time Operating System). It just requires that flightControlProcess() ; is called when needed.

I have something like this in ersky9x. The main loop actually calls another function mainSequence( MENUS ). This does the main loop function, including calling the menu handler. When the menu requires to load a new model, it needs to make sure the current one is properly saved first. Both this, and loading the new model may take time. While waiting for the eeprom operations to complete, mainSequence( NO_MENUS ) is called. This does the main loop function, but prevents the menus from doing anything.
This may be good enough, but I think the code above is easier to understand.

Any comments or alternative suggestions?

Mike.

[gohsthb]

Couldn't you make flightControlProcess() an interrupt that is called by a timer? Then the menu functions wouldn't have to worry about how long they take? There is probably a reason you haven't done this already. Is so why would that not work?
-Gohst

[MikeB]

The drawback with the interrupt approach is where a menu function carries out an update that takes more than one memory access. The interrupt could occur between these accesses, and then use an invalid value.
This is less likely on the ARM processor as it can do a 32 bit write in a single access, it is really bad on the 8 bit MEGA64.
You can disable interrupts round the updating operation, but you still need to recognise it is needed.
the flightControlProcess() will also need to allow other interrupts so will need to be protected from interrupting itself! Possible on the ARM as it has interrupt priority levels.
Maybe we do a mixture of both. Use my idea, but start a timer when flightControlProcess() ends. If the timer runs out, and flightControlProcess() has not been called, then run it anyway. At least we will keep the controls running.

At present, we effectively run the flightControlProcess() as often as possible. On the ARM board, the STAT screen reports less than 3mS for the main loop, so it is running at over 300 times per second. If we drive it from an interrupt, we will actually limit it to a slower update rate. It is worth considering the interrupt approach though.

I must have another look at the ARM processor, it has task control options I've ignored so far, too much else to learn to get it running.

Mike.

[Kilrah]

Couldn't you make flightControlProcess() an interrupt that is called by a timer?

That.

Keeping flightControlProcess() in the main loop doesn't improve anything if the main loop gets stuck/delayed. Use a dedicated timer, which calls flightControlProcess() in the ISR. Interrupt with highest priority of course.
All the rest (telemetry parsing, display, sound, logging,...) in the main loop, and thus gets executed in idle time, and even if you stick an endless loop in there you'll stil have model control even if the UI is completely stuck.

The drawback with the interrupt approach is where a menu function carries out an update that takes more than one memory access. The interrupt could occur between these accesses, and then use an invalid value.

But then again you're not editing stuff in flight, so even if one cycle had a glitch in the RC signal during ground setup it wouldn't be any worse than currently on the stock board, where some menu edits take long enough to notice the signal drop...

If it's so bad... isn't there enough RAM to buffer the "live" settings?

[MikeB]

I'm not sure about the "interrupt with highest priority" bit. As I understand it, on the ARM processor, as long as you are in the interrupt routine, all lower priority interrupts are locked out.
We need some of the other ibnterrupts to keep running.

It isn't as easy as on the M64 where you just re-enable interrupts, on the arm lower priority interrupts are still blocked. More datasheet reading needed! (It's 'only' 1106 pages long).

Mike.

[Kilrah]

Would make sense...
What are the other important interrupts?

[MikeB]

Interrupts in ersky9x:
DAQ - audio
TWI (I2C) - Volume and co-processor
Timer - provides 5mS and 10mS time ticks and calls
PWM - controls the PPM/PXX/DSM output signal
SPI - external eeprom function
Timer- capture PPM in for trainer

I think all of these will need to interrupt the flightControlProcess(). the are all "real time" events that should not be delayed.

Mike.

[Kilrah]

Hmm...

DAQ - audio

Wasn't that running off a DMA?

Timer - provides 5mS and 10mS time ticks and calls

OK, that's quick too anyway

PWM - controls the PPM/PXX/DSM output signal

Wasn't that supposed to be on a DMA as well? flightControlProcess() would calculate the values for the next cycle and place them in a buffer, that get fed to the output module asynchronously

SPI - external eeprom function
TWI (I2C) - Volume and co-processor

Do those need interrupts? The EEPROM won't mind if it's sent a byte 2 seconds later than the previous one...

Timer- capture PPM in for trainer

That maybe, although 2 events are never spaced by less than a couple of hundred us, and never more than 2 within 1ms... I haven't checked what the buffer depth was on the capture modules of that uC though

[MikeB]

DAQ interrupts after every sinewave cycle, every 1mS at 1kHz, 200uS at 5 kHz. This may change if we/when we have voice done.
PWM - for PPM interrupts once each pulse. It is a PWM controller, DMA can change the duty cycle, not the period. PXX and DSM interrupts twice per frame, once to set the data up, once to start the transmission.
SPI - external eeprom function, Data is via DMA, the interrupt is at the end of a transfer, could maybe wait for flightControlProcess() to finish.
TWI (I2C) - The co-processor may be used for control inputs in future, not defined yet. This needs to complete to free the bus for the 'other' device.
Timer- capture PPM in for trainer, interrupt on every rising edge, therefore every 1 to 2 mS.

The processor has a "system tick" timer that may be useable to run the flightControlProcess(). I'm already using 5 of the 6 normal timers available.

Mike.

[Romolo]

@mike: did you ever had a look to this one ? http://www.coocox.org/CoOS.htm

[MikeB]

Thanks Romolo, I'll give it a look.

Just uploaded a new version of ersky9x. The main change is the addition of a low level driver to handle the SD card. There is no user functionality yet, just a status display that tells if you have a card inserted, and gives details read from the card. There is a 'read block' routine in there as well.

I've nicked the code from open9x to allow moving a switch to set a value in custom switches etc.

The height setting for telemetry in custom switches has changed, as suggested by Cam:
0-64m in steps of 1m
66-192m in steps of 2m
196-448m in steps of 4m
456-872m in steps of 8m

The lowest individual cell voltage is a new telemetry input to the custom switches.
The averaging for the two analogue inputs and the two SSI values is changed.

Mike.

[PNaz]

Mike

I just put in a blank 4gb sd card formatted to Fat 32 and page 9 of Radio setup shows NOT Ready. What is the max capacity and format type for the SD card? 4gb is the smallest I have.

Paul