Ich hoffe man kann etwas Erkennen

Hi,
@Martin:
Danke
Hat nix mit Intelligenz zu tun: Arbeit und Hobby haben sich einfach gut ergänzt
und in Design, CAD, und Windows-Sachen bin ich auch ein Idiot

@Thomas:
auch Danke

Die Knüppel und 4 weitere (wichtige Realtime-Funktionen) AD-Kanäle gehen direkt auf das Main-Board,
das hat den entscheidenden Vorteil, das alle wichtigen und Sicherheits-Relevanten Funktionen auf einem
Modul sitzen, und nur auf einer CPU laufen.
Im Prinzip kann alles andere rundherum ausfallen , und das System läuft trotzdem Sicher weiter.

Hab mir auch überlegt, die Mixer-Schalter und Regler, über I2C an das SPI-Board zu hängen,
dann ist man in der Anzahl von Schaltern/Reglern nicht so begrenzt.

Das mit dem Touchscreen-Bedien-Elementen (Fahrwerk, Scheinwerfer, Gyro) kann per Seriell,
vom PDA zum SPI-Board gesendet werden und von dort, per SPI, zum Main-Board (genauso wie die Konfigurations-Daten).

Für alle die mal schauen möchten, wie das Frontend aussieht, hab ich mal eine Live-CD (Linux-Boot-CD) gebastelt.
Startet leider nicht auf jedem Rechner (nur im Text-Mode), ist aber in QEMU getestet.
Wer hat, kann mir ja mal mitteilen, ob es auch in VM-Ware funktioniert.

Live-CD (MTX-Frontend)


DannBisDann

Olli

Achso (fast vergessen) : Wunschliste für die, die sie noch nicht kennen




PS: Danke an das RC-Line Team für das schöne Forum

Hi Space,

Zitat

...das ISO läuft als VM

Cool, Danke


Wenn ich mir das so recht ansehe, ist in meinem Pre-Mixer noch ein Denkfehler drin.

Im moment werden alle Premixer untereinander gemischt:

z.B.
wert1 = adc1;
wert2 = adc2;
wert1 = wert1 + (50% wert2)
wert2 = wert2 + (50% wert1)

Hier ist auch der Denkfehler: wert2 ist am ende nicht ( wert2 + (50% wert1) ) sondern (wert2 + (50% (wert1 + (50% wert2))))

Cool: erster offizieller Bug
Mus aber dazu sagen, ich hab ihn (PreMixer) bis jetzt noch nicht benötigt.

Der Post-Mixer ist besser

z.B.
wert_IN1 = adc1;
wert_IN2 = adc2;
wert_OUT1 = wert_IN1 + (50% wert_IN2)
wert_OUT2 = wert_IN2 + (50% wert_IN1)
ppm1 = wert_OUT1
ppm2 = wert_OUT2

Keine Angst, im echten Quellcode sind das alles 7Punkt Mixer

Zum Thema Auflösung: PDA = 320x240

Sorry,
die ADC's laufen mit 10bit (AVR Intern), die Knüppel-Potis arbeiten aber leider nur in einem Teilbereich (vielleicht eine Vorstufe mit OpAmps bauen ).
Um ein Speicher-Überlauf zu verhindern, ist die Premixer-Ausgabe (integer Variable), auf +-1023 (12bit) begrenzt.

Der PPM-Encoder ist im Moment auch noch auf +-600 begrenzt (kann das ~10fache) .
Der serielle FMS-Ausgang ist 'FMSPIC' Kompatibel und dadurch auf 8bit limitiert (reicht zum Simulieren).
Über ein 2,4Ghz xBee-Modul kann der komplette 12 Wert übertragen werden.

Gerechnet (Mixer-Intern) wird mit mindestens 16bit (Integer-Variable),
im Input-Bereich auch mal mit Flieskomma (für Expo).

