Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

21

Dienstag, 16. Juni 2009, 08:20

Hui, bin jetzt etwas weiter mit'm Layout. Aber die Servo-Ausgänge stellen echt ein Problem dar. An einer Stelle hätte ich zwar gerade noch ein paar Timer Ausgänge, aber blöderweise an den JTAG Pins. D.h. beim Einschalten sind diese PU. Ich glaub nicht, dass ein ESC oder Servo das mag, und hätte keine Ahnung was er denn tut...

Ich glaub, dann geht es eben nicht direkt mit den Timer Ausgängen und ich muss alles über Interrupt-Routinen lösen...

Hab mittlerweile einen interessanten Test gelesen zum Lisy:
Lisy Vibrations Sweep-Test

Scheint wirklich so, als ob dieser vollkommen unbrauchbar für diese Anwendung ist, da extremst sensitiv auf Vibrationen...
Lustigerweise hab ich heute grad ein Mail bekommen, dass die Lisy's wieder lieferbar wären...Aber ich glaub das hat sich jetzt erledigt...(und ich spar mir den Aufwand eines zusätzlichen Layouts... :D )

ST bringt ja bald eine ganze Schwemme an neuen Gyros raus. Leider steht in den Preliminary Datasheets nirgends welche Resonanzfrequenz diese haben. Es steht jedoch zu befürchten, dass diese aufgebaut sind wie die Lisy's, dann wären diese alle nicht zu gebrauchen für RC-Zwecke...

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Hui« (16. Juni 2009, 08:23)


22

Donnerstag, 18. Juni 2009, 09:33

So Heute sind jetzt die IDG's gekommen. Zudem auch mein neuer Reflow-Ofen.
Leider hab ich zurzeit geschäftlich viel zu tun, und so muss nun der Abschluss der Layouts etwas warten...

Hab mich auch gefragt, ob's denn unbedingt ein Quarz benötigt, da dieser viel Platz braucht. Der interne RC-Oszillator hat eine Abweichung von +-0.2% im vorgesehenen Temperaturbereich (0-70°C). Das sind 2 von 1000 Abweichung. Das sollte eigentlich reichen. Es geht ja darum, dass die Servoabweichungen bedingt durch ungenaue Ansteuerung nicht zu gross werden. Und da z.B. eine DX7 eh nur 1024 Auflösung hat und im "normalen" Servobereich sogar noch weniger, sollten die 2 auf 1000 eigentlich OK sein. Schlimmstenfalls könnte man noch korrigieren mit dem internen Temp-Sensor.
Also weg mit dem Quarz vom Layout...
Auch für die späteren Kalmanfilter ist eine genaue Zeitbasis ja wichtig, aber wenn man die Genauigkeit des Gyro-Sensors berücksichtigt, relativiert sich das ganze wieder, und so müsste der interne Oszillator reichen.

o.dippel

RCLine User

Wohnort: Büdingen / Hessen

Beruf: Software-Developer

  • Nachricht senden

23

Donnerstag, 18. Juni 2009, 09:37

Moin,
gibt doch 'Micro' Quarze <8 x 5.5 x 1 mm
Oder ist das schon zu viel ?

:w

24

Donnerstag, 18. Juni 2009, 09:56

Zitat

gibt doch 'Micro' Quarze <8 x 5.5 x 1 mm Oder ist das schon zu viel ?


Viel zu viel! 8x5.5mm wäre ja riesig ;)

Ne, wenn dann hätte ich 2.5x2mm genommen. Zudem sind diese Quarze nicht gerade billig...
Zurzeit (nur HH Gyro) hätte ich auch noch genügend Platz, aber später beim vollen System wird es dann schon eng werden, zumindest, wenn ich mein gestecktes Ziel erreichen möchte, dass die Platine dieselbe Grösse hat wie der Spektrum Satellit 15x22mm. Das ist schon klein...Das sieht man erst, wenn man das Layoutet...Da wirkt ein 0603er Bauteil bereits riesig :dumm:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Hui« (18. Juni 2009, 09:58)


25

Freitag, 19. Juni 2009, 17:35

Kurzupdate:

Heute sind meine Molex Picoblade Buchsen gekommen. Wollte wissen ob das tatsächlich die von den Walkera's sind. Und ja. Die passen. Kann das Layout diesbezüglich also lassen.

Edit:

Ach ja: Eine 3er Buchse mit Stiften zum Löten wiegt 0.075g . D.h. die 5 benötigten Buchsen haben 0.375g. Ist schon nicht gerade wenig...Aber wie gesagt: Ist dann jedem selber überlassen, ob er die drauflöten will oder lieber Gewicht sparen will und direkt anlötet.

Interessant ist, dass man auf dem PCB eigentlich nicht wesentlich Platz spart, ob man diese Walkera Buchsen nimmt, oder die ganz konventionellen im 2.54er Raster. Das liegt daran, dass die Walkera-Buchsen ziemlich breit sind.
Direkter Vergleich PCB Fläche:
Picoblade 3.2 * 5.5 = 17.6 mm^2
Standard 2.54 * 3 * 2.54 = 19.4 mm^2

Es spart dann halt Platz bei den Steckern, da diese kürzer sind und zudem sind die Buchsen leichter als die 2.54er Stiftleisten...


BTW: Das Picoblade Stecksystem ist eigentlich für Ströme bis 1A...
Aber ich glaube im RC-Bereich ist es fast schon eher Regel, dass Bauteile jenseits Ihrer empfohlenen Spezifikationen betrieben werden...

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »Hui« (20. Juni 2009, 09:34)


26

Freitag, 19. Juni 2009, 17:40

Zitat

Heute sind meine Molex Picoblade Buchsen gekommen. Wollte wissen ob das tatsächlich die von den Walkera's sind. Und ja. Die passen. Kann das Layout diesbezüglich also lassen.

Interessant das zu wissen :ok:

27

Sonntag, 21. Juni 2009, 20:54

Hi Hui...
bin grade erst über diesen Threat gestolpert.
Schönes Projekt. :ok:
Ich werde das auch weiter verfolgen, bin aber leider auch im Augenblick sehr ausgelastet.
Zu allem Überfluss hab ich heute meinen Easy Glider in die Wiese gesteckt ;(

Da ist jetzt erstmal wieder basteln angesagt.
Dann kommt das RCOS Projekt dazu und jede Menge Arbeit für'n Job.
Hab seit 3 Monaten meinen Rex mit Helicommand ausgestattet und erst einen Flug gemacht ;(

Puhh...
der Tag könnte 48 Stunden haben.


Wollte eigentlich nur sagen...
Mch weiter, ich beobachte auch !!

Greets Tele
Never surf faster than your guardian Penguin can fly.

28

Dienstag, 30. Juni 2009, 16:16

Püüüh, Ja Zeit ist ein rares Gut :tongue:

Hab jetzt Mal endlich Zeit gefunden, das Layout zu beenden.

Das Power Routing ist zwar suboptimal, aber ich hab gerade keine Zeit für ein besseres Routing. Für erste Prototypen sollte es reichen.
BTW: Die linke GND-Plane ist absichtlich von der rechten getrennt (Analog+Digital), das gibt etwas weniger Störungen im Analog-Teil.
Hab's absichtlich einseitig Bestückt gemacht, dass ich keine 2 Schablonen zahlen muss. Nur 2-lagig, auch um Geld zu sparen.

Man sieht schön, dass man noch genügend Platz hätte, das ganze 6DoF auf diese Grösse zu bekommen, wenn man doppelseitig bestücken würde.
Würde ich beim vollen Stabi auch so machen: Doppelseitig bestückt, 4-lagig.

Dann gibt's auch keine Probleme mehr mit dem Power-Routing.

Der rechte Teil, neben den Walkera-Buchsen, wird nicht benötigt für 1S-Applikationen und kann dort abgesägt werden. Dawzischen ist einfach ein HCT245 als Level-Shifter für xS Applikationen (x > 1).

Da ich ja mindestens 100x100mm herstellen lassen muss, hab ich noch einiges an Platz. Hab mich entschieden noch eine Kopie des 0.5g Reglers zu machen, aber mit dem Mega88 als Chip. D.h. man könnte die ganz normale Quax SW benutzen. Mal sehen, ob ich diese Woche noch Zeit finde dazu. Falls nicht, geb ich das HH-Gyro halt ohne in Produktion.

Edit:
Ahh, BTW: Wenn Ihr das Ding in Originalgrösse sehen wollt, müsst Ihr die Ansicht verkleinern, bis die Höhe noch 15mm beträgt ;)
»Hui« hat folgendes Bild angehängt:
  • OS_HH_V0_1.jpg

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Hui« (30. Juni 2009, 16:22)


29

Mittwoch, 1. Juli 2009, 08:29

Von dem meisten hier habe ich zwar keine Ahnung aber bin begeistert. Will auch so ein kleines Stabi ;-) Würde das gerne am 4G3 "Rigid" testen. Leider kann ich sonst nicht viel beitragen oder ich studiere einfach mal Elektrowissenschaften :O

