Funkauslöser advanced ATMEL / RFM12

[logout1984]

Hallo

Eben, man weis es nicht. Er könnte z.B. damit beschäftigt sein von der letzten Übertragung noch das Display zu aktualisieren. Ich will Dir deine for-Schleife auch nicht ausreden, aber wenn man mit begrenzten Resoucen, wie Sie nun mal bei kleinen 8-Bit uControllern vorhanden sind, arbeiten will/muß, sollte man doch nutzen, was einem die kleinen Kerlchen bieten.

Gruß Ulf

Hi Ulf,

ist ja nicht meine for schleife, sondern , wenn wir es gemeinsam
implementieren, unsere for schleife bzw. unser timer.

Ich sehe in dem for Schleifen Konstrukt eine Reihe von Vorteilen

je nach Platform sind einige Timer nicht verfügbar => Änderungsaufwand bei
hardware wechsel

Timerbenutzung erfordert Absprache mit anderen (wer benutzt
welchen Timer um was zu erledigen, z.B. wer sein userinterface
mit Drehgeber realisiert braucht einen Timer, damit man sich
nicht in's Gehege kommt muss das koordiniert werden

der forschleifen code ist simple und funzt auf allem
was die avr-glibc unterstützt ohne das man über timer Masken etc.
nachdenken muss / berechnen müßte. Es würde mich nichtmal
überraschen wenn der Code nachher sogar kleiner würde.

während der 3 bis 4 ms die der uC maximal in der flash routine
steckt passiert nichts (das Display kann auch mal 4ms warten)

Allerdings würde ich für die Kleinigkeiten auch nicht in den Ring steigen ;-)

Gruß
Logout

 

[jar]

Da kommt schon was zusammen. mit userinterface usw. kann
ich mir vorstellen, dass es nicht unter 16k oder sogar
32k geht - zumindest am "Controller" Emfpänger und Sender
können vermutlich mit weniger auskommen. Da die Preisdifferenz
zwischen Mega8 und Mega32 aber gerade mal 1 Bier (ok mit
Trinkgeld)ist, mach ich mir da nicht so die Sorgen drum.

nimm den 644 Pinkompatibel zum mega32 , für mein Timer wurde mir auch der m32 zu eng, mit dem 644 ist es entspannter

 

[ulf_l]

Hallo

Warum nicht gleich den CoretexM3 oder doch lieber ARM9 ? Dann könnte man noch Spiele, Textverarbeitung und vielleicht noch einen email-Client und Auslösung per SMS integrieren

Gruß Ulf

 

[jar]

Hallo
Warum nicht gleich den CoretexM3 oder doch lieber ARM9 ? Dann könnte man noch Spiele, Textverarbeitung und vielleicht noch einen email-Client und Auslösung per SMS integrieren
Gruß Ulf

nun ja die leichte Verabreitung, die Schnitten und Tools sowie die LIBs und Sourcen im Netz und der Preis spricht eher für Atmel, auch DIP Gehäuse

 

[logout1984]

Hallo

Warum nicht gleich den CoretexM3 oder doch lieber ARM9 ? Dann könnte man noch Spiele, Textverarbeitung und vielleicht noch einen email-Client und Auslösung per SMS integrieren

Gruß Ulf

im automotiv Bereich wird teilweise wohl PPC benutzt, das wäre schon noch
ne Alternative ... nicht kleckern, klotzen

Gruß
Logout

 

[MasterFX]

Nein das ist keine Alternative. Wir wollen hier keine Heizung für den Winter bauen sondern etwas funktionelles was mit kleinen, günstigen Akkus/Batterien läuft und zu dem noch selbst zu löten ist. Zudem ist die Programmierung auf Hardwareebene viel zu teuer (JTAG-Adapter etc) + externen Flashspeicher...

 

[ulf_l]

Nein das ist keine Alternative. Wir wollen hier keine Heizung für den Winter bauen sondern etwas funktionelles was mit kleinen, günstigen Akkus/Batterien läuft und zu dem noch selbst zu löten ist. Zudem ist die Programmierung auf Hardwareebene viel zu teuer (JTAG-Adapter etc) + externen Flashspeicher...

Hallo

Full Ack !
Nur wer wollte da in Hardware programmieren ?

Gruß Ulf

 

[MasterFX]

Nur wer wollte da in Hardware programmieren ?

Mit Hardwareebene meinte ich hardwarenahes Programmieren und nicht FPGAs in VHDL oder so. Das ist das was man gemeinhin auf µCs macht. Ob nun Assembler oder C ist hier irrelevant. Nur wollte ich da kein OS zwischen, was bei PowerPC, Cortex etc meist der Fall ist, schon alleine weil die Hardware relativ komplex ist. Ich weiß das, da ich schon einen Bootloader für einen MPC8548 programmiert habe, sowohl in Asm als auch in C. Da habe ich alleine schon wochenlang fummeln müssen bis ich überhaupt erstmal die Peripherie ansprechen konnte, da es ein ziemliches rumprogrammiere ist erstmal den angeschlossenen Speicher anzusprechen wegen MMU etc.

 

[ulf_l]

[...] Zudem ist die Programmierung auf Hardwareebene viel zu teuer (JTAG-Adapter etc) + externen Flashspeicher...

Mit Hardwareebene meinte ich hardwarenahes Programmieren und nicht FPGAs in VHDL oder so. Das ist das was man gemeinhin auf µCs macht.[...]

Hallo

Aber was soll dann daran besonders teuer sein ? Die Programmierung der ATMEL Teile geht doch von billigst-Adaptern bis Dragonboard zu recht zivilen Preisen.

Gruß Ulf

 

[MasterFX]

Hallo

Aber was soll dann daran besonders teuer sein ? Die Programmierung der ATMEL Teile geht doch von billigst-Adaptern bis Dragonboard zu recht zivilen Preisen.

Gruß Ulf

Ich habe auf die Vorschläge a la PowerPC und Coretex M3 geantwortet. Klar ist Atmel günstig, genau deswegen kommt auch nur das infrage.

 

[logout1984]

Ich habe auf die Vorschläge a la PowerPC und Coretex M3 geantwortet. Klar ist Atmel günstig, genau deswegen kommt auch nur das infrage.

uiuiui

das mit dem PPC war ein Witz !!!

Gruß
Logout

 

[MasterFX]

uiuiui

das mit dem PPC war ein Witz !!!

Gruß
Logout

Ja ich habs auch nicht wirklich ernst genommen. Aber ganz ohne Kommentar wollte ich es auch nicht stehen lassen.
Aber nun BTT

 

[logout1984]

Ja ich habs auch nicht wirklich ernst genommen. Aber ganz ohne Kommentar wollte ich es auch nicht stehen lassen.
Aber nun BTT

BTT ??? .... achso ja genau... oder auch Butter bei die Fische.
Ich denke wir haben schon eine ganze Menge im Zettelkasten. Ich würde das jetzt mal
alles zu einer Art Projektbeschreibung zusammen fassen und dann hier posten.
Der nächst Schritt wäre dann, dass wir untereinander festlegen was wir in Phase 1 2 3
implementieren wollen, offene Fragen klären, welche SW-Module wir dafür benötigen und
wie die Schnittstellen zwischen den Modulen aus zu sehen haben. Ich denke
anschließend könnte jeder der sich an der Programmierung beteiligen will auf eines oder
mehrere dieser Module stürtzen und programmieren (BTW, wir hatten uns noch nicht auf
eine Sprache geeinigt, aber ich hoffe doch inständig, dass es C sein wird).
Auf der Hardwareseite stellt das Projekt keine besonderen Herrausforderungen, allerdings
sollten wir beim Design ISP Möglichkeiten berücksichtigen.
Wäre das so in etwa die Vorgehensweise die euch auch vorschweben würde ??

Gruß
Logout

P.S. ich hab die Woche noch ein bisschen was anderes zu tun, mit der
Projektbeschreibung würde es sich so bis Anfang / Mitte nächster Woche hinziehen.
BTW, ich würd's gleich in Englisch schreiben, dann kann man das ganze später
einfacher z.B. bei sourceforge einstellen (ich hatte die GPL Frage gestellt, aber keine
Antwort bekommen, vielleicht wollt ihr das ja auch garnicht, sondern mit dem eigenen
Code reich werden - kann ich gut verstehen, würde ich auch gerne ;-) )

 

[MasterFX]

(BTW, wir hatten uns noch nicht auf
eine Sprache geeinigt, aber ich hoffe doch inständig, dass es C sein wird).

Aber sicher!

sollten wir beim Design ISP Möglichkeiten berücksichtigen.

Genau, wenn Platz da ist auf jeden Fall nen ISP Header oder extern mir irgendeinem Ministecker, wobei das schon wieder zu speziell wird.

BTW, ich würd's gleich in Englisch schreiben, dann kann man das ganze später
einfacher z.B. bei sourceforge einstellen

Von mir aus kein Einwand.

(ich hatte die GPL Frage gestellt, aber keine
Antwort bekommen,

Von mir aus gern, GPL ist mir immer sympatisch.

 

[ulf_l]

Hallo

- C fände ich auch am sympatischsten (trotz (*))
- ISP sollte auf jeden Fall drauf
- Für Englisch fällt mir kein vernünftiger Grund ein
- GPL wäre mir gleich, da ich mich aus der SW wohl raushalte *

Gruß Ulf

 

[hottube]

Mit Zeile "000" muss man gar nicht anfangen. Angefangene Projekte in dieser Richtung gibt es schon ein paar. Ein gut dokumentiertes ist hier zu finden: http://code.google.com/p/strobit/
Auch gut gemacht die RFM12 Tutorial des selben Autors - die Dinger sind Tricky!

Zum Starten ist meine Empfehlung mit Evaluation Boards zu arbeiten und die HW später an die Software anzupassen. .B. von Pollin Funk-AVR-Evaluations-Board für Atmegas und RFM12.

 

[ulf_l]

Hallo

Der Tip zum RFM12 Tutorial ist prima . Das war für mich bisher die einzige "Unbekannte".
Nur schade, daß nach Teil 3a Schluß ist.

Gruß Ulf

 

[zvpunry]

Ich beobachte diesen Thread nun schon seit er existiert, bin immer dabei Kleinigkeiten zu basteln (je nach dem was man aktuell braucht). Um Funk für Kamera und Blitz bin ich bisher gut rum gekommen, für kabelloses Blitzen nehm ich den ST-E2 aber Funk wär halt schon besser.

- Für Englisch fällt mir kein vernünftiger Grund ein

Eventuell bekommt man fremdsprachige Mitentwickler, siehe Thread in dem angefangen wurde das Protokoll zwischen Kamera und Objektiv zu zerlegen. Sourcecode, Kommentare im Sourcecode und Protokoll- und API-Dokumentation sollte man vielleicht doch nicht nur auf Deutsch verfassen.

- GPL wäre mir gleich, da ich mich aus der SW wohl raushalte *

Ich fände GPL auch für Hardware-Designs (z.B. eagle dateien, sofern man diese Software verwendet) sinnvoll. Generell ist die GPL auch mir sehr sympatisch, da sie ganz einfach verhindert daß ein Projekt auf einmal closed-source ist.

Ich persönlich habe hier auch noch ein bündel RFM12er rumliegen, in Verbindung mit kleinen m88ern und ds18s20 (zusammen remote-temperaturfühler). STK500, usbprog, haufenweise Lochraster, Steckbretter, Frickeldraht und Kleinteile sind auch vorhanden. Ich würde sicher mal auch in diese Richtung experimentieren, aber wie viel Zeit ich haben werde kann ich nicht so recht abschätzen. Ich werde definitiv weiter beobachten, da mich das Projekt interessiert.

 

[jar]

Ich beobachte diesen Thread nun schon seit er existiert, bin immer dabei Kleinigkeiten zu basteln (je nach dem was man aktuell braucht).
Ich persönlich habe hier auch noch ein bündel RFM12er rumliegen, in Verbindung mit kleinen m88ern und ds18s20 (zusammen remote-temperaturfühler). STK500, usbprog, haufenweise Lochraster, Steckbretter, Frickeldraht und Kleinteile sind auch vorhanden. Ich würde sicher mal auch in diese Richtung experimentieren, aber wie viel Zeit ich haben werde kann ich nicht so recht abschätzen. Ich werde definitiv weiter beobachten, da mich das Projekt interessiert.

ich auch, nur wenig Zeit

ab Februar mache ich mit

 

[logout1984]

Hi *,

FYI, hab am Wochenende ein bisschen am Protokoll gearbeitet (poste ich im
laufe der Woche) und mir die verschiedenen RFM12 Bibliotheken angesehen.
Hier sind insbesondere die Arbeiten auf
http://www.mikrocontroller.net/articles/AVR_RFM12 interessant.

Für die Übertragung der verschiedenen Parameter find ich den RFM Protokoll
Stack interessant , s.a.
http://www.mikrocontroller.net/articles/RFM12_Protokoll_Stack
da eigentlich schon alles da ist (CSMA/CD, Prüfsummen, ACKs etc.) allerdings
wäre für den Flash Broadcast ein "Hack" erfroderlich damit der rechtzeitig bei
den Slaves ankommt (da wäre der Protokoll Stack zu langsam)
Im Artikel http://www.mikrocontroller.net/articles/AVR_RFM12 wird
auch noch auf rfm12lib von das-labor.org verwiesen, auch nicht schlecht
(beim RFM12_Protokoll_Stack bin ich mir nicht sicher ob der z.B. hardware SPI
unterstützt - ich hab's zumindest im source noch nicht gefunden, die rfm12lib
tut das.
http://code.google.com/p/strobit hab ich mir auch mal ein bisschen näher
angesehen, finde das aber nur bedingt gut gemacht (nur ein Kritikpunkt von
vielen wäre z.B. die Funktion delay_us die hier implementiert ist... kann man
so machen, aber warum nicht gleich die avr-libc verwenden, zumal ich nicht
ausschließen würde, das der compiler die nops in delay_us so wie da
geschrieben nicht gnadenlos weg optimieren würde)


Bei den Implementierungen wird übrigens gerne der RFM12 Digitalfilter
eingesetzt. Zwar bedeutet das zusätzlichen Overhead (+ 2 byte, sodass die
Auslösung bei 8 Bit broadcast 3 Byte erfordert, hat aber den großen Vorteil,
dass der AVR nicht den Schmutz rausfiltern muss und z.B. der SPI bus nicht
unnötig Daten überträgt).

Gruß
Logout