ERSKY9X Coding

[cre8tiveleo]

I'd test it, if I had a board..

Very nice work so far.

[MikeB]

OK, new version of code is committed, I've tested PXX, it works fine. The DSM signal looks OK to me, but needs real testing by someone with a prototype board and DSM module if possible.

Mike.

[MikeB]

Just found and fixed abug in the applet for reading the external serial eeprom. I've updated the zip file in:
viewtopic.php?f=7&t=40&p=2766#p2766
with the fixed version.

Mike.

[MikeB]

Sorry! I found another bug in the serial flash applet, I've updated the zip file again. I think its correct now.
Mike.

[Clivew]

It takes a lot to get me excited these days.
This project does it for me

[MikeB]

Testing continues, I've got the Bluetooth interface running, nothing useful, but enough to prove it works!

Mike.

[cre8tiveleo]

It takes a lot to get me excited these days.
This project does it for me

Excited?




(click the picture)

[MikeB]

I've just committed the latest sources with the completely new file system. So now we have 4K for the radio setup and 4K for each model. I've left it at 16 models, we could have more.
I have been testing this, it seems to work OK, but there may be the odd teething trouble.

Before we go too far with people configuring models, we might want to consider extending the model structure. With the power of the ARM processor, we might seriously consider extending the number of mixers from 32 to, say, 48 (or maybe 64), and/or adding some more 'spare' bytes for future expansion that does not then cause the model structure to change.

Note: eepe does not work with ersky9x.

Mike.

[cre8tiveleo]

It would be good to go with a format that wouldn't change , and would give the best expandibility. 48 mixes, then extra bytes for assigning image name (useful with the bt module, have a data base of your planes on your bt enabled smart phone, select a model, bt then instructs the tx to load up that model. Or , you select the model on the tx, and the bt calls up that image onto your bt enabled smart phone from a data base, so you see the model that's being selected.)

Go the max, as you said, to keep model structure semi cohesive with updates to the firmware and options.

SAM-BA loader? Is there a particular version we need, I run winblows 7. \;D

[Kilrah]

It should be dynamic, no?
ER9x is already pretty dynamic in the sense that model size varies depending on content, mixes are added only when needed,...

I'd have thought there wouldn't be such a thing as "32 mixes", but that each model would have a limitless array of mixes that could hold anything whether 0, 32 or 163 items until the model's memory is full...

Ideally same would be for models instead of having a 4k or other arbitrary limit, but I agree that's more complicated to handle dynamic memory allocation at that level.

[MikeB]

I think there is only the one version for windows, I've got V2.11 (on W7).
Check here viewtopic.php?f=7&t=40#p2766 for setup info for SAM-BA specific to the ersky9x board.

I'll put the executable(s) up on the ersky9x code page later, so you won't have to compile it, just need to sort out how to deal with the choice of display (stock or Optrex).

Mike.

[MikeB]

@kilrah, that sort of thing will require quite a bit of work to have dynamic allocation of both RAM and EEPROM storage to handle an arbitrary number of mixers. It would be a major re-write of a lot of the code.
Actually er9x is static, each model has 32 mixers. The only dynamic bit is there is some data compression done when storing each model. Blocks of zero bytes are coded in two byes. This makes it appear dynamic, but a 'full' model needs over 600 bytes of EEPROM to store, so you can only store 3 'full' models, not 16.
For now, ersky9x does not use any compression.

Mike.

[MikeB]

The executable file is now on the repository, I've made the Optrex display a menu option, it displays a black bar down the left, but still lets you get to the menu to select it. This way we only have a single executable, instead of compile time options.

There is a new(ish) setup menu, use LONG LEFT to get to the 'normal' setup menu, then RIGHT takes you to the new menu where you can set volume, backlight brightness, and now select the display type.

Mike.

[cre8tiveleo]

Thanks Mike!

[PNaz]

I have my ersky9x board installed and working. I can't update the firmware with SAM-BA v2.11. I have changed the file boards.tcl as per Mike's instructions and added the sub-directory at91sam3s2-9x with its files to the directory tcl_lib. The USB port has the correct driver. When I run SAM-BA I get the initial menu and select the serial-USB port correctly then select the board at91sam3s2-9x. I don't get an extra tab labelled SerialFlash so can't select the enable_serial_flash script. Pressing the Connect icon gives me a Connection Error warning and the program quits. The 9X transmitter has USB on the screen. I am running Windows 7 and I also tried it on my wife's Windows XP machine with identical results.

Paul

[MikeB]

If you go into 'Devices and Printers' have you got an entry for 'AT91 USB to Serial Converter (COMx)'? (x is a digit).
The extra tab is on the main SAM-BA screen, you don't appear to get to that.
What is the warning message you get? It might help work out what is happening.
You can check if the 9x USB is connected if you have a terminal program. Connect to the COM port specified in the 'Devices and Printers' above at 115200 baud, 8 data, 1 stop bits.
Type:
T#
You should get a > symbol back.
Now type:
V#
The boot loader will send a version information string.
If this works, then the USB is connected correctly and all drivers are working OK.

Mike.

[SkyNorth]

We need to get the file updated , the chip you have is a at91sam3s4.

Mike and I have boards with the at91sam3s2

unzip this in the tcl_lib directory.

Run Sam BA
you should now have "at91sam3s4-9x" board selection in the box.


The other option is do nothing and select "as91sam3s4-ek" This will let you program the board , but not allow you to access the EEprom applet.