Kann auf jeden Fall noch einiges Verbessert werden,
aber es bietet schon eine geeignete Hart- und Software-Basis.

Und es Funzt (eh Funkt) .


DBD
Olli

Hi Björn,
Der PDA würde nicht in die EVO passen

Im Moment würde ich sie noch nicht als Haupt-Anlage benutzen,
Bis auf den Pre-Mixer funktionert zwar alles,
es sind aber noch nicht alle erwünschten Funktionen Implementiert (Scanner, LS, ...).
Hab auch noch kein Platinen-Layout für das neue SPI-Board (mit ATmega644).

Aber diejenigen die ein wenig rumspielen möchten,
können die Mainboard-Firmware auch auf einem Development-Board (ab mega16) laufen lassen,
und entweder ein HF-Modul oder an einen Simulator anschließen (mixer müssen dann halt im Quellcode geändert werden).
Oder man hat noch ein 2. AVR-Board (als SPI-Board) und hängt seinen PC als Konfigurations-Frontend an das SPI

Mich würde es natürlich freuen, wenn jemand schon den aktuellen Stand nachbaut,
um beim Entwickeln zu helfen (oder einfach aus Spaß).
Wenn mal was geändert wird, dann im Rahmen von ein Paar Euro (< 15Euro / PDA, HF und Knüppel bleiben )

Wer Lust hat kann auch gerne mal versuchen ein Frontend auf AVR Basis zu bauen (LowCost-Version ohne PDA / Basic oder C, mit oder ohne LCD , Tasten oder Drehencoder, alles möglich),


Kosten Übersicht (PI * Daumen ):

Main-Board:
AVR ATmega-644 7,00 Euro
Sonstiges (Wiederstände, Transistoren) 5,00 Euro
Platine ab 1.00 Euro
---------------------------------------------------------------------------------------
ab 13.00 Euro

SPI-Board:
AVR ATmega-644 7,00 Euro
Sonstiges (Wiederstände, Transistoren) 5,00 Euro
Platine ab 1.00 Euro
---------------------------------------------------------------------------------------
ab 13.00 Euro

Frontend:
PDA (Linux-Tauglich mit Seriell-Port) ab 40 Euro (bei eBay)
---------------------------------------------------------------------------------------
ab 40.00 Euro

Sonstiges:
Gehäuse mit Knüppel 20.00 Euro (Gebraucht / Eigenbau)
HF-Modul (27/35/40/72 Mhz) oder xBee(Pro) (2,4 Ghz) 30-100 Euro
Sender-Akku (2-3S Lipo oder 8NC) 20 Euro
Schalter, Regler, Dreh-Encoder, ... 10 Euro
---------------------------------------------------------------------------------------
ab 80.00 Euro

Optional:
Sim-Connector:
Buchse oder USB-Serial-Converter 1.00 - 20.00 Euro

Lowcost-Telemetrie:
433Mhz Pollin-Modul 5.00 Euro

LS + Scan:
ATmega8 3.00 Euro
ACT-Scanempfänger (nur LS auch ohne scan möglich)
Kleingram

Head-Tracking:
ATmega8 3.00 Euro
Kleingram

---------------------------------------------------------------------------------------


DBD
Olli




PS: Generell funktioniert sie aber schon so wie sie im Moment ist (Pläne, Layout, Code)

HI nochmal,

Die Abmessungen des PDA's (iPaq 36xx):
Display: 60x80 mm
Gehäuse: 80x130 mm

Die Elektronik aus dem Gehäuse auszubauen kann problematisch werden (hatte danach Probleme mit dem Touchscreen), es ist sowieso praktischer den PDA für große Setup's aus der Funke nehmen zu können.

Sonstige 'mögliche' Frontend-Hardware:
Bedingung (für die aktuelle Software):
Linux-Support inkl. GTK
Serieller Port
Maus/Trackball oder Touchscreen
ARM-CPU oder neu kompilieren (Cross-Compiler benötigt / OpenEmbedded)