Grüße
Tobi
Grüße
Tobi

4G6 2S FBL :evil: / 4G3 Brushless HL Airwolf / 1#A / Mini Titan V-Stabi 4.0 / Gaui 200 fliegt jetzt mit alter RX-2605 vom 4G3 / 4#3b Brushless HL / H05 BL
Alle mit 2801 Pro

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »aSiD1712« (1. Juli 2009, 08:36)


30

Mittwoch, 1. Juli 2009, 12:38

Hallo Hui,

ein wirklich tolles und interessantes Projekt hast Du da angefangen. Endlich mal was anderes, als immer nur mit Motoren und Ritzeln zu experimentieren. Ich werde Dein Projekt mit großer Neugier weiter verfolgen. Wenn Du Hilfe – egal in welcher Form – benötigst, schreib es bitte hier ins Forum. Es wird sich bestimmt eine unterstützende Hand finden.

Schönen Gruß
Frank

JPOP

RCLine User

Wohnort: Saarbrücken

  • Nachricht senden

31

Montag, 6. Juli 2009, 15:08

Hi,

bei der Elektronik kann ich Dir nicht so gut helfen, höchstens bei der SW.
Aber da gibt es wohl auch schon vieles bei den Schwebeplattformen.. aber falls Du mal was in C oder C++ brauchst.. läuft die SW in festen frames oder frei und liest nen timer aus?
Gibt es ne website oder Wiki für das Projekt?

-JP
_________________________________
Against gravity

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »JPOP« (6. Juli 2009, 15:09)


32

Montag, 6. Juli 2009, 15:18

Zitat

bei der Elektronik kann ich Dir nicht so gut helfen, höchstens bei der SW.


Gerade bei der SW braucht es ja Leute. Die Elektronik kann ich leicht selber machen...Ist auch schwer die Elektronik verteilt zu machen :D

Zitat

Aber da gibt es wohl auch schon vieles bei den Schwebeplattformen..


Yep. Werde wohl vielleicht für erste Tests, da was kopieren von...

Zitat

läuft die SW in festen frames oder frei und liest nen timer aus?


Im Moment hätte ich vorgesehen in festen Time-Frames, da besser kontrollierbar, und die Filter eh eine spezifische Zeitbasis benötigen.

Zitat

Gibt es ne website oder Wiki für das Projekt?


Noch nicht. Wenn ich die ersten Platinen bestückt habe, werde ich zuerst das Grundgerüst proggen (Interface zu Satellit und Servos). Dann die SW-Grundstruktur. Sodass er funktioniert, wie ein ganz normaler Empfänger. Von da an, macht es dann Sinn, dass andere Leute Ihre Routinen ausprobieren können und das ganze Gerüst wird veröffentlicht.

JPOP

RCLine User

Wohnort: Saarbrücken

  • Nachricht senden

33

Dienstag, 7. Juli 2009, 22:49

Hi,

also wenn man schonmal ne Startroutine für den Prozessor (bootstrap) hat und sich auf eine Entwicklungsumgebung eingeschossen hat wird vieles leichter.
Könnte natürlich auch eine Rolle für die Auswahl des Professors spielen, also das vorhandensein einer ebensolchen, evtl. freien Lösung.
Welcher Prozessor war nochmal Deine Wahl? JTAG debugger schnittstelle?
Bissl schade ist diese Spektrum-Satellitensache, geht halt nur noch Spektrum, kein FM und kein FASST.

-JP
PS: Die Schwebeplattformen sind schon interessant, z.B. http://www.mikrokopter.de .. Platine abspecken, code auf Heli pimpen, servo output feddich.
_________________________________
Against gravity

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »JPOP« (8. Juli 2009, 00:12)


34

Mittwoch, 8. Juli 2009, 09:45

Zitat

Welcher Prozessor war nochmal Deine Wahl?


Ein STM32F103 Prozessor.
Programmiert wird er über einen intergrierten Bootloader per UART (serieller Schnittstelle). D.h. man schliesst einfach den PC (über einen Adapter) am Anschluss eines Satelliten an zum Programmieren.

