Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Sven, Heaterman, TDI, Finger

Re: Der AVR-/ARDUINO-Faden

Beitragvon Fritzler » Fr 31. Aug 2018, 10:35

Mit welchem Dachpappenbrenner hast du DIE Lötstellen denn angelegt?
Aber die sollten ja trotzdem nicht dran Schuld sein wenn ein aus dem Sockel gehobenes Beinchen immernoch was ausgibt.

Also PB1 gibt wirklich dasselbe wie MISO aus?
Das haste auf nem 2 Kanal Oszi gesehen?

Lad doch mal den Code als zip hoch, dann kann ich as heute Abend auf nem m328 testen.
Benutzeravatar
Fritzler
 
Beiträge: 5827
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Der AVR-/ARDUINO-Faden

Beitragvon Hightech » Fr 31. Aug 2018, 16:20

Es scheint so das der Linker/Compiler einen Furz quer stecken hatte.
Nachdem ich ein paar mal neu compiliert habe und verschiedene M88/M168 compiliert habe, geht es jetzt.(Anscheinend)

Was da unter der Haube alles schief gehen kann.
Benutzeravatar
Hightech
 
Beiträge: 3722
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitragvon Hightech » Fr 31. Aug 2018, 16:21

Fritzler hat geschrieben:Mit welchem Dachpappenbrenner hast du DIE Lötstellen denn angelegt?

Mit dem selben mit dem ich die SMD uln2003 aufbrate, wieso?
Benutzeravatar
Hightech
 
Beiträge: 3722
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitragvon Fritzler » Fr 31. Aug 2018, 17:26

Zumindest aus dem fotografierten Blickwinkel sehen die Lötstellen ziemlich Mies aus :?

Es ist egal, was der Compiler macht, aus PB1 KANN KEIN SPI KOMMEN!!!
Das is ja das total Merkwürdige.
Benutzeravatar
Fritzler
 
Beiträge: 5827
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Bootloader nicht mehr gefunden

Beitragvon Zabex » So 16. Sep 2018, 09:02

Bin am verzweifeln:
Habe Update der Entwicklungsumgebung von 1.8.5 auf 1.8.7 gemacht und seit dem kann ich keine Software mehr flashen.
Habe es mit mehreren Nano-Klonen versucht. Mit Einstellung für alten und neuen Bootloader. Jedesmal meldet der Avrdude out of sync.
Physikalisch ist alles in Ordnung: der serielle Monitor in der IDE zeigt bei bereits programmierten Nanos brav die von mir programmierten Meldungen (auch mit 115200 Baud).
Deinstallieren von 1.8.7 und installieren von 1.8.5 half nicht.
Was ich vor ein paar Tagen gemacht habe: Unterstützung für die Sparkfun (Attiny85) Boards installiert und selbige geflashed. Könnte da ein Zusamenhang sein?

Heute Abend will ich mal einen Logicanalyser an die RX/TX Pins des Nanos klemmen um zu sehen, was da rüber geht.

Weiß jemand, was ich dort sinnvollerweise sehen müsste?
Benutzeravatar
Zabex
 
Beiträge: 402
Registriert: Di 2. Jul 2013, 08:45
Wohnort: Aldenhoven

Re: Der AVR-/ARDUINO-Faden

Beitragvon Sterne » So 16. Sep 2018, 20:22

Hört sich für mich ein wenig nach diesem Problem an https://www.heise.de/make/artikel/Arduino-Nano-mit-neuem-Bootloader-4011641.html
Benutzeravatar
Sterne
 
Beiträge: 756
Registriert: Fr 28. Jun 2013, 10:30
Wohnort: Frickelkommando Nordwest

Bootloader nicht mehr gefunden

Beitragvon Zabex » So 16. Sep 2018, 20:33

