Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

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
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

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
Zabex
Beiträge: 632
Registriert: Di 2. Jul 2013, 08:45
Wohnort: Aldenhoven
Kontaktdaten:

Bootloader nicht mehr gefunden

Beitrag von Zabex »

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
Sterne
Beiträge: 1044
Registriert: Fr 28. Jun 2013, 10:30
Wohnort: Frickelkommando Nordwest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sterne »

Hört sich für mich ein wenig nach diesem Problem an https://www.heise.de/make/artikel/Ardui ... 11641.html
Benutzeravatar
Zabex
Beiträge: 632
Registriert: Di 2. Jul 2013, 08:45
Wohnort: Aldenhoven
Kontaktdaten:

Bootloader nicht mehr gefunden

Beitrag von Zabex »

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...
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

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.
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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 ?
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

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.
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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
Benutzeravatar
NilsH
Beiträge: 130
Registriert: Mo 12. Aug 2013, 22:50
Wohnort: Berlin
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von NilsH »

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
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

>void sendDatagram(< habe ich nirgends im Programm gefunden.
Könnte das noch woanders vermerkt sein?
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

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.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

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.
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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) 91-mal heruntergeladen
Wichtig ist die serielle Übertragung des Steuerbefehls

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

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

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?
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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.
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

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.
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

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
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

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
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

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
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

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
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Hier https://www.mikrocontroller.net/topic/76894 steht, wie man die Parität effizient selbst bestimmen kann, um damit den Übertragungsmodus des AVR anzupassen. Das steht wohl als Assembler-Makro in der <parity.h>. Bei der Suche im Datenblatt (http://ww1.microchip.com/downloads/en/d ... asheet.pdf), wie man die Parität durch Register im ATmega328 einstellt (Kapitel 24.12.4: USART Control and Status Register 0 C), habe ich in Kapitel 24.7.2 gesehen, dass man auch direkt 9-Bit Daten senden und empfangen kann. Da braucht man dann diesen Heckmeck nicht zu treiben.
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

Hallo, Guten Morgen.
Zuerst nochmal herzlichen Dank das ihr euch so hineinkniet.
Seid letzter Woche bin ich erst mal "Stillgestell" und kann nur mitlesen;
Bei einer einfache Zahnbehandlung hab ich allergisch reagiert...

Da ich keinesfalls auch nur annähernd so viel Ahnung wie ihr habt und ich
auch nix testen konnte habe ich erst mal Arduino heruntergeladen und mich
eingelesen. Ging halt immer nur für kurze Zeit.
Nachdem ich alle zusätzliche Bibliotheken erhalten habe klappt zumindest das
Kompilieren ohne Fehlermeldung.
Es ist für mich wahrscheinlich einfacher in Arduino meine Befehle einzubinden
als in Bascom das komplizierte serielle Protokoll zu meistern.
Ich müßte morgen mein A-Board bekommen, dann versuche ich mal die Übertragung.

Melde mich dann nochmal.
MfG
Andreas
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

N'abend, :)

ich möchte auf einem 8digit 7segmentanzeigedings mit max7219 2 Variablen Ausgeben. Die kommen von Potis via analog read und stellen die PWM von LEDs ein. Das läuft auch alles für sich schon wunderbar, also 2 Potis steuern 2 PWMen und das Display zeigt was an.
Ich würde dann map() verwenden um den eingelesenen Wert auf Prozente umzurechnen, aber so weit komme ich nicht, weil ich ums verrecken nicht rausfinde, wie ich es schaffe eine 3stellige Integer in den linken Viererblock und eine andere 3stellige Integer in den rechten Viererblock zu schreiben. Mit statischen Werten ist das kein Thema, aber wie ich da jetzt ne Variable reinschieben soll will mir nicht in den Kopf.
Ich hab mir auch schon Zabex' Thermometer als Vorbild hergenommen und verstehe einfach nicht so recht was da genau passiert. Ich hab mal versucht, das so zurechtzuschnippeln, dass der Teil, den ich verstehe Sinn ergibt, aber der Teil um "void writeDualValTo7Segment()" ist mir ein Rätsel und ich weiß nicht so recht was genau was macht. Bei negativen Werten wird noch ein Minus geschrieben und das Cycelt irgendwie lustig rum, aber die angezeigten Werte sind jedenfalls völlig unplausibel, da ist noch mehr was nicht läuft wie erwünscht. Da ist auf jeden Fall noch ne Menge unbenötigter Code drin, aber ohne zu verstehen was genau im Detail abläuft ist das wie Minesweeper ohne Kenntnis der Regeln. :?