Zitat

Bissl schade ist diese Spektrum-Satellitensache, geht halt nur noch Spektrum, kein FM und kein FASST.


Naja. FASST hat ja seine Satelliten Lösung noch nicht veröffentlicht, oder?
Prinzipiell wäre es kein grosser Aufwand auch ein Summensignal zu verwerten. Aber dies ist ein Stabi-System für speziell kleine Helis, und da macht FM generell keinen Sinn. Ich denke FASST würde sich ohne allzu grossen Aufwand auch noch implementieren lassen. Aber first things first...

Zitat

Die Schwebeplattformen sind schon interessant, z.B. http://www.mikrokopter.de .. Platine abspecken, code auf Heli pimpen, servo output feddich.


Yep, für grössere Helis kein Problem, haben auch schone einige gemacht. Aber wie bereits erwähnt, zu gross für Palm-Size Helis. Das lässt sich auch nicht beliebig schrumpfen wegen der verwendeten Bauteile. Zudem benutzen die Mikrokopter-Leute leider einen extrem schwachbrüstigen Prozessor...

JPOP

RCLine User

Wohnort: Saarbrücken

  • Nachricht senden

35

Mittwoch, 8. Juli 2009, 22:57

Hi,
ich habe mir das uP manual mal gezogen, aber noch keine Zeit damit verbracht.. interessant wäre die Grenzfrequenz der ADUs. Die sollen ja bis ans MHz rangehen, wäre mal interessant was das für die gemessenen Werte bedeutet..
Hast Du Tiefpässe auf den Gyro-Signalen? Decken die Gyro-Signale die 12 bit komplett ab oder wie hoch ist die Auflösung tatsächlich?
Ich meine, wenn man da mal ausrechnet wie schnell man Abtasten muss, kommt man vermutlich mit ein paar (einstellig) KHz hin.
Mit welcher Rate bekomen denn die Digitalservos Ihre Signale?
Und noch ne ganz blöde Frage.. einen Ausgang für den Motor ESC muss man ja auch noch forewarden, den Pin haste? Haste da auch noch pins frei zum Oszi anschliessen zwecks Messung/debug?
Ich tät da einen ganz einfachen scheduler machen.. der lässt zwei frames laufen. Einen schnellen, der macht die Filterung der ADU-Werte, generiert die Servo-Signale und liest die Empfänger-Signale ein, der "langsame" rechnet die Regelkreise. Das würde natürlich auch ein kleinerer Prozessor "packen".

Gruß,
-JP
_________________________________
Against gravity

36

Mittwoch, 8. Juli 2009, 23:48

Zitat

Hast Du Tiefpässe auf den Gyro-Signalen?


Lol

Zurzeit ist auf der Platine noch ein simpler RC-Tiefpass vorgesehen. Ich vermute jedoch stark, dass dieser nicht gebraucht wird, da der Gyro schon intern filtert, und der uC wie bereits erwähnt ziemlich schnell wandeln kann. So kann man also per SW-Filtern, was eh besser ist, da dies z.B. Filter erlaubt, welche keine Frequenz abhängigen Phasenverschiebungen bedingen, wie das bei den Analog-Filtern der Fall ist. Aber das wird dann die Praxis zeigen.

Zitat

Decken die Gyro-Signale die 12 bit komplett ab oder wie hoch ist die Auflösung tatsächlich?


Die 12 Bit decken nicht alles ab, sondern nur 2/3. Um die Mitte wird das Signal aber noch verstärkt und nochmal zugeführt, zur Genauigkeitserhöhung .
Das ganze ist aber nur eine kurzfristige Behelfslösung, da später eh ein IME3000 das AD-Wandeln übernehmen soll und der hat 16-Bit Wandler. Also sicherlich genug Auflösung. Die Frage ist nur, was für eine Samplerate dieser hat, da dies noch nicht angegeben wurde...
Sollte eigentlich reichen, Ein Gy401 hat z.B. nur ein 10Bit Wandler.

Zitat

Ich meine, wenn man da mal ausrechnet wie schnell man Abtasten muss, kommt man vermutlich mit ein paar (einstellig) KHz hin.


Längstens! Die meisten Gyros haben eh eine 3dB Grenze von etwa um 100Hz.

Zitat

Mit welcher Rate bekomen denn die Digitalservos Ihre Signale?


Mit was man diese auch immer programmiert... :D
Ich persönlich würde standardmässig bis kurz vor's Limit gehen (400Hz). Also etwas mehr als die 270Hz des GY401. Aber muss man dann testen, welche Servos das mitmachen.

Zitat

Und noch ne ganz blöde Frage.. einen Ausgang für den Motor ESC muss man ja auch noch forewarden, den Pin haste?


Es sind, wie auf der Platine ersichtlich, 5 Buchsen vorgesehen. 3 für TS, 1 für Tail und 1 für Motor. Oder wie man diese auch immer belegen will.

Zitat

Haste da auch noch pins frei zum Oszi anschliessen zwecks Messung/debug?


Nö, dafür ist kein Platz. Sind jedoch noch 2 Pins drauf mit I2C Interface für OpenServo-Lösung. Zudem kann man, wenn man nur 1 Satellit anschliesst, man den 2. Uart problemlos zum debuggen benutzen.

Zitat

Ich tät da einen ganz einfachen scheduler machen.. der lässt zwei frames laufen. Einen schnellen, der macht die Filterung der ADU-Werte, generiert die Servo-Signale und liest die Empfänger-Signale ein, der "langsame" rechnet die Regelkreise.

Braucht mehrere Timer. Einer ist für das Timen der AD-Wandlungen zuständig. Einer für die Ausgabe der Servo/ESC Signale und einer für die eigentliche Regelung. Das einlesen der Servo-Signale geschieht dank UART nebenbei und muss nicht getimed werden. Sonst (Summensignal) braucht man noch einen unabhängigen Timer zum Dekodieren des Empfangssignals.

Zitat

Das würde natürlich auch ein kleinerer Prozessor "packen".


Ich hab gerne mehr Rechenleistung. Auch da diese uC Heute fast nichts zusätzlich kosten. Wieso soll ich mich da mit einem arschlahmen 8Bit AVR begnügen, wenn man für $10 Heute ein 70Mhz 32-Bit Arm haben kann, welcher HW-Multiplier und Divider hat!
AVR sind gute Interface Chips, da sie viel treiben können. Sind jedoch nicht dazu gedacht gross was zu rechnen...
Und die Regelung die ich vorsehe braucht ordentlich Rechenpower, da das System den Helikopter modellieren soll. D.h. das System hat z.B. eine Massenträgheitsmatrix, sodass es selbständig im voraus berechnen kann, wie sich der Heli verhalten wird, und so optimal ansteuern. Also nicht nur ein plump-simpler PID-Regler...

JPOP

RCLine User

Wohnort: Saarbrücken

  • Nachricht senden

37

Donnerstag, 9. Juli 2009, 08:24

Hi,

Zitat

Und die Regelung die ich vorsehe braucht ordentlich Rechenpower, da das System den Helikopter modellieren soll. D.h. das System hat z.B. eine Massenträgheitsmatrix, sodass es selbständig im voraus berechnen kann, wie sich der Heli verhalten wird, und so optimal ansteuern. Also nicht nur ein plump-simpler PID-Regler...


ui, das ist mir neu. Nach meinem bescheidenen Wissen laufen die Systemparameter in die Regelparameter rein und fertig. Also bissl mehr D und bissl mehr P ;).. Aber da ja 1. genug Rechenpower da ist und 2. das open source ist, kann man ja alles probieren..
Die UART Lösung ist ne feine Sache, aber natürlich nicht so einfach zu debuggen. Wie Du Dir das mit den Timern vorstellst habe ich nicht ganz verstanden, vermutlich reden wir aber vom selben, ein scheduler macht ja nix anderes als eine Funktion zu einem bestimmten Zeitpunkt auszuführen..

-JP
_________________________________
Against gravity

38

Donnerstag, 9. Juli 2009, 09:15

Zitat

ein scheduler macht ja nix anderes als eine Funktion zu einem bestimmten Zeitpunkt auszuführen..


Naja, ein Scheduler ist in meinem Verständnis dafür Zuständig die Rechenlast zwischen verschiedenen Tasks aufzuteilen. Das ist bei dieser Anwendung eigentlich nicht wirklich der Fall. Deshalb rede ich nicht von einem Scheduler. Task gibt es eigentlich nur einen: die Regelung. Der Rest sind einfach nur Interrupt Routinen, nicht eigentliche Tasks...
Aber das ist reine Definitionssache. Wie meinen definitiv dasselbe :D

JPOP

RCLine User

Wohnort: Saarbrücken

  • Nachricht senden

39

Donnerstag, 9. Juli 2009, 10:27

Hi,

sicher ;). Scheduler bei RT halt.. wobei - ich bin ein "poller" kein "interrupter" wegen des deterministischen Zeitverhaltens ;). Ist aber nur ne Frage des persönlichen Geschmacks ;), funktionieren tut beides.

Also um nochma auf die Entwicklungsumgebung zurück zu kommen..
Ich habe jetzt noch keine IDE gefunden was man sich einfach runterladen kann. Also debugger, compiler+linker ect.
Ideal wäre für so ein Vorhaben ein fertiges Paket weil Standard.. vielleicht das hier oder das ?
Gefunden - Treiber/HAL:
STM32 Standard Peripheral Library

Gruß,
-JP

PS:

Zitat

Mit was man diese auch immer programmiert...
Ich persönlich würde standardmässig bis kurz vor's Limit gehen (400Hz). Also etwas mehr als die 270Hz des GY401. Aber muss man dann testen, welche Servos das mitmachen.

Naja, ich hatte da die Servos des 4G3 im Auge, sonst gibt für das ganz kleine Gehube ja nicht viel Auswahl an Digitalservos.

PPS:

Zitat

Ein STM32F103 Prozessor.
Programmiert wird er über einen intergrierten Bootloader per UART (serieller Schnittstelle). D.h. man schliesst einfach den PC (über einen Adapter) am Anschluss eines Satelliten an zum Programmieren.

Au wei, bei der Suche ist mir aufgefallen, das die meisten Free IDEs mit JTAG laufen. Ich bin ganz ehrlich gesagt auch kein so garkein Fan von der seriellen Lösung, zu groß sind die Einschränkungen und bei einem fiesen Bug kommt man nicht mehr an den uC ran. Vlt. aber auch wieder ein IDE Thema, wenn Deine gut geht?!
_________________________________
Against gravity

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »JPOP« (9. Juli 2009, 12:30)


40

Sonntag, 12. Juli 2009, 00:25

Hab gerade gesehen, dass mittlerweile immerhin bereits die IXZ Chips draussen sind.
Hoffentlich dann bald auch die ISZ und die IME.
Übrigens scheinen Sie die Produktion recht ausgebaut zu haben (wahrscheinlich Nintendo bedingt)
Das hat den Vorteil, das sich die Preise halbiert haben!
Ein IDG oder IXZ kostet jetzt nur noch $20!
D.h. ein volles Stabi-System wird wahrscheinlich so um die $60 werden.

Zitat

Au wei, bei der Suche ist mir aufgefallen, das die meisten Free IDEs mit JTAG laufen. Ich bin ganz ehrlich gesagt auch kein so garkein Fan von der seriellen Lösung, zu groß sind die Einschränkungen und bei einem fiesen Bug kommt man nicht mehr an den uC ran. Vlt. aber auch wieder ein IDE Thema, wenn Deine gut geht?!


Kein Problem, den seriellen Programmer kannst Du runterladen. Ist auch dokumentiert. D.h. kannst Du auch selber machen.
Grosse Bug's sehe ich nicht. Der Bootloader ist ja fix im ROM. Und soviel Bugs kann der ja nicht haben. Muss ja nur das Zeug ins Flash hauen.
Hab auch schon Mal 'ne GNU-Kette dafür gefunden. Aber werde vorerst, ganz OS untypisch wohl die freie Version des IWARM nehmen. 1. ist die Umgebung viel einfacher einzurichten und 2. ist der Compiler effizienter.
Kann man später ja immernoch problemlos portieren.

Edit:
JTAG kommt aus mehrerern Gründen nicht in Frage. Es werden z.B. viel zuviele Pins dafür benötigt. Diese werden 1. für anderes benötigt und 2. hat man schlicht keinen Platz dafür auf der Platine. Ich denke mit der Lösung über den Anschluss des Satelliten ist ein guter Kompromiss.
Auch ist ein JTAG Adapter doch einiges aufwändiger als ein seriell Wandler, wo Du einfach einen Max nehmen kannst.
Ich denke später muss man ja sowieso für den Benutzer standardmässig das Ding an den PC hängen können...Geht so IMHO am Besten.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Hui« (12. Juli 2009, 00:35)