Beispiel Produkte (Ungetestet):
TomTom Navi's (OpenTom )
Sharp-Zaurus, iPAQ h3600, h3700, h3800, h3900, h5400, and h5500 / Siemens Simpad (Familiar )

Aber wie oben schon erwähnt, ist es auch möglich sich ein eigenes Frontend zu Programmieren:
z.B. eins für Win(CE/Mobile) (kein Support von mir ... vielleicht mit viel betteln )
oder auf AVR bzw. PIC Basis (2,5Zoll-Display / Danke an Wurpfel) .

Wer es Richtig Dekadent braucht, kann auch ein EeePC (UMPC) mit Touchscreen einbauen (7-10Zoll, 3D-Beschleunigung, WLAN, Bluetooth, Kammera ), da passt dann auch noch ein Simulator drauf

Oder halt per Laptop,
möglich ist einiges, Hauptsache mit Seriell-Port.

Whooow ,
sieht aus wie für uns gemacht

Meinen Segen hast du

DBD
Olli

PS: Hätte gerne mal ein größeres Bild

Hi Ralf,

Zitat

ich habe mir mal Deine Live-CD 'runter geladen und etwas damit gespielt. Nach dem das Thema Pre- und Post-Mixer ja schon angesprochen wurde, muss ich leidermal ganz blöd fragen: Wo ist denn da der Unterschied bzw. wofür wird das gebraucht?

Um gemischte Werte (im Pre-Mischer) in einer 2. Stufe nochmal mischen zu können (Post-Mixer).
Ich hab im Moment nur Post-Mixer genutzt, und hab den Pre-Mixer noch nie benötigt.
Vielleicht hab ich auch einfach einen Denkfehler in diesem Aufbau, aber ich glaube man kann ihn noch gebrauchen.

Zitat

* Ein Modell mit 2 Querrudern braucht dann 2 Mixer? * Wenn ich die als Landeklappen hoch fahren will, wieder 2 Mixer?

Wollte das System möglichst generisch gestalten, daher wird alles über freie Mixer gemischt.

Zitat

von Fabian auf der Wunschliste:
*Wirklich absolut frei, so dass ich z.b. alle vier Knüppelfuktionen aufs Seitenruder legen kann, wenn ich gerade Lust dazu habe nuts

Ist zwar aufwendiger in der Konfiguration, bietet aber alle Möglichkeiten,
jeder Weg ist per 7-Punkt Kurve justierbar.

Damit der Aufwand sich in Grenzen hält, hab ich ein Template-System eingebaut,
zum Laden einer Grund-Konfiguration (Heli, Segler, Shocky, ...).

Wo wir schon mal bei Generisch sind, der PPM-Encoder ist es auch.
Erste Funke die Standard und Walkera kann .
Des weiteren lässt sich der Encoder auch High-Speed Trimmen (4Kanal, 1,2ms Mittel-Stellung, 4ms Sync)

Zitat

Dual Rate ist ja eine Wegbegrenzung in zwei Stufen, wie schalte ich die zweite Stufe ein/aus

Ausrede: Version 0.2
Wirklichkeit: Hab vergessen die Schalter mit dem DualRate zu verknüpfen .

Zitat

Wenn ich bei einem Geber einen Name vergeben habe, woher weiss ich dann nachher, welcher Geber es dann noch ist? Oder hängt das von der Reihenfolge weiterhin ab? Das gleiche gilt bei den Namen für die Servos.

Die Reihenfolge wird erhalten.

Zitat

Beispiel: Bei Multiplex sind die Geber auf dem Gehäuse bezeichnet mit A/B/C/D. In der Software weise ich dann dem Geber A die Funktion Höhe zu, diese Zuweisung wird auch weiterhin visualisiert. Könnte man hier auch so machen.

Gute Idee, wird eingebaut

Zitat

