ERSKY9X Coding
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
Re: ERSKY9X Coding
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!
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
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: ERSKY9X Coding
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.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: ERSKY9X Coding
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.MikeB wrote: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.
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.
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: ERSKY9X Coding
We are adding optrex display type support in companion9x, then it will be possible to reset it easily.MikeB wrote: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.
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
ERSKY9X Coding
I know the display is incorrect, the default on the eeprom is stock, i have an optrex.MikeB wrote: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.
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.
Re: ERSKY9X Coding
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
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
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
ERSKY9X Coding
Pretty sure you don't need to port it. Linux has most compilers in by default?
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: ERSKY9X Coding
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
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
- Attachments
-
- build_script.tgz
- Build script for yagarto
- (14.17 KiB) Downloaded 366 times
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: ERSKY9X Coding
Companion9x is now updated you can set display type from general settings.cre8tiveleo wrote:I know the display is incorrect, the default on the eeprom is stock, i have an optrex.MikeB wrote: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.
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.
Thanks Leo for highlighting the missing setting.
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: ERSKY9X Coding
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.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
ERSKY9X Coding
Well done
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
Re: ERSKY9X Coding
I found that there is a sd library available on the Arduino.cc pages.MikeB wrote: 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.
http://arduino.cc/en/Reference/SD
Maybe it could help you somehow?
Reinhard
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
Re: ERSKY9X Coding
WTG Mike!! It will be an added bonus for things to come when the sd card is functioning. Very cool.
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: ERSKY9X Coding
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.
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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: ERSKY9X Coding
A big step forward!
Well done Mike! Looks like we have a "killer" transmitter in the making
Well done Mike! Looks like we have a "killer" transmitter in the making
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
ERSKY9X Coding
Great stuff . Looking forward to seeing this in action.
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
Re: ERSKY9X Coding
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
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
Re: ERSKY9X Coding
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
Was it "Build a bettter mousetrap and the world will beat a pathway to your door"?
Something like that anyway
Well done Brent
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: ERSKY9X Coding
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.
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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: ERSKY9X Coding
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
-Gohst
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: ERSKY9X Coding
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.
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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: ERSKY9X Coding
That.gohsthb wrote:Couldn't you make flightControlProcess() an interrupt that is called by a timer?
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.
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...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.
If it's so bad... isn't there enough RAM to buffer the "live" settings?
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: ERSKY9X Coding
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.
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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: ERSKY9X Coding
Would make sense...
What are the other important interrupts?
What are the other important interrupts?
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: ERSKY9X Coding
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.
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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: ERSKY9X Coding
Hmm...
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
Wasn't that running off a DMA?MikeB wrote: DAQ - audio
OK, that's quick too anywayMikeB wrote: Timer - provides 5mS and 10mS time ticks and calls
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 asynchronouslyMikeB wrote: PWM - controls the PPM/PXX/DSM output signal
Do those need interrupts? The EEPROM won't mind if it's sent a byte 2 seconds later than the previous one...MikeB wrote: SPI - external eeprom function
TWI (I2C) - Volume and co-processor
MikeB wrote: 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
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: ERSKY9X Coding
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.
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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: ERSKY9X Coding
@mike: did you ever had a look to this one ? http://www.coocox.org/CoOS.htm
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: ERSKY9X Coding
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.
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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
-
- Posts: 142
- Joined: Tue Dec 27, 2011 5:28 pm
- Country: -
- Location: Kaleden (Twin Lake), British Columbia
Re: ERSKY9X Coding
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
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