Zitat von: Brasletti am 29 Dezember 2017, 14:11:55
Den ProMicro kann man doch auch so flashen dass der original Bootloader weg ist, oder? So dass die Serielle Anbindung auch ohne Unterbrechung zur Verfügung steht.
Die Dinger sind zickiger, als ich das erhofft hatte - es gab auch im MySensors-Forum mind. einen Thread, in dem jemand (ergebnislos) gefragt hat, wie man ein RS485-HW-Serial-GW damit an's Laufen bekommt.
Kurz: das Ding zu flashen, ist schon ein Glücksspiel, ich habe (erst ohne, dann mit Reset-Button) mehrere Anläufe gebraucht, um Blink mit einer seriellen Ausgabe (an USB) zum Laufen zu bekommen. Mit dem RS485-GW-Sketch und HW-Serial1: Keine Ausgabe, nicht mal über eine testweise Ausgabe in before().
Verdacht: Bootloader und MySensors vertragen sich nicht, werde noch ein wenig damit rumspielen (ggf. auf MySensors den alten Thread aufwärmen) und es ggf. mal über die SPI-Schnittstelle mit flashen versuchen. Kann sein, dass damit der Bootloader hops geht, aber wir werden sehen...
Ich denke der orginale Bootloader muss eh weg. Sonst würde ein NanoCul wahrscheinlich auch nicht funktionieren.
Das mit dem Bootloader verstehe ich nicht: wieso muß der weg?
Bei einem Nano ist das was anderes (da bleibt in der Regel der Standard-Bootloader drauf), und die serielle Kommunikation läuft da über den FTDI/CP2102/CH340G...
Die muß bei dem Pro Micro der Bootloader - jedenfalls während des flashens - machen. Wie es aussieht, tauscht hier die IDE auch den Bootloader je nach definiertem Board: Die USB-Kennung ändert sich, wenn man eine andere Variante des Pro Micro auswählt und einen Sketch draufgeflasht hat. Allerdings stimmen die timings schon bei Blink nicht, die LED geht sofort wieder aus, sollte aber doch eigentlich für 1 Sek (bzw. länger) angeschaltet bleiben. Sehr mysteriös...
Die Diskussion um den ProMicro sollten wir aber ggf. woanders fortsetzen, auch wenn's interresant ist...
Zitat von: Beta-User am 30 Dezember 2017, 13:14:56
Verdacht: Bootloader und MySensors vertragen sich nicht, werde noch ein wenig damit rumspielen (ggf. auf MySensors den alten Thread aufwärmen) und es ggf. mal über die SPI-Schnittstelle mit flashen versuchen.
Davon bin ich ausgegangen.
Die Teile über die IDE per USB zu flashen fand ich easy. (Habe vor 1-2 Jahren mal ein paar HID-Devices damit gebaut; HID= Maus, Tastatur)
Frage: Seht ihr den MAX487 Anschluss so wie im Screenshot ?
ed: Ich meine damit RX,TX,IRQ...
Mod: ich habe das Thema mal gesplitted.
Ja sehe ich auch so (den Anschluss an den ATMega32U4).
So wie ich das sehe ist auf den ProMicros ein Arduino Bootloader drauf, der nach jedem Reset 5 Sec auf die Verbindung zur IDE wartet. Dazu gibt es aber Alternativen, einen eigenen Bootloader kann man wohl mit LUFA machen http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/index.html (http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/index.html).
Der eigentliche Amtel ATMega32U4 Bootloader ist wohl ein DFU Bootloader der Pro Micro nutzt aber den HWB Pin nicht.
...das verstehe wer will...
Der Reihe nach: War kurz weg, Laptop war an, serial monitor der IDE offen. Ich komme wieder und sehe: Es wird doch was auf die serielle Konsole gespuckt, und die printouts passen auch noch zu MySensors! Da werde ich dann mal ein Modul an RX/TX klemmen :) .
Vorhin war da noch überhaupt nichts zu erkennen, und das war auch keine Frage von Sekunden :o .
@Ranseyer: Danke für's Splitten!
Verkabelung sollte passen.
@Brasletti
Das mit dem eigenen Bootloader wäre schon irgendwie nett, aber entweder sollte man den dann bei MySensors direkt einpflegen und auch längerfristig zur Verfügung halten. Das übersteigt meine Fähigkeiten etwas... Feel free, wenn du da Erfahrung und Kapazität hast.
Jedenfalls für's erste: Entwarnung.
Die Flasherei ist mit dem ProMicro trotzdem ungewohnt: Die IDE muß den Chip ja resetten, damit der Bootloader kommt und dann das Übertragen des eigentlichen Programmcodes starten kann. Soweit eigentlich nichts ungewöhnliches, nur dass dabei eben auch die USB-Verbindung gekappt wird und erst wieder hergestellt werden muß. Das klappt manchmal, oft aber auch nicht, und tendenziell dann nur, wenn man zum Beginn der Übertragung erst den Reset-Pin von Ground nimmt. Steht zwar so auch auf Arduino.cc, aber blöd ist's trotzdem. Unter Linux ist das ggf. in dem Fall sogar etwas frickeliger, weil hier die Schnittstelle wechseln kann, unter der die IDE den Chip vermutet (ging bei mir lustig zwischen ttyACM3 und ttyACM4 hin und her, blödestenfalls ging es bis ttyACM8...).
Dann rutscht mal gut!
Beta-User
Als node scheinen die ProMicros zu funktionieren. Siehe hier https://forum.mysensors.org/topic/5336/gateway-using-atmega32u4/2 (https://forum.mysensors.org/topic/5336/gateway-using-atmega32u4/2) Nur als Gateway scheinen sie problematisch zu sein.
Bootloader programmieren bin ich leider auch nicht so bewandert... und einlesen dauert immer so lange :(
@Ranseyer: Bezüglich der Beschaltung des Max ist mir gerade aufgefallen dass die Tabelle in Mysensors nur aussagt welche PWM Pins nicht zu verwenden sind (in Verb. mit AltSoftSerial). An die Anschlüsse de und re des Max muss auf jeden Fall Pin 2 bzw. Kannst auch Pin 3 (INT0 wie beim ATMega328) nehmen dann muss das aber
// Define this to enables DE-pin management on defined pin
#define MY_RS485_DE_PIN 2
nach
// Define this to enables DE-pin management on defined pin
#define MY_RS485_DE_PIN 3
geändert werden.
Hier https://www.mikrocontroller.net/topic/434799 (https://www.mikrocontroller.net/topic/434799) wird berichtet das der ATMega32U mit dem Original Bootloader wohl mit den Interupts (was ja die Übertragung per MAX und Pin 2 ja sind) zickig sein kann.
Danke, dann also eher Pin3 oder was meint Ihr ?
ed:
ZitatThe Pro Micro has five external interrupts, which allow you to instantly trigger a function when a pin goes either high or low (or both). If you attach an interrupt to an interrupt-enabled pin, you'll need to know the specific interrupt that pin triggers: pin 3 maps to interrupt 0, pin 2 is interrupt 1, pin 0 is interrupt 2, pin 1 is interrupt 3, and pin 7 is interrupt 4.
Also z.B. die Frage ob hier auf irgend einen anderen Code Rücksicht genommen werden sollte...
Wenn man das sauber dokumentiert, kein Problem. Dann kannst Pin 3 nehem.
Der Einfachheit halber tendiere ich jedoch eher zu Pin2. So werden Fragen vermieden.
Das mit dem Pin habe ich nicht verstanden. Welchen Grund gibt es genau, statt 2 die 3 zu nehmen?
Wenn es die Intx-Zuordnung sein sollte, wäre es besser, das auf Code-Ebene zu fixen, oder verstehe ich da was falsch? Würde also auch eher mit Brasletti dafür votieren, bei Standards zu bleiben
Habe eben übrigens mal die Adafruit-Board-Def (https://github.com/sparkfun/Arduino_Boards) ausprobiert, bekomme aber auch damit keine Lebenszeichen, die am seriellen Monitor vollständig aussehen wie an einem "normalen" seriellen GW. Test war auch nicht erfolgreich - kann aber wie immer auch an allem möglichen anderen liegen.
Ich werde mal den Adafruit-based code via ISP draufbeamen, aber nicht mehr heute...
Zitat von: Brasletti am 31 Dezember 2017, 01:00:30
Langsam glaube ich wir sind mit dem promicro auf dem Holzweg.
so langsam glaube ich das auch, auch wenn ich nicht so recht verstehe, warum das nicht klappt. Ich bekomme ihn mittlerweile zuverlässig geflasht und hab das eine oder andere ausprobiert. Es scheint wirklich daran zu hapern, dass irgendwas durcheinanderkommt, sobald man "#define MY_GATEWAY_SERIAL" reinbastelt. Allerdings scheint der Code an sich zu laufen, wenn ich dann in der loop() prints an MY_SERIALDEVICE schicke, geht alles - und dahin sollten eigentlich auch die GW-Ausgaben gehen.
Also entweder ist das ein spezielles Problem des ProMicro (danach klangen manche Quellen wie z.B. die hier: https://github.com/arduino/Arduino/issues/1031 - die Fixes dort habe ich erfolglos getestet) oder das Problem liegt auf der MySensors-Seite (im internen Message-handling) und würde auch auf anderen Prozessortypen auftauchen. Jetzt habe ich aber vorläufig keine Lust mehr zum Testen >:( . Und mit den STM32-Boards, die hier noch rumliegen, ginge das zwar eventuell, aber ich habe auch keine vertiefte Erfahrung mit dieser Hardware, das wäre eigentlich was für jemanden, der da mehr Erfahrung hat.
Gruß, Beta-User
Also ich habe eine Testplatine fast fertig und noch 3-4 von den Pro Micros. Ich werde auf jeden Fall mal solche Platinen mitbestellen.
Wenn mit mehr Power würde ich mit dem Maple Mini starten. Davon hab ich reichlich und die laufen im MAPLE CUL super.
Das Problem: Ich denke ich werde (je nach Konditionen) in diesem Jahr noch Platinen bestellen. Und das ist ja nicht mehr lange...
Das mit den Platinen ist schon ok, und der ProMicro an sich scheint ja auch ok zu sein - nur als GW will er halt aus irgendeinem Grund nicht.
Wie gesagt, ich habe den Quellcode von MySensors und auch etwas Arduino-(AVR)-allg. kurz durchsucht und keinen Grund gefunden, wieso das daneben geht, sobald man das GW-"Feature" aktiviert. Aber an sich könnte ich zumindest mal testen, ob er als normale HW-Serial-Node taugt, gelötet ist ja (wenn auch mit "zu wenig Widerstand A-B").
Wenigstens mal Bilder, das sieht trotz Lochrasterplatine doch ganz ordentlich aus ::) ...
Zitat von: Brasletti am 31 Dezember 2017, 11:18:08
Sieht eigentlich gar nicht schelcht aus ;) !
Die Rückseite habe ich euch mit Absicht vorenthalten ;D , aber es sieht besser aus als mein LC-Modul-GW auf Nano-Basis, das sind nur ein paar Drähte und die zwei Boards...
Was Alternativen angeht: An sich geht es m.E. nur um das GW - und dafür wäre das Thema Stromverbrauch im sleep() zweitrangig. Dann kämen auch die günstigsten STM32F106-Boards in Frage, die kosten knapp über 2 Euro und sind auf allen gängigen Marktplätzen verfügbar (habe noch keine Erfahrung mit Ali). Zumindest theoretisch könnte man damit sogar mehrere serielle Schnittstellen@USB aufmachen, aber das ist eine andere Baustelle.
Aber ganz allgemein nochmal: An sich war nach meiner bisherigen Erfahrung (und meiner ersten Annahmen dazu) das GW (trotz AltSoftSerial) nicht das wirkliche Problem, sondern eher die normalen Nodes bzw. die Wechselwirkungen zwischen diesen. Hätte nur nicht geschadet, das auch noch ausschließen zu können.
Hier übrigens meine erste Sicht auf das Thema: https://github.com/ranseyer/MySensors-HW/blob/master/Experimental/GW-Sens-RS485-ProMicro/board.png
(Der Schaltplan bleibt so chaotisch bis klar ist ob/welchen Sinn das Thema macht)
PS: Habe es dann mal bei Pin3 für Interupt gelassen.
An den ProMicros als RS485 GW habe ich mir damals die Zähne ausgebissen. Das geht irgendwie nicht >:(
siehe: https://forum.mysensors.org/topic/5336/gateway-using-atmega32u4
Schlussendlich machen die auch keinen Sinn. Ist halt quasi der UART-USB Chip schon mit im AVR drin. Dafür braucht man aber ggfs spezielle Treiber und hat die Probleme beim flashen. Dann lieber einen normalen ProMini/Nano mit FTDI o.ä. nehmen und RS485 über AltSoftSerial.
Habe seit >1 Jahr einen Nano mit AltSoftSerial am laufen - ist sehr stabil, ohne jegliche Probleme.
Hallo Karlheinz2000,
Danke für die Rückmeldung, den Thread hatte ich dann auch gefunden und überlegt, ob ich mal nachhaken soll, ob du es doch noch hinbekommen hattest.
Auch, wenn es hier etwas OT ist:
Kannst du (hier oder ggf. im allg. RS485-GW-Fragen-Thread) kurz beschreiben, wie dein Netzwerk derzeit aussieht? Die Anzahl nodes, Spannungsversorgung zentral @5/12V, Baudrate, #Children und Sendehäufigkeit wäre z.B. interessant.
Ansonsten finde ich den ProMicro an sich nicht mehr soooo problematisch (außer, dass er als RS485-GW scheinbar (?,s.u.) nicht will). Man muß halt wissen, dass man den Reset durchführen muß kurz vor dem Start des Upload-Vorgangs. Treiberthemen hatte ich bislang keine, nutze aber auch nur Ubuntu und Debian, die erkennen das Teil ohne weiteres.
AlsSoftSerial hat so seine Tücken, habe dazu noch das hier https://forum.mysensors.org/topic/5051/rs485-stress-test und das hier gefunden: https://github.com/mysensors/MySensors/issues/954, es wäre also schon besser, wenn man das auf "einfachem" Weg loswürde...
(OT: Ich hatte etwas Mühe bei meinen ersten Versuchen mit den STM32F106-Boards, die mußte ich erst entsperren, um den "Melbourne"-Bootloader draufzubringen, das ist m.E. für Einsteiger eine deutlich größere Hürde als der Hinweis, dass man zum richtigen Zeitpunkt den Reset machen muß...)
Zurück zum ProMicro: Auch, wenn er sich nach dem Starten anders verhält als ein Nano (keine Serial-Printouts des MySensors-Headers, kein "Startup complete"), bin ich zwischenzeitlich nicht mehr so ganz sicher, ob das nicht doch läuft. Vielleicht ist der Startvorgang schlicht zu schnell abgeschlossen oder irgendwas in der Art. Wenn ich in die loop() MY_SERIALDEVICE.print-Anweisungen reinbaue, dann kommt dort raus, was hingehört. Vielleicht habe ich auch nur einen Fehler beim Verkabeln gemacht ::) . Werde das bei Gelegenheit nochmal testen, das kann aber wieder dauern.
Gruß, Beta-User
Ich habe RS485 nur genutzt, da ich an der Haustür ein Mysensors Display haben wollte und im Blechkasten der Klingelanlage nur schlechter Funkempfang war. Dafür waren in der Klingelleitung noch 2 Adern frei :-)
Mein RS485 Setup:
GW: Nano via USB an RPi und weiter via Ser2Net an RPi2 mit FHEM
Node 1: Display mit Mega2560
Node 2: TempSensor mit ProMini
RS485 Baud: 9600
Serial Baud: 115200
Spannungsversorgung dezentral 5V, GW über USB
Kabel-Länge ca. 15m
120 Ohm am GW und Node1
Der TempSensor sendet im Minutentakt, das Display bekommt ab und zu mal Daten, dann aber auch mal 10..15 Msgs hintereinander (so schnell wie FHEM ist)
Mit den Baudraten hatte ich viel rumgespielt, da ich anfangs Probleme mit verloren gegangenen Msgs hatte.
1. Problem war aber, dass der Mega2560 Bilder von SD Karte gelesen hatte und in der Zeit ankommende Msgs nicht verarbeitet hatte (RX Bufferüberlauf). Nachdem ich den RX Buffer vergrößert hatte lief in Richtung Display alles.
2. Vom Display Richtung FHEM sollte man nicht zu schnell senden. FHEM bekommt nicht alles mit. Ich habe mir die Kommunikation angeschaut: Am GW kommt auf USB Seite noch alles raus, Ser2Net überträgt auch alles, aber FHEM empfängt nicht alles. Einige 10ms Pause zwischen den Msgs hilft...
Zwischenzeitlich hatte ich auch einen Mega2560 als GW dran, da lief das GW mit 2 HW Serials. Quasi gleicher Sketch wie auf dem ProMicro. Nur kam aus dem ProMicro nie was raus...
Mag sein, dass bei viel Traffic AltSoftSerial überfordert ist, ich habe ja ein übersichtliches Setup.
Danke erst mal.
Schade, dass du auch verlorene Messages hattest, klingt wirklich danach, als träten Probleme wirklich vermehrt mit steigender Datenmenge auf (habe auch teilweise 10+ Werte auf einen Rutsch, teilweise auch Delays eingebaut, aber eigentlich den Eindruck, dass das geht, wenn die Kommunikation insgeamt passt).
Sind das MAX485-Chips bzw. Module oder "was besseres"?
Die Feststellung, dass sich FHEM ggf. verschluckt, ist interessant, ebenso, dass der Mega mit 2 HW-Serials ging (oder habe ich das falsch verstanden? Irgendwo hatte ich mal was gelesen, dass mit dem größeren Mega auch jemand Probleme gehabt haben soll)...
@Beta-User: Hast Du R7 von deinen Modulen runter?
[ist hier eigentlich OT, oder?]
Ja, bzw. auf allen bis auf GW+letzte Node (an der sind dann die 20k-Widerstände gg. 440-er ersetzt). Auch R5+6 (?) sind überall weg bis auf die am GW.
Ich habe zwischenzeitlich die zentrale 12V-Spannungsversorgung in Verdacht. Spannungsmäßig hängen GW am hp, Node 4 an einem eigenen 5V-Netzteil und der Rest an dem 12V-NT).
[Nochmal OT ;)]
So wie ich das verstanden habe, hättest du R5 und R6 drauf lassen können. Hier https://arduino-info.wikispaces.com/RS485-Modules (https://arduino-info.wikispaces.com/RS485-Modules) schön dargestellt.
[Immer noch OT ;D ]
Interessante Seite!
Dass die recht hohen "Seitenwiderstände" ziemlich egal sind, war mir klar, da war ja was mit 1/R1=1/R2+1/R2 usw.. Da ich aber schon mal dabei war wollte ich einen wirklich (weitgehend) der Norm entsprechenden Bus...
Mein Augenmerk liegt jetzt aber auch auf den anderen 4 Widerständen: da DE/RE verbunden sind, ist dort der effektive Widerstand niedriger, und die Werte werde ich auch nochmal kontrollieren (nur 1k verbaut?). Vielleicht kommen die Arduinos gerade dann aus dem Tritt, wenn sie wegen häufiger Sendeversuche dort einen undefinierten Zustand vorfinden (Spekulier, spekulier...).
Seltsam ist übrigens bei den Modulen auch, dass meine Messungen zuverlässig andere Widerstandswerte für einen der beiden 20k (R5/6) auswerfen: nur 10k.
Mal schauen.
@Beta-User:
- ja, habe normale MAX485 drauf
- ja, mit dem MEGA lief das GW mit 2x HW Serial problemlos
- das FHEM Daten verschluckt hat ist mit einem RPi1 passiert. Habe upgrade auf RPi2 gemacht. Das bringt ja ordentlich Performance. Vielleicht ist das jetzt besser....
Hast du R5/6 in der Schaltung gemessen? Entweder sind beide messtechnsich parallel, oder es sind wirklich 10k verbaut. Im link sind im Schaltplan 20k gezeichnet, aber auf der oberen Platine 10k bestückt...
Da ich eben gemerkt habe, dass ich das hier noch nicht kundgetan habe:
Mein 2.3.0-alpha-GW läuft jetzt bereits seit einiger Zeit als Kombi aus ProMicro und MCP2551 auf einer China-Platine, die ursprünglich einen TJA-irgendwas drauf hatte; der MCP2551 ist angeschlossen an Serial1 (also HW-Serial) mit 19200 Baud.
Wenn Interesse besteht, poste ich den Sketch dazu, aber da war eigentlich nicht besonderes einzustellen...Ungewohnt ist halt, dass der MySensors-typische "Startbildschirm" in der Regel nicht zu sehen ist, weil der Start schon durch ist, bis die Kommunikation mit der seriellen Schnittstelle des Rechners paßt (oder irgend so was halt; kann sein, dass ein wait(200) oder so in before() hilft, um dem zu begegnen, allerdings muß man beachten, dass uU. der serielle Monitor der IDE auf den richtigen Port zeigt - flashen und gleichzeitig den seriellen Monitor offen halten war @Linux kontraproduktiv, soweit ich mich entsinne).
EDIT: Den code für das GW habe ich hier (https://forum.fhem.de/index.php/topic,84814.msg811286.html#msg811286) gepostet, das angesprochene Warten ist in preHwInit(). Der code selbst enthält noch einiges an auskommentierten Versuchen, die man getrost löschen kann ::) . Bei Gelegenheit und Interesse liefere ich gerne eine "aufgeräumte" Version nach.