Ansonsten habe ich eine weitere Möglichkeit für ein weiteres Frontend gefunden: http://www.toradex.com/01_Products/01_Colibri_Modules, dazu gibt es im Webshop ein kleines LCD mit Touchscreen. Die Preise sind auch recht interessant, und es gibt dazu ein Linux System.

Cool, kannte ich noch nicht, der kleine (206 Mhz / 79 Euro) recht völlig aus.
Nur leider benötigt man erst einmal ein 'Evaluation Board',
dann noch das Display (110 + Adapter, ...) und, und, und ....
Unter 500 Euro geht da NIX.
Aber wenn du magst, ich helfe gerne

DBD
Olli

PS: Bitte weiter so
ich bin kein Profi-Pilot, übersehe mal, für andere wichtige, Basis Funktionen.

Hi Hilmar,

zum Verlieben, dein Gehäuse

Durch den großen Display-Ausschnitt hat man auch genügend Freiraum für verschiedene Frontends.
Ein Zusatzdisplay finde ich auch sehr gut, vor allem auch umsetzbar (wenn nicht gerade Rund / kleines LCD am SPI-Board)
Ein paar mehr Schalter/Regler würde ich mir Wünschen
Ansonsten einfach nur Genial


Vielen, vielen Dank
Olli

PS: ich glaube ich nimm die in Grün

EDIT:
-----------------------------------------------------------------------------------------------------------------------------
Updates:
Main-Board: Quellcode etwas aufgeräumt und Initial-Support für Nautic/Multiswitch-Module

Damit man mal sieht was in der Funke so ab geht !!!

Natürlich im Fontend integriert



Was da gerade gemischt wird ist totaler Quatsch (war nur zum Testen)
Das rechts im Bild ist der PPM-Pulse.
Die Limiter sind auch neu




PS: neue Live-CD kommt bald

Hi Leonardo,

Zitat

Was ist wenn ich mit meinem Boot gar nicht nicken oder rollen will

Dann Herrscht Linearität :



Mann könnte aber auch die Lenkung mit dem Bugstrahlruder Mixen (nur so zum Beispiel)

Für Funktions-Modellbau, hab ich bereits einen Nautil/Multiswitch Software-Encoder eingebaut, der
nur noch im Frontend integriert werden muss !

Gibt es irgendwelche Spezial-Funktionen für Boote

Als alternativ Gehäuse würde ich auch noch ein Pult-System vorschlagen (vielleicht aus ALU)

So etwas in der Art:




DBD
Olli

Hi Ralf,

Zitat

Was hälst Du davon, das gleiche für die Servos zu machen: 1: Speed 2: Nick usw.

Hab es nur in der Visualisierung vergessen,
ist aber genau so schon Vorhanden

Zitat

Hast Du schon mal über Spline Funktionen statt "einfacher" Polygonen bei den Mixerfunktionen nachgedacht?

Ja, aber die armen 8bit-Atmel's ,
außerdem Ich hab kein Plan von Spline's
Kannst ja mal schauen wie man so etwas rechnen würde (7-Punkt-Kurve).

Zitat

Wieviel Parameter übergibst Du eigentlich bei einem Modellwechsel an den ATmega? Ich habe mal so 600 abgeschätzt

könnte aber hinkommen

Zitat

Ach, und was ich schon länger fragen wollte, hast Du bei Deinem Sender keine Trimmungen?

Also, am Anfang (siehe Avatar / Depron-Gehäuse) waren da die mechanischen Trimmer an den Knüppel'n,
Im Neuen Gehäuse (Holz) wollte ich schon mal auf Digital umstellen, hab aber noch keine Tasten/Encoder eingebaut .
Ist aber per PDA/Software möglich !

Zitat

Ich bin auf die neue Live-CD gespannt:-)

Nächstes Problem,
Ist Fertig, inkl. allen Entwicklungs-Tools (Editor, Compiler (x86 und AVR), Flash-Utils)

