-
Thread
AVR XPlained 328PB Freigabe/Nutzung von PCINT 21
> geht leider immer noch nicht Also bei mir läuft es; vielleicht besteht ein Missverständnis bezüglich der Funktion: nach Programmstart liegt C3 auf low, nach Drücken von Taster an D5 geht C3 *dauerhaft
#define F_CPU 16000000 #include <avr/interrupt.h> #include <avr/io.h> ISR(PCINT2_vect){ PORTC|=1<<PORTC3; } int main (void) { PORTD|=PORTD5; DDRC|=1<<PORTC3; PCICR|=1<<PCIE2; PCMSK2|=1<<PCINT21; sei(); while(1){} } [/c]
-
Thread
Ansteuerung eines Getribeschrittmotors in abhängigkeit der Drehzahl (nonblocking)
ist mehrere) mit 200. Mich beschleicht das Gefühl, als ob es nicht um mehrere Extruderschnecken geht, sondern ein AVR einen 3d-Drucker bewegen soll und ZUSÄTZLICH die Extruderschnecke. Die wiederum mal extrudiert und mal innehält (sogar zurückzieht um ein gutes Abreissen zu bewirken). Egal was,
bewegen soll. > Mich beschleicht das Gefühl, als ob es nicht um mehrere > Extruderschnecken geht, sondern ein AVR einen 3d-Drucker bewegen soll > und ZUSÄTZLICH die Extruderschnecke. Die wiederum mal extrudiert und mal > innehält (sogar zurückzieht um ein gutes Abreissen zu bewirken). > Der
-
Thread
Grafik Display mit Grafik Controller ST7565R - Probleme bei Zeichenausgabe
code]#include <avr/io.h> #include <avr/pgmspace.h> #define F_CPU 16000000 #define LCD_DATA PORTC #define LCD_DATA_DDR DDRC #define LCD_CONTROL PORTA #define LCD_CONTROL_DDR DDRA #define DB0 PC0 #define DB1 PC1 #define DB2 PC2 #define DB3 PC3 #define
begrüßen kann), musst du lernen, Datenblätter zu lesen und deren Restriktionen im Code umzusetzen. Es geht nicht anders.
-
Thread
avr-g++: external linkage von const/PROGMEM Symbol.
insbesondere wenn man viele Jahre lang mit deren Auswirkungen nicht in Berührung gekommen ist. Das geht aber alles völlig an der Frage vorbei, ob Dateierweiterungen ein haltbares Kriterium für deren Inhalt sind. Ich finde nicht. Aber das ist nur _meine_ Meinung.
als Erkennungsmerkmal > haltbar sein werden. Wer will denn so einen Murks! Ich denke, gcc geht von einem Posix-konformen OS aus.
-
Thread
Debuggen AVR DRAGON Variable ?
im Debugg Mode mit dem AVR Dragon in der Watchlist die Variable [c]int32_t val = 0;[/c] anschauen, geht das Überhaupt ? ich meine, wenn ich wärend ich im Debbug Modus bin und am Encoder drehe ? Denn, wenn ich die Variable zur Watchlist hinzufüge, steht optimized away, muss ich da den Compiler noch
Michael H. schrieb im Beitrag #6038565: > int32_t val = 0; > anschauen, geht das Überhaupt ? Nein. Lokale Variable kannst du nicht auslesen. Die mußt du zum Debuggen global oder static deklarieren. Im Run mitlesen geht auch nicht. Dazu mußt du entweder an geeigneter Stelle
-
Thread
C -> Makro für Pointer Adresse
als > dereferenzierung. Nein. Das + bewirkt wie bereits erklärt eine Intergerpromotion, deshalb geht die Warnung weg. Dereferenzierung ist was ganz anderes (andere Baustelle) und geschieht mit einem Sternchen (im vorliegenden Fall das Sternchen ganz links) oder man könnte es auch mit eckigen Klammern
. Man kann ein Byte sparen, indem man nur das Low-Byte der Adresse speichert. Beim ATmega2561 geht das aber in die Hose, da liegen Port H, J, K und L über 0x0100.
-
Thread
ATMega128 - Programm Reset nach Portzugriff (PORTA)
LCD-Controller in einem 12864 LCD ansprechen. Die Datenübertragung ist im 8-Bit-Mode. Datenport ist PORTC, Über PA4..PA7 laufen RS, RW, E und RST. Der ATMega128 hat folgende Fuses: L:E4, H:D1, E:FF. Problem: Sobald ich PA7 auf "hi" setze (also nach dem RESET des LCD) und einen weiteren Schreibzugriff
in das Hauptprogramm setze, der Fehler dann nicht mehr auftritt. Dann habe die PINs an PORTA und PORTC bei Überprüfung mit dem Scope die korrekten Signale und Soft- und Hardware arbeiten einwandfrei. Die Platine habe ich auch überprüft. Zwei ATMega128 (jeweils auf Breakoutboards verlötet) zeigen
-
Thread
ATmega328P AnalogPin7
ADC_Test_Channel 7 #define Test_DDR_REG DDRC #define Test_PORT_REG PORTC #define Test_PIN PINC #define Test_BIT PC7 uint16_t ADC_Read( uint8_t channel ); uint16_t ADC_Read_Avg( uint8_t channel, uint8_t nsamples ); void ADC_Init(void) { Test_DDR_REG
Test_PORT_REG |= (1 << Test_BIT); Aber hier versuchst du ihn als digitalen Ausgang zu benutzen. Das geht nicht. Der Pin kann nur als analogen Eingang verwendet werden. Es gibt keinen Pin PC7. Die Eingänge ADC6 und ADC7 sind analoge Eingänge ohne digitale Funktion, deswegen gibt es da nichts zu konfigurieren
-
Thread
Fehler bei CONFIG PIC 18F2420
Am einfachsten geht es so: https://microchipdeveloper.com/mplabx:view-and-set-configuration-bits
CCP2MX = PORTBE ich hab doch gesagt, alter mist ... wann lernst du endlich LESEN?! CCP2MX = PORTC/PORTB
-
Thread
ATtiny24A, Power-down
er wieder in den Tiefschlaf gehen. Am Besten, daß unter anderem kein Oszillator mehr an ist. Geht das überhaupt und wenn ja, wie? Danke Mathias
Mathias H. schrieb im Beitrag #5992270: > Geht das überhaupt und wenn ja, wie? Das geht. Schau dir dazu die Library #include <avr/sleep.h> an. Du brauchst im Code [c]set_sleep_mode(SLEEP_MODE_PWR_DOWN);[/c] und aktiviert wird der Sleepmode
-
Thread
Lokale Variable statt static, aber optimiert. Wie?
Maxim B. schrieb im Beitrag #5950976: > Was habe ich falsch gemacht? Das geht nur mit C++... Also mit g++ statt gcc kompilieren
brauchtest Du einen Kommentar, der hier aber auch nicht viel hilft. Nimm wenigstens enum-types dafür (geht in C nicht besser).
-
Thread
IR NEC Signal mit einlesen
eingelesenen überprüft. Bei Abweichung... Routine verlassen und wieder von Vorne. Bei Übereinstimmung geht es mit dem Einlesen des 8Bit Kommandos weiter. Dieses wird dann im zweiten Lesevorgang mit dem invertierten Kommando verglichen. Abweichung = Routine verlassen. Übereinstimmung = weitermachen. Zur
// Taste MENU (PINC & (1<<PINC4))) // PC4 = high ->einlesen Funktioniert NICHT { PORTC |= (1<<PC2); // Ausgang PC2 ansteuern, da PC4 high ist msec_counter = 200; // countdown auf 200 (maximal 255 moeglich!) }
-
Thread
alle Tage wieder: Externer 12 MHz Quarz schwingt nicht
falschen Routine verfallen. Wollte nur mal ein WE Miniprojekt machen. (L-Meter) Display ist an PORTC und an T0 ist ein anderer Oszillator (zum Induktivität ermitteln). Diesen habe ich aber Stillgelegt, um dort einen Fehler auszuschließen. Mit dem Oszi messe ich zwischen GND und XTAL1...nix. Und
, wegen der Oszileitung, aber bla bla von mir). CHOPT ändert nichts. Mit einem anderen Mega8 gehts auch nicht. Ich gehe davon aus, dass ein Hardwarefehler am Quarz vorliegt. Vielleicht hats beim Löten oder Messen einen weggekriegt. Mein Lötkolben scheint manchmal einen ordentlichen Spannungspegel
-
Thread
Arduino ATMega328 Breadboard Pin Definitionen
code here, to run repeatedly: delay(100); //Serial.println("An"); digitalWrite(PC1,1); //PORTC |= 0x02; delay(100); //Serial.println("Aus"); digitalWrite(PC1,0); //PORTC &= ~0x02; } Pin 24 wackelt nur, wenn ich die im obigen Beispiel auskommentierten Zeilen aktiviere. Es
A hat mir leo ja weitergeholfen, aber bei Port D muss ich wieder auf die PDs gehen: Das hier geht: pinMode(PD6, OUTPUT); Das geht nicht: pinMode(D6, OUTPUT); Compiler Ausgabe: 'D6' was not declared in this scope Warum kennt er A1..A5, aber nicht D6? Wo stehen die Pin-Definitionen und
-
Thread
[AVR] Unerwarteter Compilerfehler mit constexpr
PORTH,&PORTH,&PORTD,&PORTD,&PORTD,&PORTD,&PORTA,&PORTA,&PORTA,&PORTA,&PORTA,&PORTA,&PORTA,&PORTA,&PORTC,&PORTC,&PORTC,&PORTC,&PORTC,&PORTC,&PORTC,&PORTC,&PORTD,&PORTG,&PORTG,&PORTG,&PORTL,&PORTL,&PORTL,&PORTL,&PORTL,&PORTL,&PORTL,&PORTL,&PORTB,&PORTB,&PORTB,&PORTB,&PORTF,&PORTF,&PORTF,&PORTF,&PORTF,&
dass es in einer neueren Kompilerversion mit gleichem ausgewählten c standard plötzlich nichtmehr geht, gibt es dort eigentlich nicht.
-
Thread
Timer sek zähler
main: cpi temp5,5 ; 5 Sekunden breq led_stat rjmp main led_stat: sbis PINC,0 sbi PORTC,0 sbic PINC,0 cbi PORTC,0 ldi temp5,0 ; Wieder auf 0 und von vorne... rjmp main [/c] Momentan lasse ich damit noch ein LED blinken, damit ich mit dem Oszi den Zeitabstand messen
*** main: cpi temp5,5 breq led_stat rjmp main led_stat: sbis PINC,0 sbi PORTC,0 sbic PINC,0 cbi PORTC,0 ldi temp5,0 rjmp main [/c]
-
Thread
LED Array mit MBI5026CN und PIC 16F688
PORTC|0x01) // xxxx xxx1 Clock H -> Pin 10 #define C_0 PORTC=(PORTC&0xFE) // xxxx xxx0 Clock L #define D_1 PORTC=(PORTC|0x02) // xxxx xx1x Data H -> Pin 9 #define D_0 PORTC=(PORTC&0xFD) // xxxx xx0x Data L #define L_1 PORTC=(PORTC|0x04) // xxxx x1xx Latch H -> Pin 8 #define L_0 PORTC=(PORTC&0xFB) // xxxx x0xx Latch L #define SW1 !(PORTA&0x02) //
-
Thread
Warum funktioniert mein AVR Assembler Code nicht?
einlesen geht nicht! Matthias S. schrieb im Beitrag #5892838: >> Ist ja auch richtig. Man liest das gesamte Port (PORTC)ein. > > Immer noch nicht. Man liest PINC, denn nur da finden sich die Zustände > der Inputports. Vielleicht geht das in irgend einer Hochsprache, aber in Assembler geht das nicht. Da geht nur PORTC. Hoffentlich ist das Elend bald zu Ende.
-
Thread
AVR: Ist PORTx |= atomar?
Gerd schrieb im Beitrag #5862714: > PORTC |= xx, PORTC &= xx Wie soll das bitte funktionieren ohne den Port vorher zu lesen? Atomar wäre nur PORTC = xx.
Ich verstehe keinen Assemböer. Hier der Code, wenn jemand helfen möchte. Es geht um PORTC vom ATMega1284: An dem läuft Software-SPI (s.u.) und andere Bits werden in Interrupts geändert. Im C-Code für SPI verändern die Makros SOFTSPI_SCK_TOGGLE(), SOFTSPI_MOSI_HIGH(), SOFTSPI_MOSI_LOW
-
Thread
AVR reagiert nicht
leo schrieb im Beitrag #5853505: > DDRC &= ~(1<<PORTC2) | (1<<PORTC3) | (1<<PORTC4) | (1<<PORTC5); Unabhängig vom Flasherproblem: Soll wirklich nur PC2 ein Eingang und PC3 bis PC5 Ausgänge sein ?
Ralph S. schrieb im Beitrag #5853649: >> DDRC &= ~(1<<PORTC2) | (1<<PORTC3) | (1<<PORTC4) | (1<<PORTC5); Ich verbessere mich: PC2 als einziger Pin ist Eingang, alle anderen des PortC sind nach dieser Angabe Ausgänge ! ~(1 << PORTC2) => ~(0000.0010
-
Thread
Falsche Ausgangsspannung Mega16
Guten Tag, im Anhang befindet sich ein Schaltplan mit meiner Problemschaltung. Dabei geht es lediglich um den ULN2003, der am Port C meines atmega16 angeschlossen ist. Der Debug-Code ist denkbar einfach: DDRC = 0b1111100; PORTC = 0x1111100; while(1); Am Ausgang des m16 liegt aber
Thomas schrieb im Beitrag #5846133: > PORTC = 0x1111100; Da gehört ein "b" hin, nicht "x". Außerdem fehlt bei beiden Anweisungen eine 1 für das höchste Bit (PC7). Ansonsten würde ich auch auf die JTAG Fuses tippen, an denen liegt es fast
-
Thread
AVR Atmega 328 Hilfe bei LED Taster Schaltung
soll die LED auch ausgehen. Das einschalten der LED funktioniert auch tadellos nur aus ausschalten geht nicht immer. Es scheint so als wäre die LED beim loslassen des Tasters in keinem definiertem Zustand da sie mal an bleibt und mal ausgeht. Leuchtet die LED weiter, leuchtet sie beim nächsten Betätigen
int main(void) { DDRB = 0xFF; //Register B Ausgänge DDRC = 0x00; // Register C Eingänge PORTC = 0xFF; // Register C Pullups ein while (1) { if (!(PINC & ( 1<<PC4 ))) //wenn PC4 HIGH dann... { PINB |= ( 1<<PB0 ); // LED an PB0 an } else { PINB
-
Thread
Kann einer helfen?
Edit: Verlesen. Die LEDs sind Low-Aktiv. Das heißt, wenn der zugehörige Pin LOW ausgibt, geht die LED an. Da du das Port-Register nicht angefasst hast, ist PORTC komplett auf 0x00. Damit ist Pin C1 auf Ausgang (DDRC = 0x01) und gibt LOW (sprich, annähernd 0V) aus. Bei PORTC = 0x01 geht der Pin auf HIGH (nahezu 5 V) und die LED geht aus.
-
Thread
SimulAVR, GDB Programm mit ADC simulieren
gearbeitet. War mir aber zu groß und zu mächtig. mplab ide wird wohl ähnlich geartet sein. In avr-gcc geht das irgend wie so. [c] sbi((*(volatile uint8_t *)((0x04) + 0x20)), 5); [/c] Laut microchip [c] #define sbi(port,bit) \ (port) |= (1 << (bit)) Set bit in IO port port. [/c] Das muss
: MESSAGE: attach: IO Reg 'DDRC' at 0x0034: ref = 0x0033 devsupp.c:316: MESSAGE: attach: IO Reg 'PORTC' at 0x0035: ref = 0x0033 devsupp.c:332: MESSAGE: attach: IO Reg 'PINB' at 0x0036: created devsupp.c:316: MESSAGE: attach: IO Reg 'DDRB' at 0x0037: ref = 0x0036 devsupp.c:316: MESSAGE: attach: IO
-
Thread
STM32 Problem SPI und Tasten multiplexen
_1_ MISO eine AF) PortB 0 - Spalte 0 PortB 1 - Spalte 1 PortB 2 - Spalte 2 PortB 10 - SCK PortC 0 - nCS PortC 2 - MISO PortC 3 - MOSI PortC 4 - Zeile 0 PortC 5 - Zeile 1
eben drüber zu schreiben) Da war noch etwas Dreck zwischen den Pins, konnt ich rauskratzen, jetzt gehts.
-
Thread
Servo verhält sich nicht wie erwartet
Ich muss das Poti ganz langsam drehen, dann geht der Servo auch voll rum. Wenn ich zu schnell drehe (was heißt nicht in zeitlupe zu drehen), kommt der aus dem Trott und macht einfach klackendes Geräusch. Dann muss ich das Poti wieder an die Position
Vielleicht zieht der Servo auch einfach nur zu viel Strom und der Prozessor geht durch den Reset. Was hast du für eine Versorgung?
-
Thread
Byte auf verteilten Ausgängen ordnen
); if (byte & 0x08) PORTD |= (1 << PD3); else PORTD &= ~(1 << PD3); if (byte & 0x10) PORTC |= (1 << PC3); else PORTC &= ~(1 << PC3); if (byte & 0x20) PORTC |= (1 << PC2); else PORTC &= ~(1 << PC2); if (byte & 0x40) PORTC |= (1 << PC1); else PORTC &= ~(1 << PC1); if (byte & 0x80) PORTC |= (1 << PC0); else PORTC &= ~(1 << PC0); } int main( void ) { while( 1 ) portout2( PINB ); return 0; } [/c] Trotzdem würde ich eher die 1. Variante nehmen, da die 2. bei
-
Thread
Bekomme mein LCD Display nicht ins Laufen
Ich denke nicht Das musst du aber, entweder über die Fuses oder deinen Code. Wie das per Code geht weiss ich im Moment leider nicht mehr;)
denke nicht > > Das musst du aber, entweder über die Fuses oder deinen Code. > Wie das per Code geht weiss ich im Moment leider nicht mehr;) Ich lese mich bzgl. JTAG mal genauer ein, danke für den Hinweis :)
-
Thread
Probleme mit LCD-Display und SPI Übertragung
das Display ist wie folgt verbunden: RS PORTD4 RW PORTD1 E PORTD0 DATA4 PORTC0 DATA4 PORTC1 DATA4 PORTC2 DATA4 PORTC3 Im Anhang ist die LCD Libary. Mein Programm: [c] #include <avr/io.h> #include <avr/interrupt.h> #include "lcd.h" #include "lcd.c" volatile
wie folgt > verbunden: > > RS PORTD4 > RW PORTD1 > E PORTD0 > DATA4 PORTC0 > DATA4 PORTC1 > DATA4 PORTC2 > DATA4 PORTC3 Sicher? Ich würde es mal mit Data7, Data6, Data5 und Data4 versuchen.
-
Thread
Atmega8 Ausgang schaltet nicht
avr/io.h> #define F_CPU 8000000UL int main(void) { DDRC = 0xFF; while (1) { PORTC = 0xFF; } } [/c] Doch siehe da: Immer noch kein Mucks! Der Compiler meckert nicht (weswegen auch), Programmierung läuft wie gewohnt, Multimeter habe ich gecheckt (tadellos), ich habe schon
hat eine Idee, wo ich einen Fehler haben könnte? PS: Das LCD habe ich schon lange aufgegeben, es geht mir nur darum 5V an PORT C messen zu können :')
-
Thread
PIC16F1933: Interrupt triggert mehrfach; Flanke zu flach?
Interrupt-Routine und Kanal 1 der "debug_ausgang" aus der Main-Schlaufe. Meine Frage ist nun, geht hier gar keine Hardware-Entprellung, oder habe ich was Anderes übersehen? Ich arbeite nun seit 2 Tagen an diesem Problem. Vielen Dank! Gruss Chregu Testcode, Oshonsoft Basic, aufs nötigste
Christian M. schrieb im Beitrag #5736272: > Meine Frage ist nun, geht hier gar keine Hardware-Entprellung, oder habe > ich was Anderes übersehen? Ich arbeite nun seit 2 Tagen an diesem > Problem. Sieh es mal aus der Frequenzdomäne. Du versuchst ein relativ langsames
-
Thread
Abfrage Taster durch USI vom Slave mit zwei AVR
(byte4 == 30) { // Wenn Wert 30 gelesen wurde... PORTC &= ~( (1<<PINC5)); // schalte Port A6 PORTC |=(1<<PINC6); // wenn nicht lösche Port A6 } else { PORTC |=(1<<PINC5); // wenn
(byte4 == 30) { // Wenn Wert 30 gelesen wurde... PORTC &= ~( (1<<PINC5)); // schalte Port A6 PORTC |=(1<<PINC6); // wenn nicht lösche Port A6 } else { PORTC |=(1<<PINC5); // wenn