Wenn mir da jmd auf die Sprünge helfen könnte, wäre ich sehr dankbar :)
So sieht der Sketch grade aus:

Code: Alles auswählen

//PWM mit 2 Potis und Display

#include "max7219.h"
/*
 Led controller MAX7219:
 pin 7 is connected to the DataIn 
 pin 6 is connected to the CLK 
 pin 5 is connected to the CS 
 */
MAX7219 led=MAX7219(4,2,3);

unsigned int index;
unsigned long time;
int ledPin1 = 9;      // LED connected to digital pin 9
int ledPin2 = 10;      // LED connected to digital pin 8
int analogPin1 = 0;   // potentiometer connected to analog pin 0
int analogPin2 = 1;   // potentiometer connected to analog pin 1
int val1 = 0;         // variable to store the read value 0
int val2 = 0;         // variable to store the read value 1

void setup()
{
  pinMode(ledPin1, OUTPUT);   // sets the pin as output
  pinMode(ledPin2, OUTPUT); 
   /*
   The led controller MAX7219 is in power-saving mode on startup,
   we have to do a wakeup call
   */  
  led.shutdown(false);
  /* Set the brightness to a low value */
  led.setIntensity(4);
 
 }
 
//-----------------------------------------------------------------------------
void writeDualValTo7Segment( int n1,  int n2, bool both) {
//-----------------------------------------------------------------------------
  //Suppresses leading zeros. Fills all 8 digits.
char neg1=' ';
char neg2=' ';
int n;
  if (n1<0) neg1 = '-';
  if (n2<0) neg2 = '-';
  n1 = abs(n1);
  n2 = abs(n2);

  if (!both) led.clearDisplay();
  n=n1;
  led.setChar(0, n%10, false);  n/=10;
  led.setChar(1, n%10, true);  n/=10;
  if (0==n){
    led.setChar(2, neg1, false);  
    neg1 = ' ';
  }else{ 
    led.setChar(2, n%10, false);  n/=10;
  }  
  led.setChar(3, neg1, false);  

  if (!both) return;
  
  n=n2;
  led.setChar(4, n%10, false);  n/=10;
  led.setChar(5, n%10, true);  n/=10;
  if (0==n){
    led.setChar(6, neg2, false);  
    neg2 = ' ';
  }else{ 
    led.setChar(6, n%10, false);  n/=10;
  }  
  led.setChar(7, neg2, false);  
}
//-----------------------------------------------------------------------------
//-----------------------------------------------------------------------------




//-----------------------------------------------------------------------------
void loop()
//-----------------------------------------------------------------------------
{
  val1 = analogRead(analogPin1);   // read the input pin1
  analogWrite(ledPin1, val1 / 4);  // analogRead values go from 0 to 1023, analogWrite values from 0 to 255

  val2 = analogRead(analogPin2);   // read the input pin2
  analogWrite(ledPin2, val2 / 4);  // analogRead values go from 0 to 1023, analogWrite values from 0 to 255


  static byte tic=0;
  int temperature;
  unsigned long now;
  led.shutdown(false);
  writeDualValTo7Segment(val1, val2, (tic++ < 3));
  tic++;
  if (tic >8) tic=0;    
  delay(800);
  
    }


