Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Sven, TDI, Heaterman, Finger, duese

Benutzeravatar
ferdimh
Beiträge: 6996
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh » Sa 4. Jan 2020, 15:46

Der Geschwindigkeitsunterschied C zu Assembler ist auf dem AVR noch relativ groß, weil der Compiler nicht so clever ist, wie auf dem PC.
Ich konnte da mal >50% rausholen.
C kann Inline-Assembler. Auch aufm AVR.
Damit kann man erstmal "drauf los" programmieren, und wenn die Zeit wirklich knapp ist, das relevante Stücken assemblieren.
Was sehr hilfreich ist: Ein unbelegter Portpin, der zu Beginn der Interruptroutine High gesetzt wird und am Ende (oder nach einer bestimmten kritischen Arbeit) wieder low geht, ermöglicht die Betrachtung der zeitlichen Situation mittels Oszi.

Benutzeravatar
xoexlepox
Beiträge: 4617
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox » Sa 4. Jan 2020, 19:21

Wenn ich mir das verlinkte Timing-Diagramm anschaue, geht es wohl darum, die Spannungspegel vor (oder nach?) einem Sync-Impuls zu bestimmen, richtig? In diesem Fall würde ich mir überlegen, ob die A/D-Wandler dafür überhaupt flink genug sind, oder ob eine kleine Hardware (mit z.B. vier Komparatoren) zur Problemlösung nicht einfacher wäre. Das würde m.E. zumindest zu einem wesentlich "entspannteren" Timing für den µC führen ;)

E_Tobi
Beiträge: 460
Registriert: Mo 12. Aug 2013, 22:26

Re: Der AVR-/ARDUINO-Faden

Beitrag von E_Tobi » Sa 4. Jan 2020, 19:33

Ich würde das so lösen:
Es gibt immer einen Sprung von 0V auf -5V vor einem validen Wert.
Eine kleine Schaltung verschiebt diesen Sprung auf +3.3 auf 0V, und legt das auf einen Portpin.
Über den erzeugst du einen interrupt auf fallende Flanken. Dann hast du das Zeitfenster 15µs bis 50µs um ein paar mal das Signal zu messen. Das sollte zeitmäßig locker gehen.

Das Frame ist zu Ende wenn im Mess-Zeitfenster immer noch -5V Anliegen.

Benutzeravatar
Fritzler
Beiträge: 7725
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler » Do 16. Jan 2020, 11:05

So wies aussieht werden wohl zukünftige GCC Versionen kein AVR Backend mehr haben:
https://www.mikrocontroller.net/topic/483643
(Johann ist einer derjenigen die sich da so richtig auskennen!)

So werden AVR Firmwares zwar noch mit uralt GCCs von 4 bis 7 gebaut, unter Linux eher kein Problem.
Aber zB bei Windoof10 gibts dann das Damoklesschwert, dass "inkompatible" Software beim halbjährlichen Zwangsupgrade einfach gelöscht wird und nicht mehr installierbar ist.
Microchip macht keinen Finger krumm das zu ändern*, denen sind die AVRs dann wohl doch nicht mehr so wichtig?

Inzwischen gibts ein Bounty, damit sich wer findet das zu ändern.
Also falls wer spenden will ;)

*Der AVR Support ist in deren properitären XC8 Compiler gewandert, aber die free Version kann nicht ordentlich optimieren.

(Irgendwie war es eine gute Idee komplett auf ARM zu wechseln)

ch_ris
Beiträge: 304
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris » Do 16. Jan 2020, 17:47

Naja, dann gibt's einen ARM-/Teensy-Faden. Vielleicht?
Je schneller je besser bitte. :?

Benutzeravatar
Fritzler
Beiträge: 7725
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler » Do 16. Jan 2020, 17:50

Also bei ARM kann ich auch so helfen, insbesondere STM32.
Aber nur ohne Gammlduino Untersatz ;)

Benutzeravatar
ferdimh
Beiträge: 6996
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh » Sa 18. Jan 2020, 14:06

(Irgendwie war es eine gute Idee komplett auf ARM zu wechseln)
Ich bin damit irgendwie immer noch nicht so richtig glücklich geworden. Naja, egal.

