Menü
Aktuelles
Von:
Filter

Due Portierung (Achtung: nur experimentell)

D

dietmar

New member
Bei der Nutzung des Due kämpft man vom ersten Augenblick mit dem 3,3 V Pegel.

Das kann man umgehen indem man R3 Sensoren einsetzt, aber die sind ja noch nicht für alles vorhanden.

Ein Kernproblem scheint mir die Nutzug des I2C Busses. Nach meinem heutigen Stand ist die wire.h für den Due noch fehlerhaft.

Da man ja für die Kommunikation mit dem Nano via I2C einen Pegelwandler einsettzen muss, hab ich mich gefragt ob man für jeden Nano einen eigenen Pegelwandler nutzt oder ob man bis zum Due einen 5 V I2C Bus aufbauen kann der dann gemeinsam einen Pegelwandler nutzt.

Kennt jemand einen empfehlenswerten Wandler, der auch einfach zu beschaffen ist? (keine Bestellung aus China)
 
Mir ist heute ein weiteres Problem beim due aufgefallen.

Der hat kein EEPROM mehr.
Deshalb müssen die vielen Werte irgendwie anderweitig gespeichert werden.

Ich sehe da folgende Möglichkeiten:

- Nutznung eines externen EEproms
- Speichern als .conf auf einer Speicherkarte
- speichern auf einem Server via UDP oder TCP Verbindung.

Wir können ja weitere Ideen sammeln
 
Hab noch ne kurze Frage, zu den EEPROM Speicherungen.

Welchem Zweck dienen die, Speichererweiterung oder sind das wirklich wichtige Werte die ein Reboot überleben müssen?
 
Ich habe angefangen den Code auf den Due zu übertragen. :unsure:


Zunächst suche ich alle Problemstellen.

Zur Vereinfachung habe ich einiges rausgeworfen, und nutze noch folgende Dateien.

- Ardumiwer.ino
- ardumower.h
- drivers.cpp
- drivers.h
- kit10.h

Der den schweren EEpromfehler habe ich zunächst mal durch auskommentieren umgangen
Deshalb kommt man beim Debugging zum nächsten Fehler


Code: 
In file included from C:UsersDietmarAppDataLocalTempbuild9068075412962512103.tmp/ardumower.h:10,
                 from ardumower.ino:70:
C:UsersDietmarAppDataLocalTempbuild9068075412962512103.tmp/drivers.h:28: error: using typedef-name 'time_t' after 'struct'
f:arduino-1.5.6-r2-windowsarduino-1.5.6-r2hardwaretoolsg++_arm_none_eabibin../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/include/sys/types.h:109: error: 'time_t' has a previous declaration here
C:UsersDietmarAppDataLocalTempbuild9068075412962512103.tmp/drivers.h:33: error: using typedef-name 'time_t' after 'struct'
f:arduino-1.5.6-r2-windowsarduino-1.5.6-r2hardwaretoolsg++_arm_none_eabibin../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/include/sys/types.h:109: error: 'time_t' has a previous declaration here


Beim Versuch das für einen Mega zu übersetzen gibt es keine Fehlermeldung.

Beim debugging für den Due gibt es bei jeder Benutzung eines typedef-name 'time_t' nach einem 'struct' Befehl diese Fehlermeldung. Wenn man die Time Sachen auskommentiert, gibts den Fehler für die PID Sachen, imm da wo ein Typdef Name nach einen Struct benutzt wird.

Hat da jemand eine Erklärung zu?
 
Die Versuche den Code direkt zu importieren erkläre ich für gescheitert.

Der Kompiler macht für den Due leider einiges anders als für andere Prozessoren. :(

Struct funktioniert anders, deshalb funktioniert der alte Code weder für die Zeit noch für die PID Funktionen.

(muss angepasst oder erneuert werden)

Das umschalten auf interne Reference Spannung ist beim Due ebenfalls nicht vorgesehen. Man muss also eine eigene Referencespannungsquelle bauen.

Die Nanos alle I2c Slaves müssen via Pegelwandler eingebunden werden.

So dass die Due Übertragung leider recht aufwendig wird.

Deshalb möchte ich nochmal die Frage nach dem Nutzen stellen.

Ist der Mega ausgelastet? Wenn das nicht so ist, dann gewinnt man nur Idle Zeit :)