Grüße
Moritz
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Na ja, Kerngedanke ist, dass man von hinten anfängt, die Zahl zu schreiben, also bei den Einern. Dazu teilt man die Zahl durch 10 und schreibt den Rest in das Display. Dazu wird die Modulofunktion verwendet n%10. Damit sind die Einer fertig und wir wenden uns den Zehnern zu. Dazu teilen wir den Wert durch 10 und behalten das Ergebnis (der Rest wird bei der Ganzzahldivision verworfen). Das passiert mit n/=10;, ausgeschrieben n=n/10. Jetzt macht man wieder die Modulooperation, wobei die alten Zehner jetzt die Einer sind und dem wird Rechnung getragen, dass der Rest der Operation an die zweite Stelle auf dem Display geschrieben wird. Dann wird wieder durch 10 geteilt. Sollte nichts mehr übrig sein, wird noch das Vorzeichen geschrieben und das Vorzeichen auf das Leerzeichen gesetzt. Das ist für die nächste Zeile außerhalb der if-Verzweigung wichtig, weil dort an die vierte Stelle auf jeden Fall das Vorzeichen geschrieben wird und wir keine doppelten Minuszeichen wollen. War doch noch was übrig bei der Division (Hunderter), wird das an die dritte Stelle geschrieben und das Vorzeichen ganz normal. Bei den Hundertern könnte man noch optimieren und die letzte Division n/=10 weg lassen, was der Compiler aber wahrscheinlich sowieso tut.
War das einigermaßen verständlich?
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

Weisskeinen hat geschrieben:War das einigermaßen verständlich?
Ja, Danke! :)
Das Cycling hab ich nicht gebraucht, genausowenig negative Werte, das sieht jetzt so aus:

Code: Alles auswählen

//Beispiel PWM mit 2 Potis und Display

#include "max7219.h"
//Falls Bibliotheken fehlen: aus Internet Herunterladen und mit diesem Menüpunkt installieren: Sketch/Bibliothek importieren/Bibliothek hinzufügen...
/*
 Led controller MAX7219:
 pin 7 is connected to the DataIn 
 pin 6 is connected to the CLK 
 pin 5 is connected to the CS 
 */
MAX7219 led=MAX7219(4,2,3);

unsigned int index;
unsigned long time;
int ledPin1 = 9;      // LED connected to digital pin 9
int ledPin2 = 10;      // LED connected to digital pin 8
int analogPin1 = 0;   // potentiometer connected to analog pin 0
int analogPin2 = 1;   // potentiometer connected to analog pin 1
int val1 = 0;         // variable to store the read value 0
int val2 = 0;         // variable to store the read value 1

void setup()
{
  pinMode(ledPin1, OUTPUT);   // sets the pin as output
  pinMode(ledPin2, OUTPUT); 
   /*
   The led controller MAX7219 is in power-saving mode on startup,
   we have to do a wakeup call
   */  
  led.shutdown(false);
  /* Set the brightness to a low value */
  led.setIntensity(2);
 
 }
 
//-----------------------------------------------------------------------------
void writeDualValTo7Segment( int n1,  int n2) 
//-----------------------------------------------------------------------------
 { 
  // Fills all 8 digits.

int n;
  n1 = abs(n1);
  n2 = abs(n2);

  n=n1;
  led.setChar(0, n%10, false);  n/=10;
  led.setChar(1, n%10, true);   n/=10;
  led.setChar(2, n%10, false);  n/=10; 
  led.setChar(3, n%10, false);  

  
  n=n2;
  led.setChar(4, n%10, false);  n/=10;
  led.setChar(5, n%10, true);   n/=10;
  led.setChar(6, n%10, false);  n/=10; 
  led.setChar(7, n%10, false);  
}
//-----------------------------------------------------------------------------




//-----------------------------------------------------------------------------
void loop()
//-----------------------------------------------------------------------------
{
  val1 = analogRead(analogPin1);   // read the input pin
  analogWrite(ledPin1, val1 / 4);  // analogRead values go from 0 to 1023, analogWrite values from 0 to 255

  val2 = analogRead(analogPin2);   // read the input pin
  analogWrite(ledPin2, val2 / 4);  // analogRead values go from 0 to 1023, analogWrite values from 0 to 255


  led.shutdown(false);
  writeDualValTo7Segment(val1, val2);
  
    }
  
Ich habe offensichtlich ein Problem mit meinen Variablen val1 und val2, die machen seit dem Einbau der Display-Subroutine merkwürdige Sachen und spinnen nurnoch rum, entsprechender Müll kommt auch auf den ledPins 1 und 2 via AnalogWrite raus. Muss ich wohl noch n bißchen knobeln, vllt stimmt auch was mit der Verkabelung nicht malsehen...

Nochmal danke, da hätte ich sonst noch Tage dran gesessen! :)