So wie ich das sehe, ist das technische TODO um den Support zu erhalten garnicht so kompliziert. Schwieriger dürfte sein, die erzeugten Patches auch durch die Bürokratie zu kriegen (davon abgesehen, dass ich das Ganze mal wieder eine saublöde Aktion finde).

sukram
Beiträge: 489
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram » Sa 18. Jan 2020, 14:51

Puuh. Ich war gerade über den Jahreswechsel dabei, aus verschiedenen AVR Projekten eins für mich zusammenzufrickeln. Konkret in dem Fall yaMBSiavr (in der Ausprägung eines auf Github gefundenen Bodenfeuchtefühlerprojektes) und Fritzlers BME280 Lib.

Ziel war es, ein kompaktes Raumthermostat, wahlweise mit Analog-In und oder Digital I/O sowie Modbus RS485 auf einem 50x50mm Platinchen herzustellen. Es gibt vergleichbare Module fertig, z.B. von Thermokon (WRF07 P rH AO2V RS485Modbus), da kostet aber der Raumfühler mit Luftfeuchte, Modbus und I/O (0-10V und Digital) mal eben lässig >200Eur...

Derzeit existiert ein kompaktes Layout auf Basis eines Mega88 (der bis zum 328 Pinkompatibel sein sollte). Mit Stepdown von 24V auf 5V und 3.3V LDO für den BME280.

Jetzt überlege ich aber, ob ich das so wirklich baue. Kostenmäßig lande ich irgendwo bei 25-30Eur pro Modul, wenn das Layout keine groben Schnitzer hat (würde bei jlcpcb einkaufen). Schaue ich mich da ein wenkg um, finde ich bei Olimex ein niedliches kleines ESP32 Board mit LAN und PoE für ca 18Eur. Da kommt noch ein BME280 dazu (ca 6Eur) und fertig. Gut, das Modul ist 75mm Lang (+ LAN Stecker) und ich muss eine Sternverkabelung ziehen (Kabel muss so oder so eingebaut werden), aber am Ende lohnt es sich doch gar nicht, weiter über den Eigenbau nachzudenken, oder? Ich meine, wenn jetzt auch der Compilersupport zurückgefahren wird (stört mich jetzt nicht, aber wer weiß, wenn ich in ein paar Jahren da mal dran muss?)

Dass ich dann per LAN und nicht Modbus verkabele, ist egal - die Technik ist eh in einem isolierten Netzwerk...

Benutzeravatar
Fritzler
Beiträge: 7725
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler » Sa 18. Jan 2020, 15:33

Na das ist jetzt nicht zum Panik schieben da.
Dein Projekt wirste schon noch durchziehen können.
Das wird schon so 10J dauern bis da was stirbt.
Die letzte WinAVR Version is ja auch von 2011 :mrgreen:

Du hast eher das Problem der hohen Temperaturabweichung beim BME280, also pack noch ein LM75 daneben.

Ein ESP32 Brett mit POE und so günstig?
Jetz bin ich neugierig, zeig mal bitte.
Ich hab mir mal ein POE Switch zugelegt, weil ich diverses Testequipment mit ModbusTCP und POE bauen will.
ferdimh hat geschrieben:
Sa 18. Jan 2020, 14:06
Ich bin damit irgendwie immer noch nicht so richtig glücklich geworden.
Wo drückt der ARM denn im Schuh?

sukram
Beiträge: 489
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram » Sa 18. Jan 2020, 17:50

Mal schauen, ich werde wohl erstmal vorsichtig in beide Richtungen experimentieren. Aufgrund akuter Faulheit bin ich aber geneigt, die weniger aufwendige Variante zu wählen.

Das ESP Board wäre das hier:

https://www.olimex.com/Products/IoT/ESP ... e-hardware

Ja, Versand und Steuer usw., aber trotzdem günstig, wenn man ein paar mehr kauft.

Mit den Temperaturwerten muss ich mal sehn, Platz für einen LM75 wäre noch, ggf. auch im TO Gehäuse mit langen Beinen - damit das Board weniger Einfluss hat.

Benutzeravatar
Fritzler
Beiträge: 7725
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler » Sa 18. Jan 2020, 22:20

Hmm, schade.
Leider nicht galvanisch getrennt.

Wenn die Temperatur so richtig genau sein soll gibts auchnoch sone Scherze:
https://www.mouser.de/ProductDetail/634-SI7051-A20-IM
https://www.mouser.de/ProductDetail/403-STS21

