RS485 basierend auf Arduino ProMicro; gesplittet von:Fragen RS485 Gateway

Begonnen von Beta-User, 30 Dezember 2017, 13:14:56

Vorheriges Thema - Nächstes Thema

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Brasletti

Ich denke der orginale Bootloader muss eh weg. Sonst würde ein NanoCul wahrscheinlich auch nicht funktionieren.

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

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...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Ranseyer

FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Brasletti

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.
Der eigentliche Amtel ATMega32U4 Bootloader ist wohl ein DFU Bootloader der Pro Micro nutzt aber den HWB Pin nicht.

Beta-User

...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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Brasletti

Als node scheinen die ProMicros zu funktionieren. Siehe hier 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 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.

Ranseyer

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...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Brasletti

Wenn man das sauber dokumentiert, kein Problem. Dann kannst Pin 3 nehem.

Brasletti

Der Einfachheit halber tendiere ich jedoch eher zu Pin2. So werden Fragen vermieden.

Beta-User

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 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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

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...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

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 ::) ...


Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files