Edit: jep war die Verkabelung. mein Breadboard hat offenbar keine durchgehende Plus u. Minusschiene und die Spannungsteiler hngen demnach in der Luft herum. o_0
Zuletzt geändert von Später Gast am Mo 5. Nov 2018, 12:02, insgesamt 1-mal geändert.
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Code: Alles auswählen

int ledPin2 = 10;      // LED connected to digital pin 8
Stimmt das so?
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

Äh der Kommentar kommt noch aus dem Beispielcode, das is schon in ordnung. ;) :oops:
Thorhall
Beiträge: 291
Registriert: Mo 9. Jan 2017, 15:57

Re: Der AVR-/ARDUINO-Faden

Beitrag von Thorhall »

Moin Moin,

ich wollte mich mal mit den Atmel rumschlagen.
Ich habe ein Atmel AVR JTAGICEmkII und möchte nun mit einem Atmeg32 rumspielen.
Erstmal das Ding an meinen Linux Rechner gehängt und alles nötige installiert:
avr-binutils 2.31.1-1
avr-gcc 8.2.0-1
avr-gdb 8.2-2
avr-libc 2.0.0-3
avrdude 1:6.3-3

Keine Platine zusammengelötet, damit ich den atmega reinstecken kann, 5V Vcc drauf, ans JTAG angeschlossen und folgendes eingegeben:
avrdude -p m32 -P usb -c jtag2

avrdude meldet dann das:

Code: Alles auswählen

avrdude: Version 6.3, compiled on Aug  9 2017 at 12:31:56
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : jtag2
avrdude: usbdev_open(): Found AVRBLDR, serno: 00B0000008D8
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
...
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: usbdev_send(): wrote -6 out of 11 bytes, err = No such device or address
avrdude: jtagmkII_send(): failed to send command to serial port
avrdude: jtagmkII_getsync(): sign-on command: status -1
avrdude: jtagmkII_getsync(): timeout/error communicating with programmer (status -1)

avrdude done.  Thank you.
Was könnte ich grundsätzlich falschgemacht habe?
Jemand 'ne Idee?

Danke schonmal
Micha
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

UFF!
Also JTAG hab ich bei AVRs echt NIE genutzt (nur bei ARM bisher).
Aber ich versuch mal zu helfen:

Ist der Mega32 fabrikneu? Oder kanns sein, dass da die JTAG fuse aus ist?
Machts nen Unterschied in der Fehlermeldung wenn der jtagice garnicht am AVR hängt?
Der Klassiger ist es VTREF nich ans Target VCC anzuschließen, dann bekommt der Levelshifter im jtagice nichts zu levelshiften.
Nen monströsen C an nreset gehangen und der debugger kann daher den reset nicht shcnell genug auf low ziehen?
TDI des debuggers muss wirklich an den TDI des AVR, das ist kein UART :mrgreen:

Villeicht muss man bei JTAG auch erstmal die bitclock runterschrauben wenn der AVR fabrikneu nur mit 1MHz läuft
https://www.nongnu.org/avrdude/user-man ... ude_4.html
-> -B bitclock und/oder -c jtag2slow
Arne
Beiträge: 221
Registriert: So 11. Aug 2013, 19:12

Re: Der AVR-/ARDUINO-Faden

Beitrag von Arne »

Könnte ein Berechtigungsproblem sein. Hast du es mal als root probiert?
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

433 MHz Funkmodule

Beitrag von IPv6 »

Ich möchte ein wenig mit einfacher und billiger Funktechnik rumspielen und mir zu diesem Zweck eine Hand voll Funkmodule mit 433 MHz besorgen.

Scheinbar gibt es davon einige verschiedene Versionen, mit Quarz auf Sender bzw. Empfänger oder Module mit Spulen drauf, manche wollen 3-24 V sehen, andere nur 3-3,6 V. Die Reichweite ist sowieso immer anders angegeben.

Frage 1:
Wenn ich beim schnellen Ali "433 MHz Arduino" eingebe, sind dann die ganzen angezeigten Platinchen weitestgehend untereinander kompatibel?


Frage 2:
Mit welchen billigen Funkmodulen habt ihr Erfahrung gemacht, sprich welche taugen halbwegs was und können bedenkenlos gekauft werden?
Benutzeravatar
Bastelbruder
Beiträge: 11481
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