sukram
Beiträge: 489
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram » Sa 18. Jan 2020, 23:26

Den gibts auch in galvanisch getrennt, kostet knapp 7 eur mehr:
https://www.olimex.com/Products/IoT/ESP ... e-hardware

Ich bin mir nicht sicher, ob ich die Temperatur so genau brauche... Wichtig wäre mir nur, dass eine eventuelle Abweichung im Bereich 10-40°C linear bleibt, damit man die mit einem Offset rausrechnen kann.

Nunja. Schritt 1 wird erstmal ein Prototyp in Lochraster werden, da habe ich alles griffbereit. Wenn es klappt, dass der AVR mit 8 oder 10Mhz immer noch schnell genug ist, werde ich die Platine komplett auf 3.3V umstricken. Aber erstmal "im großen" Testen.

Benutzeravatar
Fritzler
Beiträge: 7725
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler » So 19. Jan 2020, 10:34

Ja, da hilft dann nur experimentieren.

Die bei Olimex sind aber auch lustig.
Ich weis jetzt nicht warum die das so gemacht haben:
Die verbauen einen "wunschlos glücklich" POE IC von SI -> SI3402.
Der hat die beiden POE Gleichrichter drinne und einen Flyback DC/DC für die galvanische Trennung.
Aber stattdessen nehmen die einen speziellen RJ45 MagJack mit integrierten Gleichrichter (die Dinger kosten mehr) und nutzen den DCDC des SI nur als StepDown.
Dahinter packen die dann einen 5V->5V DCDC für die galvanische TRennung.
Äh wädd?

Mit 25€ kom ich aber schon in die Selbstbauregion, vor allem hab ich dann einen STM32 drinne und muss nicht auf den ESP32 umschwenken.
(WLAN brauchts erstmal nicht).
Aber jetzt kenn ich einen wunschlos glücklich POE IC :lol:

Benutzeravatar
ferdimh
Beiträge: 6996
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh » So 19. Jan 2020, 13:03

Wo drückt der ARM denn im Schuh?
Komplexität überall.
Das ist weniger ein Problem des Prozessorkerns als der gefühlt 200 möglichen eingebauten oder nicht eingebauten Peripheriegeräte, die dann auch noch relativ komplex getaktet werden können.
Und dann gibts keine so etablierte Umgebung wie gcc+avr-libc, die "einfach so" da ist (=bei $LINUX_DISTRIBUTION enthalten). Wenn ich ein altes Projekt anfasse, gehts immer mit "wo habe ich denn jetzt die passenden libs+compiler archiviert?" los.
Das Problem würde sich mit steigender Etablierung lösen, wo sich wieder einzelne Typen (und auch Enwicklungsumgebungen) durchsetzen...

Benutzeravatar
Fritzler
Beiträge: 7725
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler » So 19. Jan 2020, 13:19

ferdimh hat geschrieben:
So 19. Jan 2020, 13:03
Und dann gibts keine so etablierte Umgebung wie gcc+avr-libc, die "einfach so" da ist (=bei $LINUX_DISTRIBUTION enthalten).
Doch ;)
https://developer.arm.com/tools-and-sof ... /downloads
Natürlich kannst du den GCC auch selber zusammennageln wenn du auf Schmerzen stehst*.
Der avr-gcc ist doch auch nicht direkt enthalten und muss als Binärpaket nachinstalliert werden.

* Das ist auch immer das Selbe: gcc+newlib in der neusten Version und dann gehts los.
https://wiki.ubuntuusers.de/Archiv/GNU_ARM-Toolchain/
ferdimh hat geschrieben:
So 19. Jan 2020, 13:03
Komplexität überall.
Das ist weniger ein Problem des Prozessorkerns als der gefühlt 200 möglichen eingebauten oder nicht eingebauten Peripheriegeräte
So viel gibts davon garnicht, das sind immer dieselben SPI/UART/I2C etc, nur eben sehr viele paralel davon im Silizium.
Daher darfste eben nicht sowas schreiben wie: uart2_putc(char c)
sondern: uart_putc(struct uartregs* uart, char c);
struct uartregs ist ein memory mappd struct der uart Register und das ist Teil des Inits für zB deine SPI LCD Lib, kommt also im Anwendungscode nicht an.
Aber ja für den SDIO/Ethernet Block musste mehr Hirnschmlz investieren, aber sowas hat der AVR erst garnicht.
ferdimh hat geschrieben:
So 19. Jan 2020, 13:03
die dann auch noch relativ komplex getaktet werden können.
https://www.youtube.com/watch?v=pQsyuiPl1WY
Will sagen: gib Stoff! Wenn du nicht Stromsparen musst, dann dreh per PLL alles so hoch wies geht ;)