Ich werde zwar mit dem due weiterarbeiten, muss aber versuchen viele Dinge selbst zu "erfinden".

Der Code, ich schwitze grad über dem für die Schleifenempfänger, ist leider schwer bis gar nicht nachvollziehbar. Eigentlich wollte ich den auf dem due mitlaufen lassen.

Für ein Community Projekt ist der eigentlich zu spärlich dokumentiert.

Oder gehts bei diesem Projekt mehr um das Basteln (den Zusammenbau)der Hardwarebasis?
Vieles ist darauf ausgelegt alles zu verdrahten, dann einfach den fertigen Code aufzuspielen und dann loszulegen.

Ich würde ab gerne verstehen was die Software macht. Das ist für mich der Kern des Projekts.
Sonst könnte ich ja auch einen fertigen kaufen.
 
Hallo Dietmar,

die allgemeine Funktionsweise des Empfänger-Codes (Frequenz-Filterung etc.) ist ja hier beschrieben: http://www.ardumower.de/index.php/de/anleitungen/2013-11-23-19-50-19/induktion
Der Code des Schleifenempfänger ist eigentlich relativ simpel: ADC für eine bestimmte Zeit samplen und dann die Samples einer Frequenzanalyse unterziehen ( FFT-Algorithmus ). Der FFT-Algorithmus befindet sich in einer fertigen Bibliothek. Beim FFT gibt es für jedes Frequenz-Band ein "Bin" welches den Anteil der Frequenz speichert.

Beispiel: ADC-Buffer mit 5 Khz gesampelt: FFT Bins 20 => ein Frequenzband (Bin) = 5000 / 20 = 250 Hz pro Bin

Bin 0 : 0..250 Hz
Bin 1 : 250..500 Hz
Bin 2 : 500..750 Hz
...
Bin 19 : 4750..5000 Hz


Der Rest sollte eigentlich aus dem Quellcode verständlich sein.

Der Mega würde alle Funktionen evtl. gerade so schaffen (man müsste den gesamten Code stark optimieren) - die Aufteilung in getrennte Nanos hat allerdings gerade beim Prototyping den Vorteil, dass man so schnell nichts "kaputt" machen kann, da alles getrennt läuft... Ziel ist aber (wenn der Code der einzelnen Nanos ausgereift ist), dass alles auf einem Mega oder Due abläuft.

PS: Neuer Empfänger-Code ist bereits in Entwicklung, bei welchem das Grundprinzip ein anderes ist (Polaritätsauswertung mit Matched Filter) und welcher einige Vorteile aufweist:
http://www.ardumower.de/index.php/d...hleifen-sensoren-polaritaetswechselauswertung
Gruss,
Alexander
 
Achso: wenn Du deine bisherigen Arbeiten irgendwo zugänglich machen könntest (so dass wir beide mit SVN oder GIT darauf zugreifen könnten, beispielsweise über Google Code), könnte ich Dir bei der Portierung helfen und wir könnten prototypisch versuchen, den gesamten Code (IMU, Perimeter) auf einem Due laufen zu lassen...
 
Danke, für die schnelle Antwort,

ich bin nochmal ein wenig eingestiegen und hab ein wenig mehr verstanden.

