Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

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

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

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

berlinerbaer hat geschrieben:Ohne jetzt den code gelesen zu haben, würde ich bei den sich überschneidenden Variablennamen einfach bei einem der beiden Treiber alle mit einem einheitlichen, kurzen Präfix versorgen, damit nix mehr durcheinander kommt.
das haut leider nicht hin, da in den Libs einen weiter Lib aufgerufen wird (im Link enthalten), die wieder auf die public-Variablen zugreift - und die kennt sich dann nicht mehr aus. - Nichts anderes, als wenn du im ISO-OSI Modell plötzlich Schicht 3 (oder war es 4?) doppelt hast. Mit wem soll Schicht 2 dann kommunizieren?
berlinerbaer hat geschrieben: Dann per Schalter zwischen beiden hin- und herschalten. Oder, noch simpler, die Buchsen in den zu steuernden Geräten direkt mit der passenden Brücke versehen, dann gehts ganz ohne Nachdenken und Platz genug wäre selbst bei einem DB9-Stecker...
Der Schalter war ja auch so irgendwie die Idee, damit der nicht selbst erkennen muss anhand des USB-Slaves, sondern vor dem Treiber laden weis, welchen.
Leider scheitert es schon beim compilieren - komm also gar nicht so weit.
Und die Buchse lässt sich ein bisserl schwer umbauen, nachdem das USB ist... ;)

@gafu: das ist mal ne Idee! Daran hatte ich noch gar nicht gedacht.
Muss ich morgen mal anschauen, was sich da bei Marlin tut. (Heute ist es schon ein wenig spät :roll: ) - Gute Nacht
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 »

Sir_Death hat geschrieben:
berlinerbaer hat geschrieben:Ohne jetzt den code gelesen zu haben, würde ich bei den sich überschneidenden Variablennamen einfach bei einem der beiden Treiber alle mit einem einheitlichen, kurzen Präfix versorgen, damit nix mehr durcheinander kommt.
das haut leider nicht hin, da in den Libs einen weiter Lib aufgerufen wird (im Link enthalten), die wieder auf die public-Variablen zugreift - und die kennt sich dann nicht mehr aus. - Nichts anderes, als wenn du im ISO-OSI Modell plötzlich Schicht 3 (oder war es 4?) doppelt hast. Mit wem soll Schicht 2 dann kommunizieren?
Nich im ernst?
Ich dachte solch schlechter Programmierstil ist unter den C Programmierern seit den 2000ern ausgetrieben.
Der OSI Vergleich hinkt, die Schichten sind Modular aufgebaut und sollen nicht ineinander greifen, nur Parameter übergeben.

Wie wärs richtig? So hier:

Code: Alles auswählen

static UART_HandleTypeDef s_UARTHandle;
-------------
    s_UARTHandle.Instance        = USART2;
    s_UARTHandle.Init.BaudRate   = 115200;
    s_UARTHandle.Init.WordLength = UART_WORDLENGTH_8B;
    s_UARTHandle.Init.StopBits   = UART_STOPBITS_1;
    s_UARTHandle.Init.Parity     = UART_PARITY_NONE;
    s_UARTHandle.Init.HwFlowCtl  = UART_HWCONTROL_NONE;
    s_UARTHandle.Init.Mode       = UART_MODE_TX_RX;
    
    if (HAL_UART_Init(&s_UARTHandle) != HAL_OK)
        asm("bkpt 255");
    
    for (;;)
    {
        uint8_t buffer[4];
        HAL_UART_Receive(&s_UARTHandle, buffer, sizeof(buffer), HAL_MAX_DELAY);
        HAL_UART_Transmit(&s_UARTHandle, buffer, sizeof(buffer), HAL_MAX_DELAY);
    }
Da wird ein struct genutzt um das Submodul zu parametrisieren, in diesem struct könnten auch Empfangsbuffer rein.

Oder kurz und knackig selber gebaut:

Code: Alles auswählen

static char usart3_tx_buf[256];
static char usart3_rx_buf[16];
static struct usart_irq usart3_irq;

void init_debugging(void){

	//USART3 Init für dprintf
	fifo_init(&(usart3_irq.tx_fifo), usart3_tx_buf, sizeof(usart3_tx_buf));
	fifo_init(&(usart3_irq.rx_fifo), usart3_rx_buf, sizeof(usart3_rx_buf));
	rcc_enable_clock(RCC_USART3);
	rcc_enable_clock(RCC_GPIOC);
	gpio_initpin(PORTC, 10, AF_PP, GPIO_HS, AF7_USART1_TO_3); //Altfunc TX Pin
	usart_init_irq(&usart3_irq, USART3_INDEX, 115200, 16000000);
	deprintf_setusart(USART3_INDEX, usart_putc);
}
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Okayyyy...

Sorry ich versteh absolut nur Bahnhofsalat.

Ist das jetzt eine lib für den USB am Arduino, oder was ist das? - Sorry die blöde Frage, aber ich verstehe nur, dass das irgendetwas mit senden und empfangen und den jeweiligen Buffern zu tun hat. Dann ist bei mir Schluss mit C...

Jaja ich weiß- lies ein Buch über C - mach ich, wenn der Tag 72 Stunden hat :-)
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Sir_Death hat geschrieben:Jaja ich weiß- lies ein Buch über C - mach ich, wenn der Tag 72 Stunden hat :-)
Wenn du C programmieren willst ohne C zu lernen, dann musst du vielleicht einsehen, dass du nicht jedes Ziel erreichen kannst. Dann funktionieren beide 'Libraries' nebeneinander halt einfach nicht und du musst alternativen suchen.

Ein abstraktes Konzept "ich versuche mehr oder weniger ein Plug and Play mit Autodetect zu programmieren, wo der Arduino selbst entscheidet, welchen Treiber er lädt." ist halt nicht mehr Trivial, sowas funktioniert ja sogar bei Computern immer mal wieder nicht vernünftig und man muss manuell Hand anlegen.
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 »

Das ist nichts gegen dich, sondern gegen die unfähigen Lib Programmierer ;)
Das wäre total egal welche CPU darunter werkelt, das soll son HAL/Treiber ja abstrahieren.