Sobald du deine Grundblöcke hast ist das auch nurnoch mit Lego spielen.

ch_ris
Beiträge: 304
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris » Mi 29. Jan 2020, 13:05

Ich werd wahnsinnig.
Die aufgabe: einzelne Bytes über die serielle schnittstelle an den Labtop mit win10 schicken. Schnell.
Hab das getestet mit einem Uno, leuft.
Dann halbfertig aufgebaut mit Nano (CH340), hier kommt nur noch mist am laptop an, bei baudraten größer 230400.
Am Kabel liegts nicht, hab 3 ausprobiert.
stromversorgung usb/batterie macht auch keinen unterschied.
Treiber? ist 3.5.2019.1
unter win7 hatte das funktioniert bis hoch zu 921600. :(

Sir_Death
Beiträge: 2447
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death » Mi 29. Jan 2020, 15:20

schon mal einen anderen nano genommen? - nicht dass der Eine einen Schaden hat?

ch_ris
Beiträge: 304
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris » Mi 29. Jan 2020, 17:35

ja hab ich.
hab auch bei den erweiterten seriellen einstellungen über den gerätemanager nix ausser fifo ja/nein.
da gabs doch noch mehr! latency etc.?

Sir_Death
Beiträge: 2447
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death » Mi 29. Jan 2020, 17:45

was hat der UNO für einen USB-Chip? - Dann würde ich mir einen Nano mit gleichem Chip besorgen.

Christian Knüll
Beiträge: 31
Registriert: So 2. Nov 2014, 19:45
Wohnort: Höpfingen
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Christian Knüll » Mi 29. Jan 2020, 19:15

Der CH340 schafft locker 1Mbaud - an dem sollte es nicht liegen.

Sir_Death
Beiträge: 2447
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death » Mi 29. Jan 2020, 23:04

Wenn es kein Fake ist ;)

Ich denke nur, dass es - wenn es mit dem UNO geht und mit dem NANO nicht - an der Platine liegen muss, nicht am Rechner, nicht an der SW am Rechner, nicht an der SW für den Arduino.
Darum meine Frage nach einem möglichen Unterschied zwischen den Platinen.

ch_ris
Beiträge: 304
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris » Do 30. Jan 2020, 09:18

glaub der uno hat nen ftdi.
Aber der ch340 kanns ja, und zwar genau dieser, hat er ja schon bewiesen.
Ich denke eher in richtung win10 bzw. treiber.
und da bin ich grad hilflos.
Wo kann ich bei dem win 10 die latency einstellen? :evil:
2020-01-30 08_17_32-Geräte-Manager.png

Sir_Death
Beiträge: 2447
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death » Do 30. Jan 2020, 10:18

hmmm...
dafür scheint der CH340 nicht ganz so toll geeignet zu sein. Er kann zwar 1 Mbaud, wenn die Daten in einem Strom kommen, aber bis sie ankommen...
https://forum.hobbycomponents.com/viewt ... 1782#p6387
https://www.alfaowner.com/threads/vag-c ... ue.523161/

latency kannst du einstellen, wenn es der Treiber unterstützt - FTDI kann das...
https://www.campbellsci.com/blog/usb-rs ... ble-issues

ch_ris
Beiträge: 304
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris » Do 30. Jan 2020, 10:38

mit der Lupe nochmal geguckt: ist kein ftdi auf dem Uno, sondern Atmega8U2 (...programmed as a USB-to-serial converter.)
Mag sein das der ch340 nicht so toll ist, aber es ging ja vorher mit win7, für mich bleibt der Arsch in der Geschichte das f....g win10.
Das ist jetzt kein Lösungsansatz, aber die Schuldfrage muss geklärt sein :lol: :cry:

Sir_Death
Beiträge: 2447
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death » Do 30. Jan 2020, 11:40

OK, wenn dir jetzt leichter ist ;)

Antworten