To load a new version , enter the new file name into the "send file name" box , and hit the send file button ...when it asks you if you want to lock it
select "no".
If you do lock it , or select the wrong program , the chip can be reset to factory default buy shorting out the ERASE jumper and powering up the board.
This allows you to recover and try again...

-Brent

[MikeB]

New sources uploaded, and a new binary on the downloads tab. At the moment, I think the download is the only place to put the binary, because it is a binary (not hex) file. Anywhere else and you don't appear to be able to download the entire file, and SAM_BA needs a binary file.

Mike.

[PNaz]

I loaded the new file at91sam3s4-9 and that worked. I got into the main program and tried flashing the latest binary. It didn't seem to load. I still had the 13 March code in the transmitter. I tried the erase pins and then the transmitter would not respond to the power button. The power stayed on and I could do nothing with any of the switches. I removed the battery and reconnected it. The transmitter seems dead, no screen, or beeps. Tried another erase and nothing. Reflashed the binary and compared the file to the memory. Comparison Result is "Sent file & Memory area content (address: 0x400000, size: 63680 bytes) match exactly !" so something is working in there. Transmitter is still dead when I turn it on. The voltage regulator is putting out 3.3 V.

Paul

[MikeB]

Nearly there! When you have done an ERASE, it also erases the configuration to allow booting from flash so it always runs the USB rom code. On the SAM-BA screen, near the bottom, isan area labelled "Scripts". The selected script defaults to "Boot from Flash (GPNVM1)". This is the one you need, just press the execute button. You will then have set the provessor to run the loaded program in flash instead of the USB boot ROM.

Mike.

[PNaz]

Thanks Mike
That got it working again.

Paul

[MikeB]

It seems the compiled code for the ARM is larger than that for the ATMEGA. This is probably due to needing to use 32 bit addresses to access memory, and there is no direct addressing mode. A 32 bit register needs to be loaded in 2 16 bit operations, and then used to access memory. Some of the code may be worth re-structuring, but at the moment we have enough flash so it is not yet important.

Mike.

[MikeB]

r39 is now available for download. The option to choose between the stock buzzer and the speaker is now in, If you choose 'Speakr' then a 2kHz tone will be sent when you press keys etc (i.e. when you got the buzzer sounding before). If you don't hear anything, check the volume setting in the SETUP2 menu (RIGHT from the original SETUP menu).
I'm looking at getting the full audio from er9x in, might manage it this weekend.

Mike.

[Rob Thomson]

Right Mike...

Audio wise.. I have just added a small patch to the code to allow the frequecy to scale correctly on the trim sticks.

Having played with the sounds... what is not working well is 'scaling' sounds.

So... start at freq 10; and scale up to 60; over 5 seconds.

All the 'single tones' work no problem at all.

I am guessing this is something different in the driver you made?

I will have a little time to look at this all again tomorrow - and after that will be post the easter w/end. If you do happen to have a speaker plugged in to yours.. the easy test is the frsky alert called 'siren'. This is supposed to go.. woop woop woop. (a siren). But curently does a bleep fizz pop splat

Code looks easy enough to follow - much the same as er9x. Somehow you have managed to magic in a new sub system - good work all round and definitly a beers on me when we next see each other!!

[MikeB]

Please keep an eye on the code as you look through it. When porting it across I sometimes commented out bits that I coudn't immediately get working, some things may still be commented out that are now OK. This applies to some of the audio as that wasn't working until recently.

The code size is quite large, but I haven't used the 'optimise for size' compile option yet, I wanted known working code I could follow. I tried that option, it chopped around 10K off the code size, but I didn't flash it so I don't know if it would have worked!

Speed is not an issue either, it is plenty fast enough, and there is enough hardware in the peripheral that no interrupts are time dependant. They also have different priorities so important interrupts automatically interrupt lesser ones.

Mike.

[Rob Thomson]

Yup. A spotted the commented out stuff. Assumed you had done exactly as you said!

If you can get a low level haptic driver done - I will pick up the interfacing bits?

I was going to look into options on how to extend the audio to work in an open9x way

- although maybe Bertrand would be up for this?

He has already solved the logic to will probably be quicker for him!

Either way - not likely that I will get time before next week.


Sent from my iPhone using Tapatalk

[MikeB]

Just built and testede the code with size optimisation turned on. The binary is now much smaller, but seems to run OK. It is a bit slower, main is now reporting 1.30mS instead of 1.12mS. Er9x reports 6.1mS for the same operation!.

Rob: I'll look into providing a haptic, low level driver. I'll provide 2 routines:
hapticOff() and
hapticOn( time, pwmPercent )
time in units of 10mS, pwmPercent as 0-100

Mike.

Edit, on second thoughts:
hapticOn( pwmPercent )
pwmPercent as 0-100
I'll leave the time to the upper level code

[Rob Thomson]

Lovely . Let me know when done.


Sent from my iPhone using Tapatalk

[MikeB]

Just committed the low level haptic code (in sound.cpp). Also changed the startup code so it starts off. I haven't updated the .bin, no point until the upper functionality is there.
COM2 on the board is available for debugging (9600,n,8,1). Send 'H' and the haptic will be turned on at 40%, 'I' turns it off. The code for this is in debug.cpp, so you could change the 40% for testing.

Mike.

[MikeB]

For those interested I've just committed the serialflash applet sources. I've cut down the Atmel supplied headers and used the minimum possible to get it to work.

Mike.