In dem struct sind Variablen, die definieren wie der UART zu werkeln hat.
Die struct Member Namen und die reingeschriebenen define Werte sprechen ja für sich.

static UART_HandleTypeDef s_UARTHandle; <- struct anlegen
s_UARTHandle.Instance = USART2; <- ansagen welcher UART, hier könnt man auch wegabstrahieren ob UART über USB wie beim 16U4 oder eben "normaler" UART an dem extern nen USB<->UART hängt. (der Treiber/HAL ruft dann eben das passende Submodul auf)
HAL_UART_Init(&s_UARTHandle) <- der eigentliche Init der Hardware

HAL_UART_Receive(&s_UARTHandle, buffer, sizeof(buffer), HAL_MAX_DELAY); <- hier wird beim lesen angegeben von welchem UART gelesen werden soll, das struct könnte schließtlich noch ne Statemachine des Treibers enthalten.

Mein eigener HAL bekommt dann eben gleich noch ne FIFO in Rachen geworfen für den UART IRQ.
fifo_init(&(usart3_irq.tx_fifo), usart3_tx_buf, sizeof(usart3_tx_buf)); <- bekommt den Buffer für die FIFO und speichert das FIFO Objekt im "Instanzobjekt" des HAL/Treiber ab
usart_init_irq(&usart3_irq, USART3_INDEX, 115200, 16000000); <- der Treiber init, hier schreibt nicht der User die Baudrate ins struct, das macht der Treiber selber, der Index wird bei meiner Lib mit angegbene, weil sich der Treiber den Pointer aufs struct merken kann.
deprintf_setusart(USART3_INDEX, usart_putc); <- dem printf sagen, dass er über UART3 ausgeben soll

Beispielhaft sieht der UARt Init dann so aus:

Code: Alles auswählen

#if USART_USE_IRQ
void usart_init_irq(struct usart_irq *idx, unsigned int usart_base, unsigned int baudrate, unsigned int bus_clk){

	volatile struct usart * const usart = (struct usart *)usart_bases[usart_base];
	irq_idx[usart_base] = idx;
	idx->usart_base_addr = usart_bases[usart_base];
	
	usart->CR1 = CR1_UE;
	usart->CR2 = 0;
	usart->CR3 = 0;	
	
	/*
		Baudteiler ist bus_clk/(16 * baudrate)
		Fraction hat 4 bits -> 16
		-> sparen wir uns die 16 und daher diese Formel:
	*/
	usart->BRR = bus_clk/baudrate;
	
	usart->CR1 |= CR1_RXNEIE | CR1_TE | CR1_RE;
	
	nvic_enable_irq(usart_irq_nbrs[usart_base], 0xE, 0xF);
};
#endif
Benutzeravatar
Sunset
Beiträge: 1498
Registriert: Fr 6. Dez 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sunset »

Ist ein neuer Arduino mit passendem CH340 nicht die simpelste Lösung?
Vielleicht findet sich ja jemand zum Tauschen, bei dem es egal ist, welche Schnittstelle der Arduino hat?
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

@Bauteiltöter: Hast ja recht - aber darum frag ich ja euch ;)

@Fritzler Aha! Danke für die Erklärung - das Wort "Hardware Abstraktion layer" hab ich schon mal gehört - wird für mich trotzdem ne ordentliche Herausforderung.

@sunset: wollte ich mir sparen, aber ist inzwischrn durchaus mehr als nur einen Gedanken wert. - nachdem ich im ganzen Haus schon um die 20 Arduino Mega verteilt habe, muss ich halt mal suchen gehen, wo ein Tauschkandidat werkelt.

@alle: Danke für eure Geduld - ich glaube, das gewünschte Ziel ist für mich momentan noch unerreichbar.
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 »

Das mit dem C Buch ist genau andersrum.
Es ist schneller dies zu lesen, als bei jedem Murks perkussionswartung anzuwenden bis es halbwegs läuft.

Zu empfehlen ist das Original:
https://github.com/germanoa/compiladore ... nighan.pdf
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Danke für den Link - ist schon gespeichert.
Mal schauen, wo ich das auf der Projektliste einordne.

Jedenfalls hat sich inzwischen gezeigt, dass der CH340-Treiber horrende langsam ist - da denkt man, das Programm wäre schon abgekackt.
Mit dem 16U2-Treiber geht es soviel schneller, dass keine Einschränkung merkbar ist - werd wohl die anderen beiden Maschinchen auch umrüsten...

Jedenfalls tut die Handsteuerung am Steckbrett schon - jetzt muss noch ein Gehäuse entstehen. Hmmmm..... mach ich das additiv oder subtraktiv? - immer diese schweren Entscheidungen ob Fräsen oder 3D-Drucken :lol:
Benutzeravatar
Rial
Beiträge: 2358
Registriert: Mi 23. Jul 2014, 19:20
Wohnort: Region Hannover

Re: Der AVR-/ARDUINO-Faden

Beitrag von Rial »

Hallo liebe Leute

Ich befasse mich grad mit dem Arduino Nano. (Danke Zabex) :D
Habe die letzten Tage schon viel gelesen,einiges an Hardware zum Spielen da
und auch noch einiges geordert,was hoffentlich in den nächsten Tagen kommt.