Aber, 'leider' hab ich angefangen die (Mainboard-)Software nochmal neu zu schreiben,
was natürlich Änderungen im Frontend und auf dem SPI-Board mit sich zieht.
Also entweder ihr wollt nur mal die Visualisierung (und vielleicht die Limiter) sehen,
oder ihr wartet nochmal bis zur nächsten Version.
Ach schei.. drauf ,
Upload läuft (~1:30 Stunde) (Ich editiere diesen Eintrag wenn's fertig ist)
.... EDIT: Fertig, unter 1 Stunde

Da mir die Visualisierung neue Ideen beschert hat, solltet ihr auch nochmal drüber schauen können .

DBD
Olli

PS: Als weiter gefragt, erspart nachher viel Arbeit bei der Dokumentation ,
und enthüllt manchen Denkfehler .

Hi Rudy,

nochmal ganz Offiziell ein Dank an Dich .
Deine Berichte, wie z.B. Kritik und Visionen ,
haben dieses Projekt stark Beeinflusst (z.B. Dynamischer, Highspeed - PPM-Encoder ).

vielen Dank,
Olli


PS: Neue Live-CD ist Online

Sorry,
schon wieder ich

Mal eine Frage:

Ist es Heutzutage noch Sinnvoll, die Trimmung auf die Eingabe-Werte zu setzten (an den Knüppeln / vor den Mixern),
oder besser am Ausgang (einzelne Servo's / nach den Mixern)

Im Eingangs-Bereich würden ja alle Mixer-0-Punkte verstellt werden !

----------------------------------------------------
Neue Struktur (für C-Programmierer):


// Geber-Werte
typedef struct {
// Vorgabe-Wert
char value;
// Schalter/Encoder-ID (control: 0=OFF, 1-10=ADC, 11-254=Virtual, 255=ON)
char control;
} RC_Control;


// Eingangs-Puffer
typedef struct {
// Puffer
int value;
// Quelle (AUS, ADC, Schalter, ...)
char control;
} Rc_Input;


// Exponential-Setup
typedef struct {
// Kurven-Typ
char type;
// Kanal
char channel;
// Steigung & Geber-Eingang (AN, AUS, ADC, Schalter, ...)
RC_Control gardient;
} Rc_Expo;
Rc_Expo Expo[4];


// Dualrate-Setup
typedef struct {
// Kanal
char channel;
// Limit & Geber-Eingang (AN, AUS, ADC, Schalter, ...)
RC_Control limit;
} Rc_Dualrate;


// N-Punkt-Kurven-Setup
typedef struct {
// Eingang/Kanal
char channel_in;
// Ausgang/Kanal
char channel_out;
// Mixer-Werte
char point[2][MIXER_POINTS_MAX];
// Gesammt-Beimischung, An/Aus
RC_Control percent;
} Rc_Mixer;


// Linear-Mixer-Setup
typedef struct {
// Eingang/Kanal
char channel_in;
// Ausgang/Kanal
char channel_out;
// Gesammt-Beimischung, An/Aus
RC_Control percent;
} Rc_Linear;


// Limiter-Setup
typedef struct {
// Kanal
char channel;
// Obere Krenze
RC_Control up;
// Untere Krenze
RC_Control down;
} Rc_Limiter;


// Slowmotion / Move
typedef struct {
// Type (Input-Slowmotion, Input-Move, Output-Slowmotion, Output-Move)
char type;
// Kanal
char channel;
// Puffer/Werte-Speicher
int buffer;
// Speed nach Oben
RC_Control up;
// Speed nach Unten
RC_Control down;
} Rc_Motion;


// ATV-Setup (Servo-Endpunkt)
typedef struct {
// Kanal
char channel;
// Oberer-Endpunkt
RC_Control up;
// Unterer-Endpunkt
RC_Control down;
} Rc_Atv;


// Ausgabe-Puffer
typedef struct {
// Puffer
int value;
// Trimmung
RC_Control center;
} Rc_Output;


Rc_Input Input[16];
Rc_Dualrate Dualrate[4];
Rc_Mixer Mixer[16];
Rc_Linear Linear[16];
Rc_Motion Motion[4];
Rc_Limiter Limiter[4];
Rc_Atv Atv[8];
Rc_Output Output[32];


----------------------------------------------------
Neue Struktur (für Alle):


32 Eingangs-Kanäle: jeder frei belegbar auf Knüppel, Schalter, Drehencoder, Touchscreen/Widgets. oder Festwert.

4 x Dualrate: jeweils frei auf einen der 32 EingangsKanäle konfigurierbar

4 x Motion-Control: jeweils als Slowmotion oder Kransteurung, und an Ein- oder Ausgang verwendbar.

16 x 7Punkt-Mixer + 16 x Linear-Mixer: Ein- und Ausgänge sind frei wählbar, der Gesamt-Misch-Anteil kann per Drehgeber/Schalter reguliert werden.

4 x Limiter: getrennt an jedem Ausgabe-Kanal anwendbar.

8 x ATV: an jedem Ausgabe-Kanal anwendbar.

32 Ausgabe-Puffer (feste Belegung / 0-12=PPM, der Rest auf Nautic/Multiswitch oder per alles per xBee)

Alle Werte (bis auf die 7-Punkt-Kurven) lassen sich frei auf Festwerte, Schalter, oder Dreh-Encoder legen.


----------------------------------------------------

Einfacher Signal-Verlauf:

Eingang -> Linear-Mixer -> Center -> Ausgang

----------------------------------------------------

Komplexer Signal-Verlauf:

Eingang -> (Motion) -> (Dualrate) -> (Expo) -> 7Punkt-Mixer -> (ATV) -> (Limiter) -> (Motion) -> Center -> Ausgang

----------------------------------------------------

Die Anzahl der einzelnen Module und Kanäle kann im Quellcode variiert werden (Achtung RAM).


DBD
Olli

Hi Ralf,

Zitat

siehe www.tfh-wildau.de/rhirte/informatik/excel/splines.htm

Die Seite ist klasse (bei Wikipedia sah das noch verwirrender aus)

Dennoch blick ich noch nicht so ganz durch (mal mit Quellcode rumspielen).
Heist das, mann kan im Frontend die Kurven vor berechnen (keine Werte-Tabelle erstellen / Zu viel Speicherbedarf),
und im Atmel nur noch einen Kleinen Teil:

den

Zitat

'eigentliche Rechenschleife Do Do Cells(aROff + m, aCOff).Value = CSng(dx) Cells(aROff + m, aCOff + 1).Value = CSng(A(i) + B(i) * (dx - x(i)) + C(i) * (dx - x(i)) ^ 2 + D(i) * (dx - x(i)) ^ 3) dx = dx + Steps m = m + 1 Loop Until dx> x(i + 1) i = i + 1 Loop Until i> n

Hab bislang eine große Kurve um Kurven gemacht

Zitat

Den Geber-Eingangswert zu vertrimmen ist meiner Meinung nach sinnvoller. Bei 2 Querrudern müsstes Du sonst beide Servos vertrimmen, so geht es direkt vom Geber über beide Mixer.

Hmmmmm,
Sauberer ist es auf jeden Fall am Ausgang, man kann auch einen Trimmer (Drehencoder, Taster oder Poti)
zu mehreren Servos zuordnen (Man muss auch mal alte Gewohnheiten aufgeben können ).
Das ist in der Konfiguration aufwendiger aber genauer.

Im Frontend kann man immer mal 'Tricksen'.
Vielleicht eine 'Expert-Mode' Ansicht mit allen Feinheiten,
und eine 'Easy-Heli', 'Car', ... Ansicht für das Nötigste (oder bekannte Menüs Clonen / von Multiplex/Futaba/Graupner).


DBD
Olli

Hi,
@ Space (das geht schneller )

Zitat

Multiplex hat vor 15 Jahren ja nicht ohne Grund bereits einen 16Bit Prozessor eingesetzt

Vor 15 Jahren waren die 8bitler auch noch nicht so schnell
Stimmt schon, mit Spline-Kurven auf jeden Fall zu Langsam

Aber:
1. was flott auf dem Mega läuft, rennt auf einem 32bit ARM wie Hölle
2. guter Anreiz den Quellcode möglichts Portabel zu Gestalten (bin schon dabei / Frontend & Backend nutzen bald die gleichen Funktionen) .

@Ralf
Bin für So :
Eingang -> Dualrate -> Motion -> Expo -> Mixer/Limiter -> Motion -> ATV -> Center/Ausgang

weil,
Dualrate: bezieht sich auf die Knüppel (Eingang -> Dualrate), optional
Motion-IN: möglichst nah am Eingang (vor oder nach Dualrate), optional
Expo: vor dem Mixer (Expo -> Mixer/Limiter), optional
Mixer/Limiter: 7-Punkt oder Linear (um RAM zu sparen)
Limiter: sehe ich als 'optionalen' Teil des Mixers (Mixer/Limiter), optional
Motion-Out: möglichst nah am Ausgang (aber vor ATV und Center), optional
ATV: bezieht sich auf die Servos (Motion -> ATV), optional
Center: bezieht sich auf die Servos (ATV -> Center/Ausgang), sollte für jeden Kanal existieren (fest mit einem Kanal verbunden)

Das 'optional' bedeutet, das diese Funktion (um RAM zu sparen) nicht auf jedem der 250 Kanälen vorhanden sein muss.

Zitat

In die 7 Punkt Kurve bekommst Du auch die Geberbegrenzung mit hinein, desweiteren in erster Näherung auch die Expo Funktion (bei Splines dann allemal smile ). Auch die Gebermittenstellung steckt in der Kurve. Ist alles nur eine Definition der Stützstellen, die man aber durchaus als separate Punkte im Frontend aufführen kann.

Ich kann nicht jedem Kanal einen 7-Punkt-Spline-Mixer spendieren (RAMRAM, RAMRAM)

Zitat

Wenn ich ein passenden Ersatz für den PDA hätte, hätte ich es schon nachgebaut

Laptop/PC mit Live-CD

Zitat

Je länger ich nachdenke, desto... Ich glaube ich höre mal lieber auf

bitte, bitte, weitermachen

Zitat

Ich habe gestern wieder ein Modell in meine MC4000 programmieren müssen, ich finde es immer wieder genial, vor allen Dingen bin ich beeindruckt was vor >15 Jahren dort schon programmiert wurde (MC68HC16).

alles alter Schrott , HIER ist die Zukunft

Zitat

Tja, und dann fallen mir noch die "Flugphasen" ein. Ich glaube spätestens da sprengt es den ATmega

Ohoh,
hab gehofft es spricht keiner an
Brauch ich nicht, hab ich nicht (auf den mega644 aber machbar / so 2-3)
Aber

@All
Ursprünglich wollte ich nur ein bisschen Elektro-Schrott bei mir Daheim verwerten
Alter iPaq, HF-Modul, ein paar Atmels, Holz und 2 Knüppel,
klasse ich Bau mir ne Touchscreen-Computer-Funke (8-Kanal AVR-Funke hatte ich schon mal gebaut).

Jetzt kommt das 'Aber':
da das alles hier etwas Ausgeartet ist,
und in Richtung 'Community - Projekt' mit guten Aussichten mutiert,
bin ich auch gerne Bereit auf 32bit-ARM CPUs (im Backend) auszuweichen.
Allerdings sind da meine eigenen Grenzen gesetzt.
Da ich noch nie ne SMD-Platine gelötet habe, und auch nicht sehr vertraut mit professioneller Platinen Herstellung bin, bräuchte ich in diesem Bereich tatgräftige Unterstützung.

ARM9E Development-Board in USB-Stick Form für 40 Teuros
Kann ich mir noch Leisten

DBD
Olli

PS: Pre-Mixer gibt es nicht mehr


EDIT: Sorry, Falscher Link str9-comstick

Hi Wurpfel,

Zitat

mit den 8biter sind auch kurven und komplexe mischer möglich..

Ich kann dir auch ein 3D-Spiel auf nem Atmel rendern lassen,
aber ob das in einer angemessenen Geschwindigkeit funktioniert ist zu bezweifeln.

Der Atmel ist jetzt schon absolut an seiner Grenze.

Zitat

der trick: rechenintensive werden VORHER berechnet und in einer lookup-tabelle gespeichert. der prozzi holt sich dann was er braucht.. stichwort reihenentwicklung und logarithmentabelle augenzwinkern

Eine Lookup-Tabelle für 10bit, 2048 byte = 2Kbyte / Mixer

Zitat

der andere trick: man teilt das problem in kleine häppchen und lässt mehrere prozzies daran arbeiten

Hab ich mir auch schon überlegt, da brech ich mir beim ARM, weniger ein BEIN bei ab

Zitat

die mondlandung wurde von einem 4bit-prozzi gesteuert.. mit einem schlanken konzept kommt man sehr weit

Für ne Film-Studio-Aufnahme reicht das wohl


Ne, ne du,
32bit ARM wird da schon wichtig.

DBD
Olli

Hi Ralf,

Zitat

Sollte meine Kommentar negative angekommen sein, entschuldige ich mich

Was, wer ,wie ,wo, nix gesehen
Ihr denkt einfach nur mit (Konstruktiv und Kritisch) ,
so gefällt mir das

Zitat

Ich denke hier kann ich dann endlich mal unterstützen

tust du doch schon

Zitat

beim programmieren ist der Zug für mich wohl langsam abgefahren

Im Gegenteil, ich komm bei deinen Spline-Kurven nicht mehr mit

Zitat

Das hier käme ggf. auch in Frage http://www.actel.com/documents/IGLOO_StarterKit_PIB.pdf

Will euch nicht kritisieren, aber ich glaub das wird zu teuer, und bezieht sich, glaube ich, Hauptsächlich auf FPGA-Entwicklung (ARM nur am Rande).

Zitat

Ich glaube der von Dir angegebene ARM ist mir vor einiger Zeit schon mal in der c't aufgefallen

Jepp

Zitat

Sieht auch interessant aus und hat wohl auch direkt ein(oder mehrere?) ADC on Board.

notfalls halt noch nen AVR-tiny26 mit 11 * 10bit ADC's drann,
oder gleich echte 16 oder 24bit Wandler (HighEnd ).

Auch bei Nutzung eines ARM's, bin ich nach wie vor für eine Trennung zwischen Frontend und Backend !

Zum besseren entwickeln der Backend-Software,
sollte man sich vielleicht eine kleine Entwicklungs-Umgebung aufbauen.

Fernbedienung mit Sim-Adapter (als Eingabe)
Backend-Software auf dem PC (als Test-System)
PPM-Encoder (AVR-Board), Serieller Servo-Tester oder PC-Bildschirm (als Ausgabe)

Neue Backend-Software,
hab Angefangen 'alles' neu zu schreiben (beim 2. mal wirds immer besser, und geht auch schneller ).

Im Prinzip hab ich erst mal nur eine Visualisierung gemacht,
allerdings mit den Atmel-Tauglichen Funktionen,
das Backend wird sozusagen Simuliert und Visualisiert
Sogar die Slowmotion-Funktion (2.Zeile / 3.Kasten im Bild).


Viel Spaß beim Fliegen
Olli