Problem gelöst: Auf beiden Boards scheint der Bootloader platt zu sein. Ein drittes Board lässt sich problemlos flashen.
Falls jemand die IDE unter Debian 18.4 (bionic-beaver) laufen lassen will und auf Probleme mit dem COMM-Treiber stößt:
Mir hat diese Seite geholfen.

Zur Info
Gemessen auf dem Nano: Es werden 2 Bytes empfangen: 0x30 0x20
Bei old bootloader kommen die Daten mit 57600 Bit/s, beim neuen mit 115200 Bit/s

Edit: beim nagelneuen Board war nicht der Bootloader platt, sondern ein AtMega168 statt 328 bestückt. Das konnte ich aber nur unter dem Mikroskop erkennen...
Benutzeravatar
Zabex
 
Beiträge: 402
Registriert: Di 2. Jul 2013, 08:45
Wohnort: Aldenhoven

Re: Der AVR-/ARDUINO-Faden

Beitragvon Mirqua » Sa 20. Okt 2018, 11:40

Hallo,
folgendes Problem: ich habe ein Arduino Programm welches über die Serielle Schnittstelle
Befehle sendet. Da ich leider mit Arduino überhaupt nix am Hut habe, weiß jemand was hier
bei dem Programmcode gesendet wird?
> Const Progmem Uint16_t St [ ] = { 0x190 , 0x00 , 0xa3 }; < Was ich bis jetzt weis, es ist 9 Bit Protokoll.
Ich hab mit BASCOM jetzt schon so einiges duch aber tut nix.

MfG
Andreas
Mirqua
 
Beiträge: 274
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitragvon xoexlepox » Sa 20. Okt 2018, 13:00

weiß jemand was hier bei dem Programmcode gesendet wird?
> Const Progmem Uint16_t St [ ] = { 0x190 , 0x00 , 0xa3 }; <

Diese Zeile sendet nix. Die Zeile bewirkt nur, daß drei 16bit-Variablen im RAM reserviert werden, die beim Programmstart mit den angegebenen Werten gefüllt sind.

Edith meint: Korrekt abgeschrieben? M.E. könnte das Leerzeichen zwischen "St" und den eckigen Klammern zu einer Fehlermeldung des Compilers führen.
Benutzeravatar
xoexlepox
 
Beiträge: 4348
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitragvon Mirqua » Sa 20. Okt 2018, 14:11

Ja danke,
hatte tatsächlich ein Leerzeichen eingefügt, (wegen der Lesbarkeit).


Const Progmem Uint16_t St_minus_10[] = { 0x186 , 0x21 , 0x06 , 0xf9 };
sendDatagram(ST_Minus_10);

Hier ein vergleichbarer Schnipsel der zusammen gehört?
Also Variablen im Ram speichern und dann aber als was gesendet ?
Mirqua
 
Beiträge: 274
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitragvon xoexlepox » Sa 20. Okt 2018, 14:37

Also Variablen im Ram speichern und dann aber als was gesendet ?