Laß die Finger von allem was bei Google mit der Suche nach >433 Sender< gefunden wird oder so ähnlich aussieht.

Bei Maxens gibts ernsthafte Funktechnik für relativ wenig Geld
Bloß drei Buchstaben RFM in die Suchmaske eingeben und freuen.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Laß die Finger von allem was bei Google mit der Suche nach >433 Sender< gefunden wird oder so ähnlich aussieht.
Das ist mri ein klein wenig zu pauschal. Das kann schlichtweg nicht alles Schrott sein, dazu gibt es zu viele Leute, bei denen das Zeugs funktioniert.

Ein möglicher Anwendungszweck wäre, über 20 Meter hin und wieder ein paar Bytes zu übertragen, mehr nicht.

Die Module vom Pollin sehen in der Tat ganz interessant aus. Was genau macht diese Module zur ernsthaften Funktechnik?
Benutzeravatar
Bastelbruder
Beiträge: 11481
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

Das ist ganz einfach: Ich schalte meinen drahtlosen Aldi-Kopfhörer ein und in 50..100 m Umkreis geht kein drahtloses Außenthermometer mehr. Zumindest nicht über eine Entfernung >5 m.
Das 1921 vom UKW-Erfinder erfundene Pendelaudion ist absolute Spartechnik, das ist ein Empfänger der alle hundert Kanäle des 70 cm-Bands gleichzeitig empfängt. Der lauteste Sender gewinnt.
Die dazu passenen Sender mit der kleinen Blechbüchse mit Aufdruck 433 sind zwar halbwegs frequenzstabil (so gut daß sie auf jeden Fall im vorgesehenen Frequenzbereich bleiben), aber der Wirkungsgrad ist schlechter als der der ernsthaften Funktechnik.

Bei der Billigware wird, wenn überhaupt, die von der Stromversorgung aufgenommene Energie angegeben, die ernsthafte Funktechnik hat belastbare Datenblätter mit Toleranzangaben kleiner 3 db. Und die ernsthaften Module beinhalten sogar automatische Antennen-Abstimmgeräte die dafür sorgen daß wirklich die bestmögliche Abstrahlung stattfindet.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Vielen Dank für deine Erklärungen!

Damit sind die Ali-Module wohl eher breitbandige Störsender und Allesempfänger?

Die Pollindinger sind ja preislich auch noch überschaubar.

Das hier sieht eher weniger nach der von dir beschriebenen Emfpängerart aus:
https://www.aliexpress.com/item/Transmi ... 16faaba7d1

Kannst du dazu irgendwas sagen?

...jaja, der Preis lockt halt, ich gebe es ja zu...
Benutzeravatar
Bastelbruder
Beiträge: 11481
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

Es wird schon einen Grund haben daß da kein Datenblatt veröffentlicht wird.
Modulation ASK = Ein-Aus = Arme-Leute-Modulation.

Die Dinger von Pollin (HopeRF) müssen natürlich programmiert werden und der Betreiber sollte tunlichst die vorgegebenen Eckwerte einhalten. Aber ein Byte wegschicken und empfangen ist doch etwas anderes als Morsen.
Die alte Technik läßt sich zwar ohne Professor in Betrieb nehmen, Batterie dran und auf der Empfangsseite den Morsesignalen lauschen oder watchen astonished the blinkenlight.
caprivi
Beiträge: 585
Registriert: Mi 9. Mär 2016, 14:44
Wohnort: Am ehemaligen Schorbaer Berg.

Re: 433 MHz Funkmodule

Beitrag von caprivi »

IPv6 hat geschrieben:Ich möchte ein wenig mit einfacher und billiger Funktechnik rumspielen und mir zu diesem Zweck eine Hand voll Funkmodule mit 433 MHz besorgen.
...
Frage 2:
Mit welchen billigen Funkmodulen habt ihr Erfahrung gemacht, sprich welche taugen halbwegs was und können bedenkenlos gekauft werden?
Kuck Dir mal mysensors.org an, die haben eine Funkbibliothek und verwenden u.a. RFM69. Der Vorteil ist, das ganze Protokoll und auch die nötigen Schalter (um die Sendeleistung deutschlandkonform zu machen) sind alle schon fertig ausgedacht.
bastelheini
Beiträge: 1663
Registriert: So 11. Aug 2013, 13:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von bastelheini »