Ich habe auch schon ein konkretes Projekt im Kopf.
Es könnte auch ein UNO werden...
Die "einzelnen" Sketches" gibt es zum Großteil im Netz.
Die werde ich dann ausprobieren,wenn die restliche Hardware da ist.
Ich habe nur Sorgen,daß ich die nicht alle zusammengehäkelt kriege (für mein Projekt) :(

Gibt es jemanden auf dem Treffen 2018,der mir gegen Fleisch und Getränk helfen würde ?
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Ich habe seit langen mal wieder mal AVR Studio installiert, da ich eine Aufgabe für einen Tiny 45 habe.
Der kleine soll alle halbe Stunde einen Portpin auf kurz auf Low ziehen.
Im Prinzip also ein langsamer LED Blinker, dass habe ich auch schon hinbekommen und läuft :D

Nun verbaucht der Tiny etwa 1,3mA Strom. Ich habe ihn schon auf 1Mhz getaktet.
Das ist aber immernoch zuviel!
Welcher Schlafmodus macht hier Sinn?
Und wie baut man das am Sinnvollsten ein?
Der Tiny macht ansonsten nichts.
Da sind einfach nur 2 Delay Funktionen drin.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von Matt »

probiert mal mit 32khz Quarz und entsprechende flags (Fuses)

dann sollte der wenigere Strom verbrauchen.

Noch wenigere Stromverbrauch kann man erzielen, wenn man ihm zum schlafen bringt und Timer & Überlauf-Interrupt aktiviert.
Bei Überlauf (= Interrupt) wacht AVR auf und zählt einmal hoch, und prüfen, ob der LED anlachen sollen und dann wieder sich zum Schlafen legen.

Allerdings erfordert das völlige andere Konzept als "delay_ms"-Funktion. Doch, da macht TINY was, denn der zählt sich runter (so funktioniert "delay_ms")

Noch habe ich damit nicht befasst und da bin ich sicher, dass es möglich ist.
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 »

Delay Funktion heißt Vollgas aufm Kern.
Zudem kann der T45 auch mit dem internen Watchdogtakt laufen -> 128kHz.
Ansonsten nimmste den 8Bit Timer1 (der kann bis 16k vorteilen).
Den Konfigurierste so, das er alle xmin nen IRQ wirft.
Mit einem IRQ kann man den AVR Kern aufwachen, den packste nämlich ind en Idle Mode.
https://www.nongnu.org/avr-libc/user-ma ... sleep.html

Ich würd ja noch mehr schreiben, aber ich hör meine Straßenbahn kommen :mrgreen:
Anse
Beiträge: 2278
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Interner Watchdog und alle x Sekunden aufwachen lassen. Dazwischen in den Powerdown. Wenn man noch sparsamer unterwegs sein will kann man sich noch das Kapitel 7.3 im DB anschauen.
Auf die Weise läuft bei mir schon ein Tiny13 über 5 Jahre auf einer CR2032. Musste sie nur tauschen weil man den Piepser nicht mehr richtig gehört hat.
Fischjoghurt
Beiträge: 271
Registriert: Di 13. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fischjoghurt »

Hallo Leute

Nach langer langer Zeit habe ich wieder angefangen AVR sprich diesmal Arduino UNO zu programmieren. Früher mit WinAVR ohne Arduino aber da bin ich zu lange weg und deswegen programmieren ich den Arduino UNO mit Arduino Sketch. Es hat viele angenehme Funktionen wie das Arbeiten mit Strings was ich mit richtigem C richtig schrecklich finde. Was mich aber am meisten nervt ist, dass nicht alle Timer zur verfügung stehen. Der Timer0 ist für delay usw reserviert und diese Funktion brauche ich nicht.

Kann man den Timer 0 mit einem Trick in Arduino Sketch doch nutze?

Ich habe versucht mit:

ISR(TIMERO_OVF_vect)
{
digitalWrite(ledPin_13, digitalRead(ledPin_13) ^ 1);
}

bekomme ich die Fehlermeldung:

wiring.c.o (symbol from plugin): In function `__vector_16':
(.text+0x0): multiple definition of `__vector_16'
sketch\MyDyno_2.ino.cpp.o (symbol from plugin):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
exit status 1
Error compiling for board Arduino/Genuino Uno.


Mit :
ISR(TIMERO_OVF0_vect)
{
digitalWrite(ledPin_13, digitalRead(ledPin_13) ^ 1);
}

bekomme ich keine Fehlermeldung aber der Timer läuft nicht weil es wohl der falsche Vektor ist.
Was ist der Unterschied zwischen "TIMERO_OVF_vect" und "TIMERO_OVF0_vect" ?

Wer kann mir da helfen?

Und mit welcher IDE für Arduino abgesehen mit Sketch arbeitet Ihr?


Gruss
Benutzeravatar
Rial
Beiträge: 2358
Registriert: Mi 23. Jul 2014, 19:20
Wohnort: Region Hannover

Re: Der AVR-/ARDUINO-Faden

Beitrag von Rial »

Ich kriege ums Verrecken nicht den Arduino-Treiber für den USB-Serial
installiert !
Auf 2 verschiedenen Rechnern mit W7 Premium...
Die Installationsdatei von https://www.arduino.cc/en/Main/Software
läuft problemlos durch.Fragt auch brav,ob es die FTDI-Treiber und USB-Serial
installieren darf...

Wenn ich dann das Board anstecke "Treiber nicht gefunden/installiert".
Im Gerätemanager wird der USB-Serial ohne Treiber angezeigt.
Treiber aktuallisieren und den Ordner "Driver" von Arduino angeklickt :
Treiber konnte nicht gefunden werden...
Arne
Beiträge: 221
Registriert: So 11. Aug 2013, 19:12

Re: Der AVR-/ARDUINO-Faden

Beitrag von Arne »

Moin Rial,

ist denn auf dem Arduino ein FTDI drauf? Auf meinen Chinaclones sind CH340 drauf.

LG
Arne
Benutzeravatar
Rial
Beiträge: 2358
Registriert: Mi 23. Jul 2014, 19:20
Wohnort: Region Hannover

Re: Der AVR-/ARDUINO-Faden

Beitrag von Rial »

Ich habe 2 Nano-Clones und einen Uno-Clone ausprobiert.
Auf die beiden Nanos habe ich vor ein paar Wochen
auch schon das Beispiel "Blink" geschoben,welches auch funktioniert hat.

Aber auf einmal wollte es nicht mehr,bzw der Treiber war weg und lässt
sich nicht mehr installieren.
Benutzeravatar
Bastelbruder
Beiträge: 11483
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

Vielleicht hilfts ...
Der Treiber - nicht bloß der Ordner - muß explizit ausgewählt werden und nur dann kommt auch die bekannte Sicherheitsabfrage. Dann wird der Treiber tatsächlich "aktualisiert". Ansonsten tut Windoofs bloß so als würde es updaten und wenn man nachschaut ist genau nix passiert.
Hält halt vielleicht bloß bis zur nächsten Gängelung.
Wird Zeit daß hier der hualp!-emoticon eingeführt wird.
Benutzeravatar
Rial
Beiträge: 2358
Registriert: Mi 23. Jul 2014, 19:20
Wohnort: Region Hannover

Re: Der AVR-/ARDUINO-Faden

Beitrag von Rial »

Eine direkte Datei kann ich nicht auswählen.Nur den Ordner.
Siehe Bild

Ich habe auch keine Ahnung,was ich vor ein paar Wochen anders
gemacht habe !?! :?
Dateianhänge
Arduino.jpg
Benutzeravatar
Rial
Beiträge: 2358
Registriert: Mi 23. Jul 2014, 19:20
Wohnort: Region Hannover

Re: Der AVR-/ARDUINO-Faden

Beitrag von Rial »

Hat vielleicht jemad einen (deutschen) Link zu funktionierenden Nanos ?
Darf auch ein Uno sein...
Ama Zon oder Bucht ?
Ich bin gerne bereit,mehr als 2 Euro pro Board zu bezahlen :roll:
Aber auch nur,wenn es auf Anhieb mit der offiziellen Software funktioniert !!!
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Einerseits könnte es helfen, mal nach der Vendor-ID und der Device-ID des USB-Serial-Wandlers zu suchen, um sicherzustellen, dass das wirklich ein FTDI-Teil ist. Wenn nicht (z.B. der CH340), passenden Treiber suchen und installieren. Wenn es ein FTDI-Chip sein soll, dann könnte es noch ein gefälschter sein. Neue FTDI-Treiber sollen das erkennen können und verweigern dann die Zusammenarbeit. Wie man das konkret löst, weiß ich aber jetzt auch nicht.
Einen Treiber kann man auch installieren, indem man die .inf-Datei im Explorer auswählt und installieren lässt (ööööhhhhmmmmm, Doppelklick oder Kontextmenü, weiß ich jetzt gerade nicht).
Benutzeravatar
Rial
Beiträge: 2358
Registriert: Mi 23. Jul 2014, 19:20
Wohnort: Region Hannover

Re: Der AVR-/ARDUINO-Faden

Beitrag von Rial »

Einerseits könnte es helfen, mal nach der Vendor-ID und der Device-ID des USB-Serial-Wandlers zu suchen, um sicherzustellen,
dass das wirklich ein FTDI-Teil ist. Wenn nicht (z.B. der CH340), passenden Treiber suchen und installieren.
Geilo ! Das war das Problem ! Ich danke dir vielmals !!! :)
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Jetzt habe ich auch mal ein Problem mit einem Arduino Pro Mini. Ich habe ein Thermometer gebaut, das einen DS18S20 ausliest (mit der OneWire- und der DallasTemperature-Library) und den Messwert auf einem OLED-Display ausgibt (mit der Adafruit_GFX- und der Adafruit_SSD1306-Library). Außerdem wird je nach Temperatur auch noch ein Servo angesteuert (Standard-Arduino-Servo-Library). Das funktioniert auch im Wesentlichen ordentlich, außer, dass immer wieder und nach völlig unterschiedlichen Zeiträumen die loop-Funktion stoppt. Irgendwas stürzt da irgendwie ab und ich weiß nicht, wie ich dem auf die Schliche kommen soll. Hat da jemand eine Idee?
An der Stromversorgung sollte es eigentlich nicht liegen, es sei denn, der Servo stört doch mal sporadisch zu stark...
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

In welchen Zeitabständen stürzt das ab? - Hatte mal das selbe Problem mit einer windschiefen LCD-Library, in der Timer über das mitzählen von millisekunden gelöst waren - leider läuft auch irgendwann ein long int über...
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Das ist sehr unterschiedlich. Einmal ist das Teil nach einer halben Minute abgestürzt, dann läuft es mal eine Stunde klaglos. Komisch ist auch, dass der Servo dann nicht mehr angesteuert wird. Wird der über Software-PWM versorgt? (Hängt an Pin 9, einem PWM-Pin.)
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

da bin ich leider ratlos
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sven »

Gib Statusmeldungen auf der seriellen Verbindung aus, so dass du siehst, was das Teil gerade macht. Dann hast du einen Anhaltspunkt, wo es schief geht.

Generell gibt es gerne mal Probleme, wenn die Servo Lib zusammen mit irgendwelchen One-Wire oder ähnlichen Libs verwendet wird.
Bei Adafruit gibt es dazu einen Artikel inkl. Workaround. Dort ist die NeoPixel Ansteuerung problematisch aber das ist in diesem Fall eigentlich egal.
https://learn.adafruit.com/neopixels-an ... s/overview
Da kommen sich zwei Libs ins Gehege, die mit Interrupts arbeiten.

PS: Oder bau es einfach selber mit den Hardware Timern. Wenn ich mich recht erinnere wird Timer 0 von den internen Zeitgebern genutz (millis usw.)
Timer 1 ist frei verfügbar und hat 16 Bit Auflösung. Wenn du damit deinen Servo ansteuerst, läuft das komplett autark, ohne dass dir da ein Interrupt ein Bein stellt.
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Ordentlich aufgebaut (gelötet, nicht auf einem Steckbrett) und mit einer Servolibrary von Adafruit, die den Timer zur Hardware-PWM-Erzeugung verwendet, funktioniert das Ding jetzt zuverlässig...
lüsterklemme2000
Beiträge: 249
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Der AVR-/ARDUINO-Faden

Beitrag von lüsterklemme2000 »

Hallo,

Folgendes Problem:
Ich habe einen MCP2515 an einen Atmega328P über die SPI Schnittstelle angebunden.
Ich sitze jetzt seit etwa zwei Tagen daran, dass der Atmega mit dem MCP über SPI spricht. Aber da tut sich bisher nichts. Ich verwende Atmel Studio 7.
Versucht habe ich es bis jetzt unter anderem mit diesem Tutorial, sowie der Library von der Seite http://www.kreatives-chaos.com/artikel/can.


Bezüglich der Library, falls jemand Erfahrungen mit dar spezifischen Library aus dem Link von oben hat:
Ich habe die Library nach der Konfiguration für die aktuelle Hardware mit WinAvr zusammengebaut und mitsamt can.h und config.h in den Projektordner von Atmel Studio verfrachtet. Mit dem Beispiel aus der Library kompiliert das Programm ohne Fehler. Nach dem upload tut sich aber auf dem SPI Bus weiterhin nichts.
Das ist der Code:

Code: Alles auswählen

// coding: utf-8

#include <avr/io.h>
#include <avr/pgmspace.h>
typedef uint8_t prog_uint8_t;
#include "can.h"


// -----------------------------------------------------------------------------
/** Set filters and masks.
 *
 * The filters are divided in two groups:
 *
 * Group 0: Filter 0 and 1 with corresponding mask 0.
 * Group 1: Filter 2, 3, 4 and 5 with corresponding mask 1.
 *
 * If a group mask is set to 0, the group will receive all messages.
 *
 * If you want to receive ONLY 11 bit identifiers, set your filters
 * and masks as follows:
 *
 *	prog_uint8_t can_filter[] = {
 *		// Group 0
 *		MCP2515_FILTER(0),				// Filter 0
 *		MCP2515_FILTER(0),				// Filter 1
 *		
 *		// Group 1
 *		MCP2515_FILTER(0),				// Filter 2
 *		MCP2515_FILTER(0),				// Filter 3
 *		MCP2515_FILTER(0),				// Filter 4
 *		MCP2515_FILTER(0),				// Filter 5
 *		
 *		MCP2515_FILTER(0),				// Mask 0 (for group 0)
 *		MCP2515_FILTER(0),				// Mask 1 (for group 1)
 *	};
 *
 *
 * If you want to receive ONLY 29 bit identifiers, set your filters
 * and masks as follows:
 *
 * \code
 *	prog_uint8_t can_filter[] = {
 *		// Group 0
 *		MCP2515_FILTER_EXTENDED(0),		// Filter 0
 *		MCP2515_FILTER_EXTENDED(0),		// Filter 1
 *		
 *		// Group 1
 *		MCP2515_FILTER_EXTENDED(0),		// Filter 2
 *		MCP2515_FILTER_EXTENDED(0),		// Filter 3
 *		MCP2515_FILTER_EXTENDED(0),		// Filter 4
 *		MCP2515_FILTER_EXTENDED(0),		// Filter 5
 *		
 *		MCP2515_FILTER_EXTENDED(0),		// Mask 0 (for group 0)
 *		MCP2515_FILTER_EXTENDED(0),		// Mask 1 (for group 1)
 *	};
 * \endcode
 *
 * If you want to receive both 11 and 29 bit identifiers, set your filters
 * and masks as follows:
 */
uint8_t can_filter[] = 
{
	// Group 0
	MCP2515_FILTER(0),				// Filter 0
	MCP2515_FILTER(0),				// Filter 1
	
	// Group 1
	MCP2515_FILTER_EXTENDED(0),		// Filter 2
	MCP2515_FILTER_EXTENDED(0),		// Filter 3
	MCP2515_FILTER_EXTENDED(0),		// Filter 4
	MCP2515_FILTER_EXTENDED(0),		// Filter 5
	
	MCP2515_FILTER(0),				// Mask 0 (for group 0)
	MCP2515_FILTER_EXTENDED(0),		// Mask 1 (for group 1)
};
// You can receive 11 bit identifiers with either group 0 or 1.


// -----------------------------------------------------------------------------
// Main loop for receiving and sending messages.

int main(void)
{
	// Initialize MCP2515
	can_init(BITRATE_125_KBPS);
	
	// Load filters and masks
	can_static_filter(can_filter);
	
	// Create a test messsage
	can_t msg;
	
	msg.id = 0x123456;
	msg.flags.rtr = 0;
	msg.flags.extended = 1;
	
	msg.length = 4;
	msg.data[0] = 0xde;
	msg.data[1] = 0xad;
	msg.data[2] = 0xbe;
	msg.data[3] = 0xef;

	// Send the message

		can_send_message(&msg);


	
	can_send_message(&msg);	

	
	
	while (1)
	{
		// Check if a new messag was received
		if (can_check_message())
		{
			can_t msg;
			
			// Try to read the message
			if (can_get_message(&msg))
			{
				// If we received a message resend it with a different id
				msg.id += 10;
				
				// Send the new message
				can_send_message(&msg);
			}
		}
	}
	
	return 0;
}

Hat jemand von euch mit dem MCP schonmal so etwas gemacht und kann mir vielleicht eine Seite empfehlen, oder hat jemand sogar Code, der unter Atmel Studio läuft?

Ich wäre euch super dankbar, wenn ihr mir irgendwie weiterhelfen könnt. Ich komme nämlich nicht wirklich weiter.

Schönen Abend noch,
Lüsterklemme
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 »

Wie sieht die config.h denn aus?
lüsterklemme2000
Beiträge: 249
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Der AVR-/ARDUINO-Faden

Beitrag von lüsterklemme2000 »

Die sieht folgendermaßen aus:

Code: Alles auswählen

#ifndef	CONFIG_H
#define	CONFIG_H

// -----------------------------------------------------------------------------
/* Global settings for building the can-lib and application program.
 *
 * The following two #defines must be set identically for the can-lib and
 * your application program. They control the underlying CAN struct. If the
 * settings disagree, the underlying CAN struct will be broken, with
 * unpredictable results.
 * If can.h detects that any of the #defines is not defined, it will set them
 * to the default values shown here, so it is in your own interest to have a
 * consistent setting. Ommiting the #defines in both can-lib and application
 * program will apply the defaults in a consistent way too.
 *
 * Select if you want to use 29 bit identifiers.
 */
#define	SUPPORT_EXTENDED_CANID	1

/* Select if you want to use timestamps.
 * Timestamps are sourced from a register internal to the AT90CAN.
 * Selecting them on any other controller will have no effect, they will
 * be 0 all the time.
 */
#define	SUPPORT_TIMESTAMPS		0


// -----------------------------------------------------------------------------
/* Global settings for building the can-lib.
 *
 * Select ONE CAN controller for which you are building the can-lib. 
 */
#define	SUPPORT_MCP2515			1
#define	SUPPORT_AT90CAN			0
#define	SUPPORT_SJA1000			0


// -----------------------------------------------------------------------------
/* Setting for MCP2515
 *
 * Declare which pins you are using for communication.
 * Remember NOT to use them in your application!
 * It is a good idea to use bits from the port that carries MOSI, MISO, SCK.
 */
#define	MCP2515_CS				B,2
#define	MCP2515_INT				B,0

// -----------------------------------------------------------------------------
// Setting for SJA1000

#define	SJA1000_INT				E,0
#define	SJA1000_MEMORY_MAPPED	1

// memory-mapped interface
#define	SJA1000_BASE_ADDR		0x8000		// for ATMega162

/*
// port-interface
#define	SJA1000_WR				D,6
#define	SJA1000_RD				D,7

#define	SJA1000_ALE				E,1
#define	SJA1000_CS				C,0
#define	SJA1000_DATA			A
*/

#endif	// CONFIG_H
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 »

Der CS Pin stimmt nehm ich mal an?

In der Lib kann ich irgendwie die Funktion can_init nicht finden.
Für den MCP gibts nur eine mcp2515_init
lüsterklemme2000
Beiträge: 249
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Der AVR-/ARDUINO-Faden

Beitrag von lüsterklemme2000 »

Der CS Pin stimmt mit der Hardware überein.
Die Funktion can_init gibt es dort meine ich irgendwo, die ist mir heute schon begegnet. Ich suche aber sicherheitshalber nochmal.

Edit:

Code: Alles auswählen

#if ((BUILD_FOR_MCP2515 + BUILD_FOR_AT90CAN + BUILD_FOR_SJA1000) <= 1)
	#if (BUILD_FOR_MCP2515 == 1)

		#define mcp2515_init(...)					can_init(__VA_ARGS__)
		#define mcp2515_sleep(...)					can_sleep(__VA_ARGS__)
		#define mcp2515_wakeup(...)					can_wakeup(__VA_ARGS__)
		#define mcp2515_check_free_buffer(...)		can_check_free_buffer(__VA_ARGS__)
		#define mcp2515_check_message(...)			can_check_message(__VA_ARGS__)
		#define mcp2515_get_filter(...)				can_get_filter(__VA_ARGS__)
		#define mcp2515_static_filter(...)			can_static_filter(__VA_ARGS__)
		#define mcp2515_set_filter(...)				can_set_filter(__VA_ARGS__)
		#define mcp2515_get_message(...)			can_get_message(__VA_ARGS__)
		#define mcp2515_send_message(...)			can_send_message(__VA_ARGS__)
		#define	mcp2515_read_error_register(...)	can_read_error_register(__VA_ARGS__)
		#define	mcp2515_set_mode(...)				can_set_mode(__VA_ARGS__)
Das gibt es in can_private.h. Somit werden die Befehle den jeweils der Hardwarekonfiguration entsprechenden Funktionen zugeordnet. Also wird mit can_init() die Funktion mcp2515_init() aufgerufen.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Ich schätze ich bin hier nicht der erste, der ein Menü auf einem OLED Display anzeigen will, vielleicht kann mir jemand weiterhelfen.

Ich bastel schon den ganzen Tag mit dieser Bibliothek rum: https://github.com/neu-rah/ArduinoMenu

Fertige Bibliothek erscheint mir aus vielerlei Gründen sinnvoll, bis ich ein Menü selber geschrieben habe, was den sonst laufenden Code nicht blockiert und die Funktionen kann, die ich gerne hätte, vergehen wohl Wochen.

Ich bekomme mit dieser Bibliothek aber nichts ans laufen. Die Dokumentation erscheint mir mangelhaft (oder ich bin zu blöd?), klar, es gibt eine Menge Beispiele, die auch vollgepackt sind mit allerlei Code, aber wirklich verständlich geht nicht daraus hervor, was es alles an Funktionen gibt und wie diese zu nutzen sind.
Ich bekomme beispielsweise nichts auf meinem OLED Display angezeigt. Das Beispiel für das OLED Display zeigt zwar "hello world" auf dem Display an, wie es in der Setup Funktion steht. Aber kein Menü, ich bekomme das ums verrecken nicht hin.
Außerdem wird z.B. in der Setup Funktion eine Zeile Code auf dem seriellen Monitor ausgegeben, nur beim Ausführen von dem Programm erscheint die Zeile alle halbe Sekunde neu. Ruft sich da die Setup Funktion mehrfach auf? Wie soll das gehen? Ich verstehe einfach nicht, was da passiert.

Mein eigentliches Projekt ist Folgendes:
Unters Bett kommt ein Bewegungsmelder, eine Menge LEDs, ein LDR und in ein kleines Kästchen an die Wand das Gehirn, ein OLED Display, eine RTC und ein paar Knöpfe.
Ziel ist zum Einen ein Nachtlicht, was abhängig von der Uhrzeit die Helligkeit und Lichtfarbe verändert. Da kommt dann optimalerweise, wenn man die Füße aus dem Bett streckt, gerade so viel Licht unterm Bett hervor, wie man zum laufen braucht. E soll aber dunkel genug sein, dass der Andere problemlos weiterschlafen kann.
Zum Anderen soll da gleich ein Lichtwecker mit rein, dessen Weckzeit man auf einem Menü am Display einstellen kann.
Per Menü soll dann auch manuell das Licht mit auswählbaren Farben eingestellt werden können.

Hardware liegt schon eine Weile rum, Zeit ist in den nächsten Wochen auch gut vorhanden. Grundsätzliche Programmierung sollte auch möglich sein.
Es fehlt nur zunächst ein funktionierendes Menü.
Das Menü muss nicht viel können, hauptsächlich ein paar Variablen änderen (für Uhrzeit, Lichtfarben usw.).

Vielleicht ist die Bibliothek, die ich rausgesucht habe, auch viel zu kompliziert?
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 »