Um das zu beantworten, müsstest du herausfinden, was die Funktion "sendDatagram()" mit den übergebenen Daten macht. Nach meiner Kenntnis ist diese Funktion nicht Bestandteil der Standard-Bibliothek, also müsste sie in dem Programm stehen. Der Code der Funktion müsste mit der Zeile
Code: Alles auswählen
void sendDatagram( Uint16_t * data ) {
(oder so ähnlich) beginnen. Der Code der Funktion beginnt nach dem "{" in der angegebenen Zeile, und endet mit der entsprechenden schließenden Klammer.

Ich sehe gerade: Das "Progmem" in der Zeile mit den Hexziffern bewirkt wohl, daß die Daten nicht im RAM, sondern im Programmspeicher (Flash) abgelegt sind, was jedoch an der Funktionalität wohl nichts ändert.
Benutzeravatar
xoexlepox
 
Beiträge: 4348
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitragvon Mirqua » Sa 20. Okt 2018, 17:12

Danke für deine Ausführung.
Ich werde erst mal das komplette Programm ausdrucken und suchen.
Arduino ist halt leider nicht meine Welt..

MfG
Andreas
Mirqua
 
Beiträge: 274
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitragvon NilsH » Sa 20. Okt 2018, 18:02

xoexlepox hat geschrieben:Ich sehe gerade: Das "Progmem" in der Zeile mit den Hexziffern bewirkt wohl, daß die Daten nicht im RAM, sondern im Programmspeicher (Flash) abgelegt sind, was jedoch an der Funktionalität wohl nichts ändert.

Das ändert sehr wohl etwas. Auf den Programmspeicher kann man beim AVR nicht wie auf den SRAM zugreifen.
Man muss die Daten vorher manuell in den SRAM holen. In Assembler macht man das mit der Instruktion LPM.
Wie es bei Arduino aussieht, kann ich leider nicht sagen.

Fraglich ist, ob sendDatagram() eine Adresse im SRAM als Parameter erwartet,
oder eine Adresse im Programmspeicher und dann selber die Daten von dort holt.

Nils
Benutzeravatar
NilsH
 
Beiträge: 54
Registriert: Mo 12. Aug 2013, 22:50
Wohnort: Berlin

Re: Der AVR-/ARDUINO-Faden

Beitragvon Mirqua » Sa 20. Okt 2018, 18:36

>void sendDatagram(< habe ich nirgends im Programm gefunden.
Könnte das noch woanders vermerkt sein?
Mirqua
 
Beiträge: 274
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitragvon xoexlepox » Sa 20. Okt 2018, 19:58

Auf den Programmspeicher kann man beim AVR nicht wie auf den SRAM zugreifen.

Danke für die hilfreiche Info! Ich mache relativ wenig mit dem AVR, bin meist mit PIC-Assembler unterwegs, und nutze C fast nur auf dem PC. Von daher war die Zeile der Funktionsdefinition auch "reine Schätzung" ;)

>void sendDatagram(< habe ich nirgends im Programm gefunden. Könnte das noch woanders vermerkt sein?

Ja, durchaus... Wie schon oben vermerkt, könnte das "void" auch "int" oder sonstwas sein. Suche einfach nach "sendDatagram(". Falls es wirklich nicht enthalten ist, schau mal, ob das ggf. in einer eingebundenen Headerdatei steckt. Die externen Header werden meist mit einer Zeile im Format "#include <dateiname>" eingebunden, wobei die spitzen Klammern auch Anführungszeichen sein könnten.
Benutzeravatar
xoexlepox
 
Beiträge: 4348
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitragvon IPv6 » Sa 20. Okt 2018, 19:59

Jetzt zeig halt mal her um was für ein Programm es sich handelt! ;)

Mit kleinen Codeausschnitten wird man dir hier kaum weiterhelfen können.
IPv6
 
Beiträge: 499
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitragvon Mirqua » Mi 24. Okt 2018, 10:36

Das Arduino Programm habe ich nur als Schnipsel.

Das hier soll auch die Steuercodes erzeugen.
Mit meiner bescheidenen Technik kekomme ich zwar Dezimal das Selbe,aber bei mir
reagier der Empfänger nicht. Es könnte also ein Problem mit dem Timing sein.

seatalk_in_c.txt
(2.46 KiB) 28-mal heruntergeladen


Wichtig ist die serielle Übertragung des Steuerbefehls

Danke, MfG
Andreas
Mirqua
 
Beiträge: 274
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitragvon xoexlepox » Mi 24. Okt 2018, 11:28

Das hier soll auch die Steuercodes erzeugen.

Das scheint mit eher ein reines Empfangsprogramm zu sein.

Der Code ist ja grausig! In dem Programm wird sich auf einige Dinge verlassen, auf die sich ein guter Programmierer nicht verlassen sollte: Z.B. daß alle Variablen beim Programmstart auf Null gesetzt sind, was je nach verwendetem Compiler und Modus (->Debug-Code) nicht unbedingt gewährleistet ist. Aber zumindest ist es halbwegs brauchbar dokumentiert.

Bevor ich mich da dran mache, das verwendete Protokoll herauszuklamüsern, wäre es ganz nett zu wissen, wie herum du das einsetzen möchtest: Willst du mit diesem (PC-) Programm etwas empfangen, was der Arduino senden, oder wie soll das laufen?

Was passiert, wenn du die Aussendung des Arduino mit einem "Terminalprogramm" auf dem PC empfängst (4800Bd, Parity enable, 8bit)? Kommt da überhaupt etwas an (ggf. auch irgendwelche Hieroglyphen)?

Edith meint: Nach kurzer Recherche habe ich das hier gefunden. Dort ist das verwendete Protokoll so grob beschrieben. Vielleicht reicht das schon, um die "Kommunikationsstörung" zu finden?
Benutzeravatar
xoexlepox
 
Beiträge: 4348
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitragvon Mirqua » Mi 24. Okt 2018, 11:54

Die Sache ist die:
Der Rechenknecht soll weg.
Ich möchte mit einem Atmega die Einheit ansteuern. Leider kann ich nur Bascom.
Ich würde nur gern wissen wie das Protokoll aussieht.
Sende ich Programmdaten vom Rechner und das Gleiche mit einem Atmega an einen Anderen
sind Dezimal beide Daten gleich. Aber irgendetwas muß ja anders sein.
Mit meinem Timing muß was nicht stimmen.
4800 Baud ,1 Stopbit und 8 Bits haut bei mir der Empfang hin.
Mirqua
 
Beiträge: 274
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitragvon xoexlepox » Mi 24. Okt 2018, 18:57

Ich würde nur gern wissen wie das Protokoll aussieht.

Das findest du auf den von mir verlinkten Seiten (einfach mal alle weiteren Links abklappen). Die von dir angegebene Sequenz "0x190 , 0x00 , 0xa3" bedeutet damit "0x100 + 0x90" -> Command 'Device ID' (0x100 -> Command, 0x90 -> Command code)", "0x00" -> kein weiteres Datenbyte als die drei Pflichtbytes, "0xa3" -> Daten (steht für "send by NMEA"). Und die Sequenz "0x186 , 0x21 , 0x06 , 0xf9" bedeutet: "0x186" -> "Command 'Key stroke'", "0x21" -> ein weiteres Datenbyte, und die beiden Datenbytes "0x06" und "0xf9" stehen für "-10".

Mit meinem Timing muß was nicht stimmen.
4800 Baud ,1 Stopbit und 8 Bits haut bei mir der Empfang hin.

Ich vermute eher, das könnte am fehlenden Paritybit liegen, denn das gesetzte neunte Bit signalisiert ja in dem Protokoll ein "Commandbyte". Wie man es jedoch hinbekommt, den Arduino in Bascom zu überreden, neun Bits zu senden, das kann ich dir nicht sagen, denn ich habe keine Ahnung von Bascom :( Notfalls musst du "zu Fuß" auf den USART-Registern des Atmel-Chips "herumtrommeln". Welche Bits in welchen Registern dafür notwendig sind, findest du im Datenblatt des Chips.
Benutzeravatar
xoexlepox
 
Beiträge: 4348
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitragvon Mirqua » Mi 24. Okt 2018, 19:59

Puh,
zuerst mal danke das du dir so viel Mühe gegeben hast. Das ist Bitschubsen für Fortgeschrittene.

Ich lese mich nochmal in die Thematik ein, könnte aber ein schnelles Ende nehmen.

MfG
Andreas
Mirqua
 
Beiträge: 274
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitragvon Weisskeinen » Do 25. Okt 2018, 14:02

xoexlepox hat geschrieben:Ich vermute eher, das könnte am fehlenden Paritybit liegen, denn das gesetzte neunte Bit signalisiert ja in dem Protokoll ein "Commandbyte". Wie man es jedoch hinbekommt, den Arduino in Bascom zu überreden, neun Bits zu senden, das kann ich dir nicht sagen

Das gibt man bei der Konfiguration mit an, ob man keine, gerade oder ungerade Parity haben möchte.

Code: Alles auswählen
Serout S , 0 , D , 1 , Mybaud , 0 , 8 , 1

'                                      ^ 1 stop bit

'                                  ^---- 8 data bits

'                                ^------ even parity (0=N, 1 = E, 2=O)

'                        ^-------------- baud rate

'                  ^-------------------- pin number

'               ^----------------------- port so PORTA.0 and PORTA.1 are used

'           ^--------------------------- for strings pass 0

'      ^-------------------------------- variable
Benutzeravatar
Weisskeinen
 
Beiträge: 2399
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitragvon xoexlepox » Do 25. Okt 2018, 20:31

Das gibt man bei der Konfiguration mit an, ob man keine, gerade oder ungerade Parity haben möchte.

"Serout" hört sich sehr nach "Senden eines einzelnen Bytes/Strings" an, d.h. man könnte die Konfiguration "pro Byte" ändern? Das wäre zwar etwas "Bitgeschubse", für jedes Byte auszurechnen, ob nun das Parity-Bit "Odd" oder "Even" sein muss, um es auf "0" oder "1" zu setzen, aber sicher auch ein möglicher Weg.
Benutzeravatar
xoexlepox
 
Beiträge: 4348
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitragvon Weisskeinen » Mo 29. Okt 2018, 13:01

Ich kenne kein Bascom, das sah aber nach Konfiguration der seriellen Schnittstelle aus. Die Atmel-Controller können das nach Konfiguration komplett selbst in Hardware machen, zum Senden schreibt man nur das entsprechende Byte ins Register und der AVR kümmert sich um den Rest. Beim Empfangen ist das ähnlich, dass man das empfangene Byte einfach aus dem entsprechenden Register abholt.
Die Parity-Berechnung geschieht auch hardwaremäßig, aber man muss angeben, ob das Bit für Odd-Parity (ungerade Bitanzahl) oder Even-Parity (gerade Bitanzahl) berechnet sein soll.
Natürlich kannst du die Konfiguration für jedes Byte ändern, nur sinnvoll ist das nicht, der Empfänger muss ja mit den gleichen Einstellungen laufen. Also ein Mal festlegen und das war's dann.

Edit: Ich sehe gerade, dass das Parity-Bit als Command-Bit missbraucht wird. Hmmm, ja, dann muss man wohl die Schnittstelle ständig umkonfigurieren, je nach dem, was man braucht. Und selbst die Anzahl der Bits zählen, die im eigentlichen Commandbyte drin sind.
Benutzeravatar
Weisskeinen
 
Beiträge: 2399
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitragvon xoexlepox » Mo 29. Okt 2018, 15:15

Ich sehe gerade, dass das Parity-Bit als Command-Bit missbraucht wird.

Das ist ja das Gemeine an diesem Protokoll ;) Aber wenn ich das Datenblatt vom Atmel richtig interpretiert habe, kann man (durch direktes "Getrommel" auf den Registern) auch 9Bit senden, und damit das Parity-Bit selber bestimmen. Eine andere Variante wäre, die anstehenden Bits in einem Timer-Interrupt selber einzeln "herauszuschießen". Nur ob man in Bascom auch Interrupt-Funktionen schreiben kann (und ob es dafür schnell genug ist), ist mir nicht bekannt.
Benutzeravatar
xoexlepox
 
Beiträge: 4348
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

VorherigeNächste

Zurück zu Allgemeine Diskussion

Wer ist online?

Mitglieder in diesem Forum: basti1, Google [Bot] und 36 Gäste

span