Moin,

ich mich auch mal an der Arduino Sache probiert. Leider habe ich das Problem, dass ich die Baudrate nicht ändern kann, es wird immer 1200 verwendet.

Code: Alles auswählen

Serial.begin(19200);
oder andere Baudraten ändern nichts.

Verwendet wird ein ATmega32, folgende Boarddefinition https://www.instructables.com/id/Using- ... duino-IDE/.

Fuses sind korrekt eingestellt, delay(1) dauert auch ~1 ms. F_CPU sind auch die korrekten 16000000.

Die Ausgabe erfolge via z. B.

Code: Alles auswählen

Serial.println(F_CPU);
Woran kann das noch liegen?

Edit2: Wenn ich mir UBRRL und UBRRH ausgeben lasse komme ich auf dezimal 103 & 6. Die 6 aus dem high Register müssten eigentlich 0 sein. Woher kommt das?


Edit: intern macht er das:

Code: Alles auswählen

void HardwareSerial::begin(unsigned long baud, byte config)
{
  // Try u2x mode first
  uint16_t baud_setting = (F_CPU / 4 / baud - 1) / 2;
  *_ucsra = 1 << U2X0;

  // hardcoded exception for 57600 for compatibility with the bootloader
  // shipped with the Duemilanove and previous boards and the firmware
  // on the 8U2 on the Uno and Mega 2560. Also, The baud_setting cannot
  // be > 4095, so switch back to non-u2x mode if the baud rate is too
  // low.
  if (((F_CPU == 16000000UL) && (baud == 57600)) || (baud_setting >4095))
  {
    *_ucsra = 0;
    baud_setting = (F_CPU / 8 / baud - 1) / 2;
  }

  // assign the baud_setting, a.k.a. ubrr (USART Baud Rate Register)
  *_ubrrh = baud_setting >> 8;
  *_ubrrl = baud_setting;

  _written = false;

  //set the data bits, parity, and stop bits
#if defined(__AVR_ATmega8__)
  config |= 0x80; // select UCSRC register (shared with UBRRH)
#endif
  *_ucsrc = config;
  
  sbi(*_ucsrb, RXEN0);
  sbi(*_ucsrb, TXEN0);
  sbi(*_ucsrb, RXCIE0);
  cbi(*_ucsrb, UDRIE0);
}
Zuletzt geändert von bastelheini am So 6. Jan 2019, 01:35, insgesamt 2-mal geändert.
Anse
Beiträge: 2278
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Probiere das mal statt Serial_begin:

Code: Alles auswählen

UCSRB |= (1<<TXEN)|(1<<RXEN);                 // UART TX und RX einschalten
UCSRC = (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0); // Asynchron 8N1
UBRR=51; //
Ich setzt einfach mal voraus, dass die Arduino IDE alle Registerdefinitionen drauf hat.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Ist schon spät und mein Gehirn schläft halb und ein Experte auf dem Gebiet bin ich auch nicht wirklich...

In deinem "Intern macht er das" Codeausschnitt finden sich folgende Zeilen:
#if defined(__AVR_ATmega8__)
config |= 0x80; // select UCSRC register (shared with UBRRH)
#endif
Du verwendest ja einen ATmega32.

In der Instructable Anleitung zum ATmega32 zusammen mit der Arduino IDE findet sich folgender Hinweis:
For Serial library to work properly must be made following changes to the file HardwareSerial.cpp
In ...\arduino-1.5.8\hardware\arduino\avr\cores\arduino\HardwareSerial.cpp

will replace:

#if defined(__AVR_ATmega8__)
config |= 0x80; // select UCSRC register (shared with UBRRH)
#endif

with:

#if defined(__AVR_ATmega8__) || defined(__AVR_ATmega32__) || defined(__AVR_ATmega16__)
config |= 0x80; // select UCSRC register (shared with UBRRH)
#endif
Vielleicht hilft das weiter.

Viel Erfolg!
Benutzeravatar
Rial
Beiträge: 2356
Registriert: Mi 23. Jul 2014, 19:20
Wohnort: Region Hannover

Re: Der AVR-/ARDUINO-Faden

Beitrag von Rial »