@Lüsterklemme
Auf dem SPI passiert wirklich NICHTS?
Haste das mit nem Oszi/Logicanalyzer überprüft?
Die mcp2515_init klimpert ja direkt auf dem SI rum, also irgendwas müsste man direkt am Anfang sehen.
lüsterklemme2000
Beiträge: 249
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Der AVR-/ARDUINO-Faden

Beitrag von lüsterklemme2000 »

Also der Logicanalyzer hängt dauerhaft am SPI. Da kommt absolut gar nichts an.
Aber folgendes ist mir eben aufgefallen:

Ich habe mal den Beispielcode in ein funktionierendes Programm integriert, welches über den SPI Daten rausschiebt. Solange man die Funktion can_init() nicht aufruft ist alles ganz normal.
Wenn man diese Funktion dann aber aufruft, scheint das Programm sich aufzuhängen und es passiert gar nichts mehr, auch auf normalen I/O Ports.
Jetzt stellt sich mir gerade die Frage, wo er sich aufhängt.

Der Ablauf ist ja wie folgt:

Code: Alles auswählen

bool mcp2515_init(uint8_t bitrate)
{
	if (bitrate >= 8)
		return false;
	
	SET(MCP2515_CS);
	SET_OUTPUT(MCP2515_CS);
	
	// Aktivieren der Pins fuer das SPI Interface
	RESET(P_SCK);
	RESET(P_MOSI);
	RESET(P_MISO);
	
	SET_OUTPUT(P_SCK);
	SET_OUTPUT(P_MOSI);
	SET_INPUT(P_MISO);
	
	// SPI Einstellung setzen
	mcp2515_spi_init();
mcp2515_spi_init() findet sich dann in spi.c

Code: Alles auswählen

void mcp2515_spi_init(void)
{
	#ifndef USE_SOFTWARE_SPI
		// Aktivieren des SPI Master Interfaces
		SPCR = (1<<SPE)|(1<<MSTR) | R_SPCR;
		SPSR = R_SPSR;
	#endif
}
und dann geht es mit dem Rest in mcp2515_init() weiter:

Code: Alles auswählen

// MCP2515 per Software Reset zuruecksetzten,
	// danach ist er automatisch im Konfigurations Modus
	RESET(MCP2515_CS);
	spi_putc(SPI_RESET);
	
	_delay_ms(1);
	
	SET(MCP2515_CS);
	
	// ein bisschen warten bis der MCP2515 sich neu gestartet hat
	_delay_ms(10);
	
	// CNF1..3 Register laden (Bittiming)
	RESET(MCP2515_CS);
	spi_putc(SPI_WRITE);
	spi_putc(CNF3);
	for (uint8_t i=0; i<3 ;i++ ) {
		spi_putc(pgm_read_byte(&_mcp2515_cnf[bitrate][i]));
	}
	// aktivieren/deaktivieren der Interrupts
	spi_putc(MCP2515_INTERRUPTS);
	SET(MCP2515_CS);
	
	// TXnRTS Bits als Inputs schalten
	mcp2515_write_register(TXRTSCTRL, 0);
	
	#if defined(MCP2515_INT)
		SET_INPUT(MCP2515_INT);
		SET(MCP2515_INT);
	#endif
	
	#ifdef RXnBF_FUNKTION
		SET_INPUT(MCP2515_RX0BF);
		SET_INPUT(MCP2515_RX1BF);
		
		SET(MCP2515_RX0BF);
		SET(MCP2515_RX1BF);
		
		// Aktivieren der Pin-Funktionen fuer RX0BF und RX1BF
		mcp2515_write_register(BFPCTRL, (1<<B0BFE)|(1<<B1BFE)|(1<<B0BFM)|(1<<B1BFM));
	#else
		#ifdef MCP2515_TRANSCEIVER_SLEEP
			// activate the pin RX1BF as GPIO which is connected 
			// to RS of MCP2551 and set it to 0
			mcp2515_write_register(BFPCTRL, (1<<B1BFE));
		#else
			// Deaktivieren der Pins RXnBF Pins (High Impedance State)
			mcp2515_write_register(BFPCTRL, 0);
		#endif
	#endif
	
	// Testen ob das auf die beschreibenen Register zugegriffen werden kann
	// (=> ist der Chip ueberhaupt ansprechbar?)
	bool error = false;
	if (mcp2515_read_register(CNF2) != pgm_read_byte(&_mcp2515_cnf[bitrate][1])) {
		error = true;
	}
	
	// Device zurueck in den normalen Modus versetzten
	// und aktivieren/deaktivieren des Clkout-Pins
	mcp2515_write_register(CANCTRL, CLKOUT_PRESCALER_);
	
	if (error) {
		return false;
	}
	else
	{
		while ((mcp2515_read_register(CANSTAT) & 0xe0) != 0) {
			// warten bis der neue Modus uebernommen wurde
		}
		
		return true;
	}
}
Und irgendwo dort muss er sich aufhängen. Wie geht man jetzt bei sowas zur Fehlersuche vor? Ich hätte jetzt angefangen einzelne Befehle und Funktionen aus mcp2515_spi_init() rauszunehmen, es dann immer wieder neu mit WinAvr zu bauen und das solange zu machen, bis es sich nicht mehr aufhängt. Dann schauen, was als letztes rausgenommen wurde.
Ist das eine sinnvolle Herangehensweise, oder ist das nur ein Symptom das dieser Abschnitt nicht funktioniert und das Problem liegt ganz woanders? (Es muss schließlich bei anderen Personen schon funktioniert haben)
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 »

Statt andauernd neucompilen würde ich da den UART in Betrieb nehmen und über diesen ausgeben bis wohin das Program grade kam.
(gutes altes printf Debugging)
Nen Debugger zum durchsteppen wär natürlich besser, hat aber fürn AVR kaum jemand.
UART Lib: http://homepage.hispeed.ch/peterfleury/ ... tware.html

Komplett aufhängen kann er sich eigentlich nur in der spi_putc, denn dort wartet er in einer while Schleife auf ein Flag.
lüsterklemme2000
Beiträge: 249
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Der AVR-/ARDUINO-Faden

Beitrag von lüsterklemme2000 »

@IPv6:
Wenn das mit der Library nicht funktionieren sollte für die Menüführung, dann kann man das auch gut selber machen.
Ich habe das bei meinem Wecker mit einem Drehencoder und zwei Schaltern gelöst. Da man bei solchen Projekten ja nichts steuern oder rechnen muss, während man im Menü rumwerkelt, ist die Programmierung der Menüführung relativ simpel. Wenn man sich einmal eine Menüstruktur überlegt hat (z.B. für die Lichtfarbenwahl), kann man die ja auch auf andere Sachen wie die Weckzeiteinstellung adaptieren. Wenn du möchtest, kann ich dir auch die Menüführung von meinem Wecker mal zukommen lassen (wenn ich die Software wiederfinde), dann kannst du dich ja inspirieren lassen :)

@Fritzler:
Dann baue ich mal einige Debuggmeldungen in die fraglichen Routinen und probiere es nochmal, danke.
MfG
Lüsterklemme
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Ich bin gerade auch am überlegen, ob eine solche doch recht komplexe Menü-Lib wirklich notwendig ist.
Allerdings wäre es für zukünftige Projekte auch gar nicht schlecht, sich mal an einfachen Beispielen mit Menüs auseinandergesetzt zu haben.

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

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

angehängte txt Datei in .ino umbenennen.

Ist ein Wecker mit 2 Stück 4-fach 7-Segmentanzeige + Doppelpunkt, Alarm ein über Schalter, Taster für Snooze, gesamte Bedienung über Dreh und Drück (Drehencoder mit Taste)
aktuelle Zeit auf grüner Anzeige, Weckzeit auf roter.
Während der Nacht werden die 7-Segment-Anzeigen abgeschaltet und durch drücken der Snooze Taste kurz aktiviert.
Ist der Alarmschalter ein, zeigt er auch die Weckzeit an, wenn nicht, dann nur die aktuelle Zeit

1 x Drücken am Encoder: gehe in den Weckzeit-Einstell-Modus.
Am Ende des Weckzeit-Einstell-Modus lange drücken (bis die Doppelpunkte leuchten) geht in den Einstellmodus für aktuelle Zeit + Nachtlicht Farbe + Nachtlicht Helligkeit
Weckmelodie liegt auf einer MicroSD-Karte in einem mp3-Modul, welches bei Spannung ein direkt losdudelt. Fertig
7-Segment-Stellen sind gemuxt - Helligeit selbst mit 1:3 MUX-Zeit und 1kOhm noch völlig ausreichend, aber auch so, dass es einem die Augen nicht raus haut.
RTC mit Knopfzelle ist drinnen für Stromausfall, Weckzeit wird im EEPROM gespeichert.

WAFF & DAFF (Wife & Doughter) ist mit dem Ding Grasgrün - wir haben schon 3 davon :D
lüsterklemme2000
Beiträge: 249
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Der AVR-/ARDUINO-Faden

Beitrag von lüsterklemme2000 »

@fritzler:
Das Problem scheint nicht die Library an sich zu sein, sondern die Library in Verbindung mit Atmel Studio.
Ich habe eben das Projekt mal mit WinAVR kompiliert und mit AVRDUDESS auf den Chip gebrannt. Sowohl mit einem Atmega8, wie auch mit einem offiziell nicht unterstützten Atmega328P funktioniert die Software und der SPI Bus einwandfrei :D
Sogar der MCP2515 schaufelt am anderen Ende fröhlich Daten raus, die sich auch mit dem Oszi wieder dekodieren lassen.
Vielen herzlichen Dank für die Tips und Ratschläge, wieder was gelernt. Wieso das mit Atmel Studio nicht funzt versuche ich dann morgen mal zu klären.

Schönen Abend noch,
Lüsterklemme
Benutzeravatar
Hightech
Beiträge: 11307
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Mit AVR-Studio hab ich auch schon so komische Erfahrungen gemacht, das irgenwelche Abhägigkeiten in dem Wust der Software nicht erfüllt werden.
Irgenwann hab ich ich dann auch vom AVR-Studio verabschiedet, die Suche nach irgend einem kruden Fehler hat mir zu lange gedauert.
Besonders Schlimmm ist es wenn man Teile von anderen Projekten übernimmt.

Ob das heute noch ein Problem ist, kann weiss ich nicht.
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 »

Ich weis ja, dass man das Atmelstudio meiden sollte wie der Teufel das Weihwasser.
Dies aber eher weil die Software total überladen ist.
Dass die sich noch sowas leisten is schon krass :shock:

Ich mein unter der Haube nutzen dir auch den GCC und wenn eine Datei fehlt, dann müsste spätestens der LInker meckern, dass da ein Symbol fehlt.
lüsterklemme2000
Beiträge: 249
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Der AVR-/ARDUINO-Faden

Beitrag von lüsterklemme2000 »

Welche Software wäre denn eine empfehlenswerte Alternative zu Atmel Studio?
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 »

Na so wie dus jetzt machst.
Editor deiner Wahl + Makefile + GCC + Utils
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Fritzler hat geschrieben:Editor deiner Wahl + Makefile + GCC + Utils
Örks, genau gegen so was wurden IDEs erfunden...
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Oder halt die Arduino IDE... :lol:
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

:roll:
nicht schon wieder...
Benutzeravatar
Raja_Kentut
Beiträge: 1528
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

Moin,

für meine Kellerentmuffung 2.0 brauche ich neben einem Sensor für Temperatur & Luftfeuchte (SHT31 im Einsatz) einen zweiten Temperatursensor für die Kellerbodentemperatur. Dieser residiert leider ca. 10m vom Arduinokaschtl entfernt. Daher brauch ich einen I2C Bus Buffer, da mehr als ca.3m Kabel nicht vom Arduino/STH31 getrieben werden können.
Ich hab bereits gesuuuuucht, konnte aber nichts fertiges finden. Bevor ich nun selbst was stricke (z.B. auf Basis P82B715) meine frage :

Gibt's da einen fertigen Shield für ? (hab einen für unverschämte 17USD/Stk von Sandbox gefunden...ist mir aber viel zu teuer)

sparsame Grüße,
RK
Antworten