Diese Funktion leider nicht :(


Code: 
void adcInit(){
  /*  REFS0 : VCC use as a ref, IR_AUDIO : channel selection, ADEN : ADC Enable, ADSC : ADC Start, ADATE : ADC Auto Trigger Enable, ADIE : ADC Interrupt Enable,  ADPS : ADC Prescaler  */
  // free running ADC mode, f = ( 16MHz / prescaler ) / 13 cycles per conversion 
  ADMUX = _BV(REFS0) | channel; // | _BV(ADLAR); 
  ADCSRA = _BV(ADSC) | _BV(ADEN) | _BV(ADATE) | _BV(ADIE) | _BV(ADPS2) | _BV(ADPS1); //prescaler 64 : 19231 Hz 
//  ADCSRA = _BV(ADSC) | _BV(ADEN) | _BV(ADATE) | _BV(ADIE) | _BV(ADPS2) | _BV(ADPS1) | _BV(ADPS0); // prescaler 128 : 9615 Hz
  sei();
}


Außerdem kann man ADMUX und ADCSRA auf dem DUE nicht nutzen.

SVN bzw GiT muss ich mir erst zugänge anlegen. Wenn ich das habe schicke ich eine PN.
Ich fürchte das ich doch erst mit dem Nano arbeiten muss :(
 
ÖH, hast du auch einen Link für den 32bit Atmel ARM Cortex-M3

den für die Portierung auf den Due unter Nutzung direkter Programmierung werden wir das brauchen.

ich hab mir nun doch erst einen Nano bestellt, geht einfacher.
 
Hier das Datenblatt für Atmel SAM3X8E ARM Cortex-M3 (Due)
http://www.atmel.com/Images/doc11057.pdf
 
Danke für die Links zu den Datenblättern.

Ich habe in Kapitel 44 des SAM3X8E ARM Cortex-M3 PDFs
die Hinweise gefunden.

Aber das kann ich nicht, oder....... noch nicht
 
Ich habe Dich als Repository-Administer für Google Code eingetragen, Du müsstest jetzt also Deine bisherigen Ergebnisse einchecken können, so dass wir beide Code-Änderungen gemeinsam durchführen können (Check-in/Check-out).

http://code.google.com/p/support/wiki/GettingStarted
 
Due ist anders :) - Hier nur eine Idee wie man bestimmte Dinge evtl. umsetzen könnte:

Perimeter Receiver: ADC muss mit mindestens 2 * 7.8 Khz gesampelt werden - wenn der Due das bewerkstelligen soll (und nebenher auch noch andere ADC-Pins für die Sensoren funktionieren sollen), kann man kein Dauer-Sampling veranstalten, sondern müsste wohl einen Timer verwenden, wo pro Interrupt einmal gesampelt wird.

Als Timer-Lib z.B. https://github.com/ivanseidel/DueTimer#compatibility-with-servoh
Dasselbe Problem wohl für später für das IMU-Modul (GY-80), welches mit 100 Hz die Sensoren (Beschl./Kompaß/Gyro) auslesen muss.

Wenn der Due das mit 20-30% Auslastung schafft, sind der Rest nur noch Kleinigkeiten ;-)
 
Ja, Due ist anders.
Wenn man dur die Arduino Foren schaut, haben das schon viele bemerkt.
Was die wohl geritten hat als sie sich für den Cortex entschieden haben.

Aber er ist die Leistungsstärkste Hardware im Adrdu Bereich. :eek:hmy:

Ich würde vorschlagen, dass wir zunächst mal alle Fallstricke bei der Portierung sammeln.

Ich denke das sich einiges überschneidet und gemeinsam gelöst werden kann.

Ich fang die Liste mal an.

- 3,3 V Problem [gelöst mit einfachem Pegelwandler]
- die bisherigen Verwendung von struct geht so nicht
- Speichern im EEPROM nicht möglich (keines da)
- Umschalten auf interne Referenzspannung nicht möglich (DUE misst gegen die 3,3V VCC)[in Arbeit]
- Direkte Steuerung des AD Wandlers muss geändert werden

Als vorrangig sehe ich das EEPROM Problem und die Überarbeitung aller struct Anweisungen.
Wobei ich den Grund für den Fehler immer noch nicht verstehe. Aber der Compiler nörgelt :sick:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben