Moin,
hat schon mal jemand etwas aus dem Projekt nach gebaut (ausser dem Fredi )
Ich finde nur die Sourceforg Seite, http://embeddedloconet.sourceforge.net/

Besonders Interssiert mich wie die Oszilatoren den ablauf am Loconet beinflussen,
da ich nur 8Mhz Oszilatoren da habe, und am Liebsten mit dem Internen arbeiten würde.

Frohes Neues Lars

Hallo Eisenhorn,

ich habe meine gesamte Steuerlogik mit Arduinos und der mmrwa-LoconNet-Bibliothek (Nachfolgeprojekt von EmbeddedLoconet) aufgebaut. Ich habe mir auch schon mal Gedanken darum gemacht, ob man mit anderen Taktfrequenzen arbeiten kann, bin aber noch zu keinem Schluß gekommen.

Es zwei mögliche Fehlerquellen: (1) Takt zu langsam (8 statt 16MHz) und (2) Takt zu ungenau (interner Resonator, ggfs. nicht kalibriert, statt externem Quarz).

Prinzipiell ist es möglich, einen Atmega mit 8MHz zu takten und am LocoNet zu betreiben. Der FREDI-Bausatz von Peter Giling arbeitet mit einem Atmega8L8 (maximale Taktrate 8MHz) und einem passenden 8MHz-Quarz. Allerdings weis ich nicht, ob die FREMO-Leute MRRWA einsetzen, oder eine eigene LocoNet-Bibliothek geschrieben haben.

Nun aber zurück zu MRRWA: Nachdem wir wohl davon ausgehen können, dass ein 8MHz-Atmega schnell genug ist, um die Daten zu verarbeiten, bleibt die Frage, wo es im Code Timing-Probleme geben könnte. Soweit ich bisher feststellen konnte, kann es da nur zu Problemen kommen, wenn die internen Timer verwendet werden. Das wiederum passiert dort, wo die Bits vom LocoNet gelesen bzw. auf das LocoNet geschrieben werden. An dieser Stelle musste ich meine bisherigen Debugging-Versuche abbrechen. Der MRRWA-Code mutiert dort von Arduino-Code zu "direktem" AVR-Code, d.h. man muss sich die Makros und Registerbezeichnungen heraussuchen. Ich vermute, dass man nur den Timer Prescaler abhängig von der Taktrate richtig einstellen muss und dann alles läuft. Mangels intimer Kenntnis der Registernamen, Zeit und passender Hardware habe ich das aber noch nicht ausprobiert.

Zum Thema Quarz vs. interner Resonator kannst du dir ja mal anschauen, wie genau die Timer sind, wenn man den internen Resonator benutzt und wie viel Genauigkeit LocoNet erfordert. Etwas leichtes googlen hat aber gerade ergeben, dass der interne Resonator wohl nicht sonderlich genau ist und auch seine Taktrate mit der Temperatur ziemlich stark verändert.

Gruß,
fantux

Hallo Fantux,
Danke für die Schnelle antwort.

Zitat von fantux

---

Hallo Eisenhorn,


Prinzipiell ist es möglich, einen Atmega mit 8MHz zu takten und am LocoNet zu betreiben. Der FREDI-Bausatz von Peter Giling arbeitet mit einem Atmega8L8 (maximale Taktrate 8MHz) und einem passenden 8MHz-Quarz. Allerdings weis ich nicht, ob die FREMO-Leute MRRWA einsetzen, oder eine eigene LocoNet-Bibliothek geschrieben haben.

---

Ich dachte EmbeddeLoconet wäre die Bibliothek von Fremo zumindest sind in den deren Branch die Firmwear für Fredi und LoconetGateway enthalten.

mrwa-LoconNet-Bibliothek habe ich auch gefunden, ich habe aber kein andruino, und bin auch kein fan davon(eine ganz persönliche Vorliebe).

Laut spezifikation überträg das Loconet mit 16.66 KBaud +/-1.5%. http://www.digitrax.com/static/apps/cms/...onaledition.pdf
Ich habe schon uart Komunikation mit 9600Baud und internem oszilator gebaut habe angst das das ganze jetzt kippt.
Das ganze soll ehr erst mal ein Versuchsaufbau sein, später möchte ich die Schaltung natürlich mit externen Oszilator ausrüsten.

Warum sollten die internen timer probleme machen? in der sysdef.h müsste man doch nur den richtigen Takt einstellen oder?

Gibt es zu Emebedded Loconet noch eine ausführliche Doku was wozu ist ?
Gruß Lars

Hallo Eisenhorn,

Zitat von Eisenhorn

---

Ich dachte EmbeddeLoconet wäre die Bibliothek von Fremo zumindest sind in den deren Branch die Firmwear für Fredi und LoconetGateway enthalten.

---

Der Hauptentwickler, Alex Shepherd, ist IIRC Neuseeländer. Soweit ich weiß hat er mit FREMO nichts zu tun. Das schließt natürlich nicht aus, dass der Fremo trotzdem auf MRRWA aufsetzt. In dem Falle wäre wohl das nächste, zu prüfen ob und welche Änderungen Fremo am MRRWA-Code vorgenommen hat. Wenn die Timer gleich behandelt werden, könnte MRRWA auch direkt funktionieren.

Zitat von Eisenhorn

---

mrwa-LoconNet-Bibliothek habe ich auch gefunden, ich habe aber kein andruino, und bin auch kein fan davon(eine ganz persönliche Vorliebe).

---

Dann bist du, was das LocoNet angeht, aber out-of-date. Die Entwicklung des Codes findet nur noch in MRRWA statt. Der Code enthält inzwischen auch möglichkeiten, um z.B. Module per JMRI-SV oder Uhlenbrock-LNCV zu konfigurieren. Du kannst den MRRWA-Code auch ohne Arduino-IDE nutzen, du musst nur die Arduino-Library importieren. HowTos für WinAVR und Eclipse gibt es im Netz.

Zitat von Eisenhorn

---

Laut spezifikation überträg das Loconet mit 16.66 KBaud +/-1.5%. http://www.digitrax.com/static/apps/cms/...onaledition.pdf
Ich habe schon uart Komunikation mit 9600Baud und internem oszilator gebaut habe angst das das ganze jetzt kippt.
Das ganze soll ehr erst mal ein Versuchsaufbau sein, später möchte ich die Schaltung natürlich mit externen Oszilator ausrüsten.

Warum sollten die internen timer probleme machen? in der sysdef.h müsste man doch nur den richtigen Takt einstellen oder?

---

Um Bits zu empfangen/senden werden die intervalle zwischen den Taktflanken über Timer-Interrupts bestimmt. Ist der Timer nicht genau genug, passen die Intervalle nicht zu denen, die die anderen Module am Bus erwarten und du liest/sendest falsche Bits. Daher brauchst du erstmal hinreichend genaue Timer. Der interne Resonator ist möglicherweise nicht genau genug (d.h. läuft zu sehr zu schnell/langsam, sogenannte Uhren-Drift), um die korrekten Intervalle zu generieren. Wie stark der Resonator driftet, ist von der Betriebsspannung und der Umgebungstemperatur abhängig, d.h. der Wert ist nicht nur nicht korrekt, er ist nicht mal konstant! Man kann zwar mit einer von Atmel herausgegebenen Prozedur den Resonator kalibrieren, allerdings gilt diese Kalibrierung nur für eine bestimmte Spannung und Temperatur (ab Fabrik AFAIK 5V, 25°C). Diese Werte konstant zu halten dürfte im Mobaumfeld ein Ding der Unmöglichkeit sein. Schon aus einem LM7805 kommt in den seltensten Fällen 5,0V raus.

Soviel zu den möglichken Problemen. Ob die Drift des internen Resonators nun überhaupt ein Problem ist, bleibt noch zu untersuchen. Dazu musst du wissen, wie groß die Drift werden kann und wie genau die Timings der Taktflanken auf dem Bus sein müssen. Was du oben angegeben hast: "16.66 KBaud +/-1.5%" ist die Datenrate auf dem Bus, direkte Timing-Informationen lassen sich daraus nicht ableiten. Die Frage ist also, ob in der LocoNet-Spec noch mehr Informationen zu den Timings enthalten sind.

Neugierige Nebenfrage: Warum willst du denn den externen Quarz loswerden? Kosten tun Quarz+2*Kondensator ja nix.

Zu sysdef.h kann ich wenig sagen, da ich jetzt nicht mehr weis, auf welches System du dich beziehst. Einfach nur die Taktrate ändern wird aber vermutlich nicht ausreichen. Um das selbe Zeitintervall zu messen, brauchst du bei 16MHz doppelt so viele Timer-Ticks wie bei 8MHz. Das rechnet der bisherige Code soweit ich das überblicke nicht mit ein. Für Arduinos geht man AFAIK davon aus, dass die Chips immer mit 16MHz getaktet werden. Die Arduino-IDE bietet die Möglichkeit, durch etwas tippen in der Hardware-Spezifikation neue Boards zu erstellen, die andere Taktraten haben. Ob man an diese Information allerdings im Code rankommt, weis ich nicht. Weiterhin habe ich nach meinen bisherigen Analysen den Eindruck, dass im MRRWA-Code eine Unterscheidung nach er Taktfrequenz der CPU drin ist (was aber IMHO eingebaut werden sollte - Patch, anyone?).

Zitat von Eisenhorn

---

Gibt es zu Emebedded Loconet noch eine ausführliche Doku was wozu ist ?

---

Nein, gibt es nicht. Das muss man sich aus dem Code erpuzzlen - oder du Mailst einfach mal Alex Shepherd direkt an und fragst ihn. Mich würde das Thema auch interessieren.

Gruß,
fantux

Hallo,

zusammengegooglete Werte: Bit Time der Loconet-Spec: 60us mit (vermutlich) +-1,5% Toleranz. Der interne Resonator kann aber unter realistischen Bedingungen schon 10% falsch sein. Das würde darauf hindeuten, dass ein Betrieb mit dem internen Resonator wahrscheinlich nicht zuverlässig möglich ist.

Andererseits: Auf den kaufbaren Arduino-Boards ist für den Prozessor ein externer 16MHz-Resonator vorgesehen - kein Quarz! Unterliegt der einer ähnlichen Abweichung? Die Module auf meiner Anlage sind alle mit Quarz ausgestattet, den kauf-Arduino benutze ich nur zu Testzwecken. Ich hatte aber bisher noch keine Probleme damit, dass der kauf-Arduino am Loconet Bits verschluckt oder falsch gesendet hätte.

EDIT: Ich habe mich mal bei Reichelt umgeschaut. Es sieht so aus, dass externe resonatoren typischerweise 0,5% genau sind und nochmal 0,15% je Grad abweichen. Man hat also einen ziemlich großen Temperaturbereich, in dem die 1,5% eingehalten werden.

Gruß,
fantux

Moin

Zum Fremo Thema Olaf Funke, Martin Pischky haben aber auch zu embeddeLoconet beigetragen, die sind Fremo
Wie gesgat wenn man den Tarball für EmbeddeLoco net runter lädt sind dort gleich der Quellcode vom Fredi und LoconetGatewaye enthalten

Zum Oszilator ich habe nur einen 8MHz Oszilator da, sonst nur 3.33Mhz, wollte jetzt mal so eine kleine Bastelei mit 2-3 Loconet Teilnehmer vorbereiten und Testen, und mich dann nach und nach tiefer in den Code Fuchsen.
Dann bleibt es wohl erst mal bei einem Teilnehmer

Zitat von fantux

---

Dann bist du, was das LocoNet angeht, aber out-of-date. Die Entwicklung des Codes findet nur noch in MRRWA statt. Der Code enthält inzwischen auch möglichkeiten, um z.B. Module per JMRI-SV oder Uhlenbrock-LNCV zu konfigurieren. Du kannst den MRRWA-Code auch ohne Arduino-IDE nutzen, du musst nur die Arduino-Library importieren. HowTos für WinAVR und Eclipse gibt es im Netz.

---

EmbeddedLoconet kann doch auch LocoNet SV ist das nicht das Gleiche?
Wenn nein kann ich dann Überhaupt den Modulen per Intelibox Adressen zuweissen und deren Status auslesen?

In der sysdef.h werden bei EmbeddedLoconet die "Hardwear" vorgegben und eben den F_CPU wert,
die Beispiele arbeiten auch immer mit Unterschiedlichen Frequenzen. d.h. Denek ich soweit ich den Code Überblicke das
er sich an den F_CPU anpasst

Ich hätte auch noch eine Frage welceh modul benutzt du denn für das Loconet?

Danke für die Hilfe
Gruß Lars

Hallo,

Zitat von Eisenhorn

---

Zum Fremo Thema Olaf Funke, Martin Pischky haben aber auch zu embeddeLoconet beigetragen, die sind Fremo
Wie gesgat wenn man den Tarball für EmbeddeLoco net runter lädt sind dort gleich der Quellcode vom Fredi und LoconetGatewaye enthalten

---

ja, es scheint sich die Entwicklung etwas zu zerfasern. Zumindest sehe ich keine commiter aus dem Fremo auf MRRWA. Und EmbeddedLocoNet hat die letzte Code-Änderung 2011 erhalten. Ich vermute mal, dass FREMO einfach einen Fork der alten EmbeddedLocoNet-Bibliothek benutzt.

Zitat von Eisenhorn

---

Zitat von fantux

---

Dann bist du, was das LocoNet angeht, aber out-of-date. Die Entwicklung des Codes findet nur noch in MRRWA statt. Der Code enthält inzwischen auch möglichkeiten, um z.B. Module per JMRI-SV oder Uhlenbrock-LNCV zu konfigurieren. Du kannst den MRRWA-Code auch ohne Arduino-IDE nutzen, du musst nur die Arduino-Library importieren. HowTos für WinAVR und Eclipse gibt es im Netz.

---

EmbeddedLoconet kann doch auch LocoNet SV ist das nicht das Gleiche?
Wenn nein kann ich dann Überhaupt den Modulen per Intelibox Adressen zuweissen und deren Status auslesen?

---

Nein, LocoNet SV und LNCV sind unterschiedliche Systeme. "LocoNet SV" sind die "System Variables", das kommt AFAIK aus dem Umfeld von MRRWA, JMRI und NMRA. LNCV sind die "LocoNet Configuration Variables", das ist ein Uhlenbrock-eigenes System. Beide machen letztendlich das selbe: Sie stellen einen Raum von 2^16 Laufzeit-Konfigurierbaren Werten mit einem 2^16 Wertebereich bereit. Es gibt zwei kleine Unterschiede: Bei LNCVs ist Adresse 0 immer die Moduladresse, SV's sind da frei. Und beide verwenden leicht unterschiedliche Nachrichtenformate. Uhlenbrock-Geräte sprechen nur LNCV. Du kannst aber mit JMRI und einem LocoNet-Buffer aus SVs schreiben. Der aktuelle SVN-Code von MRRWA unterstützt sowohl SV als auch LNCV. Allerdings ist das Interface für den Modulentwickler noch nicht sonderlich schön, aktuell läuft beides nebenher, d.h. wenn dein LocoNet-Modul beides unterstützen soll, musst du an zwei Interfaces andocken. Den Code dafür mal schöner zu machen steht auf meiner Todo-Liste, aber die ist leider lang

Zitat von Eisenhorn

---

In der sysdef.h werden bei EmbeddedLoconet die "Hardwear" vorgegben und eben den F_CPU wert,
die Beispiele arbeiten auch immer mit Unterschiedlichen Frequenzen. d.h. Denek ich soweit ich den Code Überblicke das
er sich an den F_CPU anpasst

---

Ah so. Das hat mich jetzt inspiriert, nochmal durch den MRRWA-Code zu suchen. Dort findet man folgende Zeile:

#define LN_BIT_PERIOD  (F_CPU / 16666)
 

F_CPU ist sonst nirgends definiert, das wird wahrscheinlich von der Arduino-IDE zur Verfügung gestellt. Da kann man einen Wert "f_cpu" für verschiedene Boards konfigurieren. Für einen 16MHz-Arduino kommt da ca. 960 heraus, das ist die Anzahl der Timer-Ticks bis zum nächsten Bit.

Letztendlich passt sich also dieser Code der soll-Taktrate des Chips an. Wenn du mit dem EmbeddedLocoNet-Code arbeitest, solltest du prüfen, ob du etwas ähnliches dort finden kannst.

Wenn du übrigens nur herumprobieren willst und keine Quarze da hast, würde ich mir weniger sorgen wegen der Zuverlässigkeit der Übertragung machen. Googlen hat auch noch ergeben, dass die 10% Abweichung die Spezifikation von Atmel ist, die meisten Chips aber wesentlich genauer sind. Unter die Bahn schrauben würde ich so ein Modul nicht, weil man nie weiß, ob es zuverlässig arbeitet. Aber zum basteln auf dem Schreibtisch hätte ich da keine Sorge.

Zitat von Eisenhorn

---

Ich hätte auch noch eine Frage welceh modul benutzt du denn für das Loconet?

---

Ich habe meine Module alle selber gebaut. Auf GitHub habe ich den Code und die Vorlagen für die Hardware öffentlich gemacht - bisher hat es aber noch niemanden interessiert Leider keine Eagle-Files, ich baue meine Hardware als Paper-PCB, das ist schneller und billiger als Platinen zu ätzen. Wie du RJ-11-Buchsen für LocoNet auf Streifenrasterplatinen bekommst, habe ich in einem anderen Thread schonmal bebildert beschrieben.
Den Schaltplan muss man sich bei Bedarf aus den Lochrasterplatinen zurückübersetzen - die Schaltpläne sind aber allgemein sehr einfach. Üblicherweise ein Spannungsregler (manchmal ein Schaltregler), ein Breadboard-Arduino und gegebenenfalls ein ULN2803 um Relais zu treiben bzw. Pullups für s88-kompatible Eingänge.

Gruß,
fantux

Moin Fantux, ich werde einfahc mal etwas Basteln, und hier die resultate Posten.

Dein System sieht auch super aus.

Update:

Kann man die Intelibox LocoNet SV programmieren mit den Richtigen einstellungen im interface,
und dem richtigen programm? Allerdings kann ich dort nur LocoIO programmieren zumindrest bei JMRI und Rocrail,
oder übersehe ich etwas?

Gruß Lars

Hallo Eisenhorn,

Zitat von Eisenhorn

---

Moin Fantux, ich werde einfahc mal etwas Basteln, und hier die resultate Posten.

Dein System sieht auch super aus.

---

Danke - ich freue mich auch auf deine Ergebnisse.

Zitat von Eisenhorn

---

Kann man die Intelibox LocoNet SV programmieren mit den Richtigen einstellungen im interface,
und dem richtigen programm? Allerdings kann ich dort nur LocoIO programmieren zumindrest bei JMRI und Rocrail,
oder übersehe ich etwas?

---

Ich glaube, ich verstehe die Frage nicht ganz. Zunächst: Die Intellibox kann mit LocoNet SV nichts anfangen. D.h. du kannst aus dem Menü der Intellibox heraus keine Nachtichten generieren, die LocoNet-SV-Werte beeinflussen. Allerdings ist das LocoNet nicht durch die Intellibox beschränkt. Du kannst beliebige Nachrichten darüber schicken, die IB kann dann vielleicht nichts damit anfangen und ignoriert diese Nachrichten. Die Module, die SV-Nachrichten interpretieren können, werden trotzdem richtig damit umgehen.

Prinzipiell kannst du also vom PC aus mit dem richtigen Programm und einer Verbindung zum LocoNet die SV-Programmier-Nachrichten erzeugen und so deine Module konfigurieren. (Nebenfrage: Was meinst du hier mit "Interface"? LocoBuffer? Märklin Interface? Schnittstelle der IB1 oder 2? Jeweils mit Märklin- oder LocoNet-Protokoll?) Ich habe selber mit SV keine Erfahrungen, gehe aber eigentlich davon aus, dass zumindest JMRI das unterstützt. (An dieser Stelle kurze Pause, um JMRI mal zu starten...) Ich sehe: JMRI hat scheinbar nur eine Oberfläche, um die SV's für einige wenige hartcodierte Module zu ändern. Das ist in der tat blöd - du müsstest dann die Programmiernachrichten alle von Hand in die LocoNet-Oberfläche einhacken. Das klingt, als solltest du einen Bugreport zu JMRI schreiben.

Ich habe mit der Programmierung über Software keine Erfahrung. JMRI habe ich nur benutzt, um am PC untersuchen zu können, was für Nachrichten über das LocoNet gehen und damit herauszufinden, wie die LNCV-Programmierung funktioniert. Programmiert habe ich meine Module dann alle per LNCV aus dem Menü der IB heraus.

Gruß,
fantux

Zitat von fantux

---

Hallo Eisenhorn,

Ich glaube, ich verstehe die Frage nicht ganz. Zunächst: Die Intellibox kann mit LocoNet SV nichts anfangen. D.h. du kannst aus dem Menü der Intellibox heraus keine Nachtichten generieren, die LocoNet-SV-Werte beeinflussen. Allerdings ist das LocoNet nicht durch die Intellibox beschränkt. Du kannst beliebige Nachrichten darüber schicken, die IB kann dann vielleicht nichts damit anfangen und ignoriert diese Nachrichten. Die Module, die SV-Nachrichten interpretieren können, werden trotzdem richtig damit umgehen.

Prinzipiell kannst du also vom PC aus mit dem richtigen Programm und einer Verbindung zum LocoNet die SV-Programmier-Nachrichten erzeugen und so deine Module konfigurieren. (Nebenfrage: Was meinst du hier mit "Interface"? LocoBuffer? Märklin Interface? Schnittstelle der IB1 oder 2? Jeweils mit Märklin- oder LocoNet-Protokoll?) Ich habe selber mit SV keine Erfahrungen, gehe aber eigentlich davon aus, dass zumindest JMRI das unterstützt. (An dieser Stelle kurze Pause, um JMRI mal zu starten...) Ich sehe: JMRI hat scheinbar nur eine Oberfläche, um die SV's für einige wenige hartcodierte Module zu ändern. Das ist in der tat blöd - du müsstest dann die Programmiernachrichten alle von Hand in die LocoNet-Oberfläche einhacken. Das klingt, als solltest du einen Bugreport zu JMRI schreiben.

Ich habe mit der Programmierung über Software keine Erfahrung. JMRI habe ich nur benutzt, um am PC untersuchen zu können, was für Nachrichten über das LocoNet gehen und damit herauszufinden, wie die LNCV-Programmierung funktioniert. Programmiert habe ich meine Module dann alle per LNCV aus dem Menü der IB heraus.

Gruß,
fantux

---

Genau das meinte ich, das man die Intelibox quasi nur als interface benutzt, wenn ich es richtig verstanden haben kann man mit unterschiedlichen Protokolen mit der Intelibox kommunizieren. Mal sehen heute abned bin ich wieder im Verein dort ist eine intelibox.

Viele Grüße Lars

Hallo Eisenhorn,

ja, das geht. Du musst an der IB und am Rechner einstellen, das über die serielle Schnittstelle LocoNet gesprochen werden soll. Falls du eine IB1 hast, wirst du aber wenig Spaß haben, weil die bekanntermaßen dauernd abstürzt, wenn man die serielle Schnittstelle nutzt. Langfristig kannst du dir einen 16MHz-Quarz besorgen und mit einem Atmega und den MRRWA-Beispielcode für einen LocoBuffer benutzen, um dir einen LocoBuffer zu bauen.

Gruß,
fantux

Mhm Angemeldet hat sich der Kontroller, aber programmieren ging noch nicht.
Mal sehen wann ich weiter komme jetzt ist wieder Uni und das Modul wo die Steuerung rein soll muss auch weiter gebaut werden

Gruß Lars

Moin,

mal ein paar Sachen...

Ob man einen externen Quarz oder Keramikresonator nimmt, ist nach meinen Erfahrungen fast egal. Ich nehme in der letzten meist den Keramikresonator weil es 2 Teile weniger zum Löten sind. Die ideale Taktfrequenz kann man ausrechnen. Das steht auch in den Datenblättern von Atmel. Für LocoNet ist eine Frequenz von 7,3728 MHz (oder ein vielfaches davon) ziemlich gut. Ein Stück weit ist das natürlich auch davon abhängig welche Strategie man zum Senden und Empfangen von LocoNet benutzt (Software-UART, Hardware-UART, etc). Mit 8Mhz ist man noch relativ dicht an einem sinnvollen Takt. Mit dem internen Takt der Atmegas geht es grundsätzlich auch. Leider ist der interne Quarz der Atmegas nicht immer sonderlich genau. Ohne weitere Maßnahmen kann es daher passieren das es bei Temperatur-Schwankungen etc zu Fehlfunktionen kommt. Auf Dauer sollte man daher einen externen Taktgeber vorsehen.
In den LocoNet-AVR-Projekten stellt man über F_CPU die Frequenz ein. Das kann an unterschiedlichen Stellen erfolgen: in der sysdef.h, im makefile, in den Eigenschaften des Atmel-Studio-Projekts oder bei Arduino in der boards.txt.
Im FREMO gibt es derzeit etwa eine handvoll halbwegs aktive LocoNet-Entwickler. Allerdings werden eher wenige reine LocoNet-Sachen entwickelt, die Aktivitäten liegen zur Zeit mehr bei Stellwerks- und Blocktechnik.
Mit mrrwa und Arduino wird gelegentlich auch gearbeitet. Es gibt auch eine fremointerne Arduino-Mailingliste. Hier liegt der Schwerpunkt zur Zeit eher bei Bahnübergangs-Steuerungen und ähnlichen Sachen.
Die Mrrwa-Library basiert auf den ln_sw_uart-Routinen von Alex. Im Fremo wird überwiegend ln_swtx_hwrx_uart.c von Stefan eingesetzt.

Heiko