SD-Card for Models/Logging on Stock Board

[derFrickler]

Hi, it it possibel to use the SD-Card mod on the stock-board as it is described on the radioclone documentation with open9x?

http://sourceforge.net/apps/mediawiki/r ... e:build_SD

My eeprom is allready full with some models and kopters with a bit complex programming.

[bertrand35]

No it's not possible for now. I will have a look to the link and see if it will be possible in a next future ...
Bertrand.

[Rob Thomson]

I believe that mod used the telemetry pins. So not really a viable option.


Sent from my iPhone using Tapatalk

[derFrickler]

Yes, right, i forgott that, Miso and Mosi are used for telemetry.

So i will wait for the FrSky X12D i guess...

[bertrand35]

I believe that mod used the telemetry pins. So not really a viable option.


Sent from my iPhone using Tapatalk

For these pins we have the EXT option EXT=FRSKY EXT=ARDUPILOT ...
We could have EXT=SDCARD

But I have to read more, I don't know how it's possible to have the FatFS embedded in the 64A!
Bertrand.

[bertrand35]

Yes, right, i forgott that, Miso and Mosi are used for telemetry.

So i will wait for the FrSky X12D i guess...

If you have already FrSky on these pins, you may forget it, yes!
Bertrand.

[Rob Thomson]

But the only real use for logging is for telemetry... So having ext=sdcard would remove telemetry... Making the whole thing pointless?


Sent from my iPhone using Tapatalk

[bertrand35]

He first said that it was in order to store more models
Bertrand.

[Rob Thomson]

Aha! I assumed it was for logging!


Sent from my iPhone using Tapatalk

[Kilrah]

Yes, right, i forgott that, Miso and Mosi are used for telemetry.

Actually they aren't, but it's a little confusing...

Here for the SD card we're talking of the on-chip SPI interface, that uses PB2-PB3-PB1-PB0 as MOSI-MISO-SCK-nSS respectively.

The RXD-TXD lines used for frsky are PE0-PE1, and have nothing to do with the onboard SPI. BUT, they're used for in-system programming, AND as ISP is one with SPI signals, then they're also called MISO and MOSI. But that's only relevant to flashing!

So it would be possible IMO.

The FAT driver used in radioclone looks pretty lightweight. There would still be the solution of using raw memory blocks without FS if it was too much. No reading with the PC, but that shouldn't be a problem, once models are setup for good transfer them from eeprom to SD.
Or m128 upgrade?

[derFrickler]

Thanks for your answers.
Is there any other option on how to get more models on the open9x by removing some firmware options (but this is flash only, not eeprom...) or something else.

[bertrand35]

Simple answer... Why don't you backup some models on the computer with companion9x?
The only options available today that I would suggest: m128 upgrade (30 models) / gruvin9x upgrade (30 models) / sky9x upgrade (60 models).
Bertrand.

[derFrickler]

Storing models to the computer is my current solution, but then i have to upload the models before i go to the field, this is not the perfect option.

m128 Upgrade means "just" replaing the m64 processor with an m128? Does open9x work for this or do i need to compile it on my own?

By the Way, i just checked back the radioclone SD-Card Mod and now i got what kilrah explained above.
On the m64 the ISP Pins actually do not use the MISO and MOSI pins of the processor, but in every 9x ISP or Telemetry pic. these pins are stated to be MISO and MOSI.
So from the wiring issue the SD-Card mod goes together with the telemetry mod:
http://sourceforge.net/apps/mediawiki/r ... install_SD

[xnalpf]

Just had a quick chat with der-Frickler on this topic. Fact is that TX/RX for the Telemtry Mod actually are Pins2&3 which is PDI and PDO for the ISP interface. So only "collides" with flashing the Firmware. PDI and PDO are connected to the pins called MOSI/MISO on your ISP progger but this is due to the fact that smaller Atmels combine ISP/SPI thus the naming confusion. The m64 has a seperate SPI Interface which is a Serial Peripheral Interface for e.g. Serial EEPROM etc. This one should be usable for a SD Card interface. But talking about serieal EEPROM one might consider this as the best solution. Serial EEPROM is very cheap with capacity of up to 64kbit which is 8kb extra model memory. This is in total five times of the initial capacity and should be enough for most users. Interfacing serial EEPROM ist quite simple and code is available all over the net. Data structures could be just the same as for internal EEPROM storage so no need to use complicated FAT and SD code.
I must admit that this is no option for telemetry logging though. This would only be feasible with the SD card interface. So challenge would be to offer both solutions. SD card or SEEPROM AND telemtry.

[Kilrah]

m128 Upgrade means "just" replaing the m64 processor with an m128? Does open9x work for this or do i need to compile it on my own?

open9x support in makefile has been added, but untested at this point (I have 5 m128s on my way, ordered them last thursday after suggesting the addition). It works in the simulator. Should be able to give news in a few days, then companion9x/compilation server should follow as a new "official" version.

By the Way, i just checked back the radioclone SD-Card Mod and now i got what kilrah explained above.
So from the wiring issue the SD-Card mod goes together with the telemetry mod:
http://sourceforge.net/apps/mediawiki/r ... install_SD

Hmm, just a detail, the pin he uses as CS is one of those used for rerouting the THR/AIL switches along with the frsky mod, so it might be preferable to use another pin... now which one is the question. With the voice module one could use the spare line, otherwise maybe some choice might have to be made (for example sacrifice haptic or backlight control).