Hat vielleicht jemand die Specs für die Betriebstemperatur
eines Arduino Nano ?
Habe schon gegoogelt,aber irgendwie nichts gefunden...

Desweiteren :
Ich würde einen Nano gerne wetterfest machen.
Soll draußen in ein Gehäuse an die Wand gespaxt werden.
Dieses Gehäuse ist IP mäßig sehr weit unten angesiedelt.
Der Nano muß also irgendwie eingegloddert/versenkt werden.

Aber womit ?
Gerne mit Links zu Shops
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Da könnten sich schon die Klone von den originalen Arduinos unterscheiden.

Was die Betriebstemperatur engeht würde ich mich an die Empfehlungen der Hersteller der verbauten Komponenten halten. Also konkret an die Angaben für einen ATmega328 und den verbauten USB-Seriell Umsetzer, wobei dieser für den direkten Betrieb nicht unbedingt notwendig ist.

Beim Controller kommt es auch wieder auf die verbaute Variante an. Laut Datenblatt ist der ATmega328P für automotiv Zwecke zugelassen und macht Betriebstemperaturen von -40 °C bis +125 °C mit. Ob diese Variante auf deinem Nano verbaut ist müsstest du mal durch genaues Hinsehen herausfinden.

Für Wetterfestigkeit könnte schon Regengeschützt in einem nach unten geöffneten Gehäuse ausreichen. So kann Feuchtigkeit wenigstens wieder raus.
Sonst könnte man das Gehäuse auch versuchen mit Silikon oder Heißkleber komplett dicht zu bekommen und ins Innere ein Päckchen Trockenmittel für alle Fälle mit rein packen.

Eingießen könnte schon mit Heißkleber oder Kerzenwachs brauchbare Ergebnisse erzielen. Kommt man halt nie wieder ran, was bei den Preisen für die Dinger aber nicht so tragisch ist. Nur neu programmieren wird ebenfalls erschwert, da würde ich dann die USB-Verbindungen nach außen legen.
Benutzeravatar
Rial
Beiträge: 2356
Registriert: Mi 23. Jul 2014, 19:20
Wohnort: Region Hannover

Re: Der AVR-/ARDUINO-Faden

Beitrag von Rial »

und macht Betriebstemperaturen von -40 °C bis +125 °C mit
Das ist schon mal eine Aussage,mit der ich in der Norddeutschen-Tiefebene leben kann :lol:

Regengeschützt verbaut werden soll der Nano.
Aber es geht mir um die Temperatur-Schwankungen/Luftfeuchtigkeit,
weil das Gehäuse nicht hermetisch dicht ist.
Deswegen eingloddern.
Kommt man halt nie wieder ran, was bei den Preisen für die Dinger aber nicht so tragisch ist
Richtig
Nur neu programmieren wird ebenfalls erschwert
Muß nur einmal geproggt werden und dann funktionieren
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Ich denke ein Arduino in einem regengeschützen Gehäuse, wo ein Luftaustausch stattfinden kann hält schon quasi ewig. Am Arduino ist es durch den Stromverbrauch immer wärmer als die Umgebung, da bildet sich eher kein Kondenswasser. Ich würde es daher zunächst einfach mal in einem regengeschützten Gehäuse versuchen und nur darauf achten, dass sich da keine Tierchen einnisten können.
Luftfeuchtigkeit macht dem Arduino prinzipiell nichts, solange er nicht nass wird. Und bei schwankenden Temparaturen ändert sich wohl ein wenig der Takt, was für viele Anwendungen recht egal sein dürfte.

Wenn das aus irgendeinem Grund nicht ausreicht würde ich das Ding in ein kleines Kistchen packen und mit 2 Stangen Heißkleber auffüllen. Kerzenwach sollte auch gehen, schrumpft aber ein wenig beim kalt werden und wird im Sommer schon weich.
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Kerzenwach sollte auch gehen, schrumpft aber ein wenig beim kalt werden und wird im Sommer schon weich.
Ich denke, "reines Bienenwachs" ist dafür besser geeignet. Das wird von einigen Voodoo-Priestern verwendet, um Anschluß-/Filterdosen an Antennen zu füllen. Nähere Angaben dazu können bestimmt die hier anwesenden Imker machen.
Antworten