[derFrickler]

Hey, m128 support sounds great, i think i will try that once it is is in copmanion, seems like the easiest solution for me ;_)

[Kilrah]

Is there any other option on how to get more models on the open9x by removing some firmware options (but this is flash only, not eeprom...) or something else.

No, as any setting that is left to default in the model setup doesn't use any eeprom due to compression.

One thing worth doing is reviewing each of your models in C9X. Due to an error in eeprom conversions long ago I had some stray values around. For example, some trim values for flight phases I never used weren't zero. Setting them back to 0 saves 2 bytes of eeprom per value. I don't use the ppmca option, but had some values that weren't 1500, and were using eeprom too. Check that as well. Also check you don't have anything (mixers, telemetry settings, custom switches,...) that you don't use, for example I had once set min/max settings for telemetry bars on a model, then disabled it by setting source to "---". The min/max setting are kept and use eeprom, so setting them back to zero will free some.
These won't show up easily on the radio (you won't see flight phase trims unless you set a switch to activate that phase and turn it on), but on c9x you have a good overview, even disabled settings are visible so you can see if they're not zero, enable them just to set them back to 0, and disable them again (the telemtry bar example).

Also the way you program things can affect a little. For example, if you have too much throw on your rudder, it will take less eeprom to reduce the weight on your RUD mixer than to create a D/R line with the lower value and no switch. Instead of creating 2 D/R lines for elevator, a "default" one at 70 and a "reduced" one at 50, you'll use less eeprom by setting mixer weight to 70%, and having only one D/R line at 57%.

I saved more than 200 bytes of eeprom by doing that the other day

[derFrickler]

Yes, i allready did this, disabled most of the telemetry screens i do not use, simplified some mixers and removed unused switches, will check the other stuff you requested!

...my Hangar is just to big and every model i use more often i want to port from the FX-18 to the 9x, so i do not have to carry and care about two Transmitters
http://der-frickler.net/modellbau

[Kilrah]

Wow!
I think the SD card is needed then, m128 won't be enough

However I guess IF SD was implemented, it would require m128 too just because of the amount of code needed to use the SD...

It's too bad because a few years ago I used a very simple solution called DOSONCHIP, Sparkfun made a small module with a microSD card slot and a chip that included all the FAT stuff, all you needed was to send it simple commands to open/close/read/write and it did all the complicated job. That would have been a good solution for the 9x, but this thing was discontinued a couple of years ago

[jhsa]

maybe there is something similar?? something like that could maybe be used also with the M64?

[MikeB]

Don't forget the TelemetrEZ board in development. This has an ATTINY1634 on it, providing the telemetry interface easily. It is also going to support the connection of a rotary encoder, but neither of these uses a lot of its flash up (16K available). While the pins for hardware SPI are used by the serial ports doing the telemetry, it could do a SPI on spare pins using bit-bashing. We might be able to put a serial EEPROM, or an SD card on it, the main problem for the SD card would be it only has 1K bytes of RAM.

Mike.

[jhsa]

obviously people that don't have the telemetryEZ and have all the mods done, would have to undo everything and get the board if they wanted SD Card?

Option number 2:
get an atmega 128 and replace the mega 64?

Option number 3: I'm not saying it, because it is too obvious..

[Rob Thomson]

There is always option four?

The new X9D, X12D, X16D by frsky... and of course whatever turnigy flysky happen to release?

But those are all unknowns

Rob

[jhsa]

right..

[MikeB]

obviously people that don't have the telemetryEZ and have all the mods done, would have to undo everything and get the board if they wanted SD Card?

No, you could leave the wires/resistors to the cpu pins, just remove the RS2323 to logic converter and put the TelemetrEZ board in instead.

Mike.

[jhsa]

but aren't the switches also handled by the Ez board?

[MikeB]

Yes, but they get disconnected from the main board when you connect the TelemetrEZ board in, that's part of the neat design.
It doesn't matter whether you have the telemetry mod done on the main board or not.

Mike.

[DAVEC921]

Ok I am trying to follow all of the talk about all of this.
I am handy with a soldering iron but coding I am hopeless.
What is the atmega 128 chip suppose to replace on the stock 9x board. I feel I would be able to do the switch out but one I do how much would I have to try on the codeing or would I just need to reload ER9X.
Thanks for info.
DAVE

[xnalpf]

Wow!
I think the SD card is needed then, m128 won't be enough

However I guess IF SD was implemented, it would require m128 too just because of the amount of code needed to use the SD...

It's too bad because a few years ago I used a very simple solution called DOSONCHIP, Sparkfun made a small module with a microSD card slot and a chip that included all the FAT stuff, all you needed was to send it simple commands to open/close/read/write and it did all the complicated job. That would have been a good solution for the 9x, but this thing was discontinued a couple of years ago

A breakout board holding an abstract external memory sounds like a smart solution. Interfaced via the SPI (not the ISP!) connector it could either hold EEPROM, SD or any other flash or even non-flash memory accessed vie a standardized protocol. This might even be exchangable so might think of it as "memory cartridges" the user can exchange on demand.

[Kilrah]

What is the atmega 128 chip suppose to replace on the stock 9x board. I feel I would be able to do the switch out but one I do how much would I have to try on the codeing or would I just need to reload ER9X.

The idea is :
- Remove the existing processor
- Solder the new one in place
- Set fuses with companion9x
- Flash the m128 version of open9x.

No coding to do.