-
Thread
ATMega328-basierter Sprach-Synthesizer für den CPC 464 - Schnelles Byte-weises Lesen mit dem 328?
Es geht um 0x... <-> 0b...
int main(void) { DDRB = 0; DDRC = 0b00110000; initUSART(); clearBit(PORTC, 5); clearBit(PORTC, 4); while (receiveByte() != ':'); buffer_index = 0; last_low = 0; last_high = 0; initInterrupt(); while ( 1 ) { setBit(PORTC, 5
-
Thread
Berechnungsfehler bei der Konstruktion von Assembler Warteschleife?
), dann sind die Zeiten spürbar kürzer. Ich versuchte es so: [avrasm] longdelay: sbi PORTC, 0 ldi Temp3, 40 ; wait 1200ms loop: rcall Delay30ms ; 30ms x 40 dec Temp3 brne loop cbi PORTC, 0 ret [/avrasm] Das Signal auf PORTC dient
Jo, geht mal wieder zur Sache hier ;-) Mal im Ernst: Ich kann die Empörung des Themenstellers vollkommen verstehen. Unsachliche, arrogante und beleidigende Posts, wir die von C-hater, haben hier nichts
-
Thread
STM32Fxxxx Machbarkeit Frage
mehreren STM32Fx einzusetzen und die nötige Signale abzutasten und darzustellen bzw. einzullogen. Mir geht erst mal darum: Ist das machbar? Ursprüngliche Idee war eine NI-USB-XXXX einzusetzen, aber da es die Synchronistaion sehr wichtig bzw. die Abtastrate noch wichtig ist, können wir das nicht mit NI
ganze Darauf zuschneiden. Quasi Steuerbyte = 10100000 bedeutet das 2 Byte nutzdaten von Porta und portc übertragen werden da auf Portb und Porto keine Veränderungen beim Sample vorhanden waren.
-
Thread
externer interrupt
1 << ISC10)|(1<<ISC11); sei(); while(1){ PORTC=0xff; _delay_ms(1); PORTC=0x00; _delay_ms(1); } } ISR(INT1_vect) { PORTB=0xff; PORTB=0x00; }[/c] Ein Signal des PortC wird dabei zum Test auf den INT1/PD3 gegeben. Zum Oszibild: blau PortC und gelb PortB
-
Thread
c compiler Unterprogramme aufrufen mit Funktion
Nach 1000 Sekunden (16,7min) geht sie aus.
Warum erst in 16,7Minuten und wann geht sie Wieder an ?
-
Thread
[C] GCC Atmega32, Menü über Funktionspointer, PeDa Entprellung, unterscheidet key_short/long nicht
horizontal navigiert, mit PC2/PC6 "lang" übernimmt man die in "Option x einstellen" gesetzten Werte bzw. geht wieder eine Menüebene hoch. Jetzt zum eigentlichen Problem: Mit den Tasten Hoch(PC5)/Runter(PC4) kann ich mich problemlos navigieren. Wenn ich im "Startmenü" bin, kann ich zum Testen mit der
auf einen kurzen Tastendruck von PC3. Ein "langer" Tastendruck wird nicht mehr erkannt, sondern er geht als "kurzer" durch. Selbiges passiert auch mit den Tasten, die für die horizontale Navigation zuständig sind. Zum Eingrenzen des Problems: Das Startmenü funktioniert einwandfrei, in allen anderen
-
Thread
IO-Pins als Bitfeld zusammenfügen und maskieren (AVR)
//welche Ports werden für die Motoren verwendet volatile uint8_t * Port_Mask[ARRAY_LENGTH] = { &PORTC, &PORTC, &PORTC, &PORTC, &PORTA, &PORTA, &PORTA, &PORTA, &PORTB }; //mit welchen Pins sind die Motoren verbunden uint8_t Pin_Mask[ARRAY_LENGTH] = {PC7, PC6, PC5, PC4, PA7, PA6, PA5, PA4, PB0};
pin) //»a->b« Kurzform für »(*a).b« #define SBIT(x,y) SBIT_(x,y) #define MOTOR1 SBIT( PORTC, 7 ) #define MOTOR1_DDR SBIT( DDRC, 7 ) #define MOTOR2 SBIT( PORTC, 6 ) #define MOTOR2_DDR SBIT( DDRC, 6 ) #define MOTOR3 SBIT( PORTC, 5 ) #define MOTOR3_DDR SBIT( DDRC, 5 ) #define
-
Thread
RFM24W Datenblatt unklar
9600 Ddrc = &B111111 Ddrd = &B11111110 Ddrb = &B11101111 NSEL alias PortC.0 RX_ANT Alias Portc.1 TX_ANT Alias Portc.2 config spi= hard, interrupt = off, Data_order = MSB, Master = yes, polarity = high, phase = 0, Clockrate = 16, Noss = 1 spiinit dim spi_inp as Byte Do Nsel = 0
Bytes ja nur jeweils 8 Clockimpulse. Da wird es egal sein, was ich an das Modul sende. Zumindest geht aus dem Impulsdiagramm und dem Text nicht hervor, was genau gesendet werden soll, wenn Daten aus dem Modul herausgetaktet werden sollen. Ich habe es gerade nochmal probiert. Was mich etwas stutzig
-
Thread
SN74HC595N QH´-Pin dauerhaft HIGH
SPI-Bus funktioniert normal: CPOL = 0 CPHA = 0 Frequenz: 1 MHz Master-Mode MOSI, SCK, SS und PORTC, 3 als Ausgang gesetzt --> Mit Oszi nachgemessen, stimmt alles (Datensignal ist da, Clock ebenfalls, OE geht zu Beginn der Übertragung auf HIGH damit LEDs nicht flackern, RCK geht zu Beginn der
Möglichkeiten: 1 Wir glauben dir. 2 Wir glauben an die bisher gültigen Naturgesetze. Beides geht nicht. Georg
-
Thread
Strukturierte AVR-Assembler-Programmierung Gesperrt
in LEDport,PORTC eor LEDport,bitmask ; toggle masked LED position out PORTC,LEDport IF LEDcnt == #7 ldi bitmask,0b00_0001 ; reload bitmask ELSE lsl bitmask
in LEDport,PORTC eor LEDport,bitmask ; toggle masked LED position out PORTC,LEDport IF LEDcnt == #7 ldi bitmask,0b0010_0000 ; reload bitmask ELSE lsr
-
Thread
AVR Anfang / Flash geht aber Programm scheint nicht zu laufen
CK3 heißen auf 0 gesetzt und jetzt spricht der Mega8 nicht mehr > mit mir "reset to default geht auch nicht" ;-(((
Posting https://www.mikrocontroller.net/topic/424250?reply_to=4961949#4961849 bedeutet, dass es nicht geht. Dieses https://www.mikrocontroller.net/topic/424250?reply_to=4961949#4961927 hingegen, dass es geht; zumindest das Verifying. Was trifft jetzt zu? Am besten versuchst Du einfach mal die Fuses
-
Thread
PIC 16F723 und UART Problem
**************************** ;* ;* Pinbelegung ;* ---------------------------------- ;* PORTC: 0 ;* 1 ;* 2 ;* 3 ;* 4 ;* 5 ;* 6 RS-232-Ausgang zum Treiber ;* 7 RS-232-Eingang vom Treiber ;* ;**********************************************
Danke für die Tipps. Ich weiß nicht woran es lag, aber es geht jetzt. Habe den Code nochmal neu zusammenkopiert. Beim Vergleichen kann ich aber keinen Unterschied feststellen. Ich kann den Fehler also nicht nachvollziehen. Aber egal, es geht bis auf eine
-
Thread
Externer Interrupt
1 << ISC30); EIMSK = (1 << INT3); EIFR = (1 << INTF3); DDRC &= ~(1 << PC0); PORTC |= (1 << PC0); } [/c] Hier die ISR: [c] volatile unsigned int test = 0; ISR (EXT_INT3_vect) { test++; } [/c] Und in der main innerhalb der while(..) frage ich die Variable test ab:
Schön, wenn der PIN mittels Pullup auf high gehalten wird Gera schrieb im Beitrag #4955934: > PORTC |= (1 << PC0) wird das nur wenig bewirken. Schaltung, komplettes Program ...
-
Thread
Benörige Hilfe bei Grafikdisplay LM240120
Geht nicht so einfach. Das sind 8051 (bzw. 8052) spezifische Sachen, die es auf dem AVR in der Form nicht gibt - jedenfalls nicht in C. Aber: So ein parallel LCD Interface gibts für AVR wie Sand am Meer
Ja, hatte den PortC komplett auf Ausgang gesetzt: DDRC |= (0xff). Wenn ich mir das mit den ganzen Speicherfressenden Bits anschaue, kann das wohl auch rechnerisch nicht passen. Bei 120x240 Pixeln wären das ja schon
-
Thread
AtMega16 Timer Problem
F_CPU / 1024 * 10e-3 + 0.5); // preload for >10ms Warum nimmst du das umständliche Preload? Das geht doch mit OC-Interrupt einfacher. Wo kommen die 8,3MHz her? MfG Spess
erste grobe Messung des internen Oszilators. Laut Oszi liege ich damit bei 1,002 Sekunden. Natürlich geht das noch genauer, aber da war ja erstmal nicht mein Problem Hab es jetzt auf 10ms pro Overflow umgebaut und jetzt passt es. Vielen Dank allen für die Antworten
-
Thread
SPI zwischen zwei AtMega8
PORTD |= (1<<PD6); } } void changeDigitToOnAndOthersOff(int digit){ if(digit == 1){ PORTC |= (1<<PC0); PORTC &= ~((1<<PC1) | (1<<PC2) | (1<<PC3)); }else if(digit == 2){ PORTC |= (1<<PC1); PORTC &= ~((1<<PC0) | (1<<PC2) | (1<<PC3)); }else if(digit == 3){ PORTC |= (1<<PC2); PORTC &= ~((1<<PC0) | (1<<PC1) | (1<<PC3)); }else if(digit == 4){ PORTC |= (1<<PC3); PORTC &= ~((1<<PC0) | (1<<PC1) | (1<<PC2)); } } void multiplexDigits(){ if(multiplexCount
-
Thread
UART empfängt nur 2 zeichen
4Taster gedrückt if(PINC & (1<<PINC0)){ //Btn 1 gedrückt _delay_ms(60); PORTC |= (1<<PORTC4); _delay_ms(60); PORTC &= ~(1<<PORTC4); sendByte[8] = 0x01; char *test = "1234567"; // rs485_putAddr(0x42); rs485_puts
test); //_delay_ms(100); } if(PINC & (1<<PINC1)){ //Btn 2 gedrückt PORTC |= (1<<PORTC5); _delay_ms(100); PORTC &= ~(1<<PORTC5); // sendByte[8] = 0x02; rs485_putAddr(0x42); rs485_puts(sendByte,sizeof(sendByte));
-
Thread
BASCOM: Byte Array an I2C RGB LED
/nicht geht oder es wird nie etwas. Wenn es mit von dir oben gepostetem Program geht (wenn auch falsch), dann *muss es mit meinem Program erst recht gehen* . Das einzige, was bei mir ev. geändert werden
und da geht es nicht weiter. Hast du einen Verdacht was es sein könnte? Adresse ist korrekt!
-
Thread
Suche E2PROM Manager für STM32F10x
PortA SCL pin RCC_AHB1PeriphClockCmd(I2C_PERIPH_SDA_PORT, ENABLE); // Enable clock für PortC SDA pin I2C_Cmd(I2C_CHANNEL, DISABLE); // I2C abschalten, damit Bus still bleibt // Port mit SCL einrichten GPIO_InitStruct.GPIO_Pin = I2C_SCL_PIN;
solche schlimmen Sachen wir das TWI zu benutzen. Beim Cortex eher Spass an der Sache, wissen wie es geht, Spass am Denksport, da ich beruflich schon lange keine HW und SW mehr entwickle. Danke Dir und Grüße, Christian
-
Thread
PIC-Register Verhalten
ANSELA clrf TRISA clrf PORTB clrf ANSELB clrf TRISB clrf PORTC clrf ANSELC clrf TRISC clrf PORTD clrf ANSELD clrf TRISD ;movlw 0xFF ;movwf PORTA ;movwf PORTB ;movwf PORTC ;movwf
movwf cnt1 movwf cnt2 movlb 0xFF incf PORTA,w ; <-- Um diese Zeile geht es movwf PORTA movwf PORTB movwf PORTC movwf PORTD dl decfsz cnt1 goto dl movlb 00 movlw 0xFF movwf cnt1 decfsz cnt2
-
Thread
Diamex ISP will nicht
unter Systemsteuerung/System/Hardware/Gerätemanger ob der Jungo Treiber installiert ist, ohne den gehts nicht.
angeschlossen. Jetzt konnte folgenden Code flashen [code] $regfile = "m328pdef.dat" Config Portc.5 = Output Do Portc.5 = 1 Waitms 800 Portc.5 = 0 Waitms 800 Loop End [/code] Jetzt blinkt meine LED aber nicht in einem 800ms Abstand (immerhin blinkt sie
-
Thread
BASCOM AVR Bedeutung
das gleichwertig? > > Wenn da jeweils ein Config vorsteht, ja. Anscheinend doch nicht. so gehts ------------------ Config PORTA = Output Config PORTC = Output Config PORTE.4 = Output Config PORTE.5 = Output Config PINB.5 = Input Set PORTE.4 Set PORTE.5 ----------
Probleme nicht nachvollziehen. Schick mal ein komplettes kompilierbares Programm. Und was bedeutet: geht nicht???
-
Thread
C++ RS232 Timeout-Problem ?
www.teuniz.net/RS-232/index.html Ich sende mit einem RS232-USB-Dongle zum Arduino Uno und von dort geht es parallel in einen Homecomputer (Commodore Plus/4). Das funktioniert einwandfrei mit Linux "cat". Das zu sendende Programm wird in ein Array geladen und dieses dann um einige Parameter für den Empfänger
sta (t_lo),y ; save lda #$40 sta portc ; set ack (pc6) asl sta portc ; and delete ack - lda portc cmp #$80
-
Thread
Funktionsaufruf aus naked-Routine
einer "naked"-Routine einen Funktionsaufruf zu starten? [code]ISR( PCINT2_vect, ISR_NAKED ){ PORTC = GPIOR1; isr_more_logic(); reti(); }[/code]
Schon das PORTC = GPIOR1 ist nicht "sicher", weil das nicht ohne Zuhilfenahme eines Registers funktioniert, welches wegen des naked ja nicht gesichert und wiederhergestellt wird.
-
Thread
Störungen auf einer RS485 Übertragung
ein schlechtes Gewissen, dass das Funktionierende plötzlich auf Grund von Störungen auch nicht mehr geht. Der ganze Aufbau soll mir schon dauerhaft zuverlässige Temperaturen für Raumklimasteuerung liefern. Die Signale auf dem Bus A/B habe ich mal mit Oszi angesehen. Könnte nichts negatives feststellen
Controllerboard gehen und beim anderen nicht. Auch mal erwähnt, bei dem Board bei welchem es nicht geht, ist Nagelneu aus Verpackung. Das welches geht, hat schon einige Tests hinter sich. Also müsste quasi ein Produktionsfehler vorliegen. (Auf ESD achte ich so gut als möglich.) Da ich schon mal deswegen
-
Thread
F1-Drehzahlanzeige selber programmieren
case 4: PORTC = 0b00001111; PORTD = 0b00000000; break; case 5: PORTC = 0b00011111; PORTD = 0b00000000; break; case 6: PORTC = 0b00111111; PORTD = 0b00000000; break; case 7: PORTC = 0b01111111; PORTD = 0b00000000; break; case 8: PORTC = 0b11111111; PORTD = 0b00000000; break; case 9: PORTC = 0b11111111; PORTD = 0b00000001; break;
-
Thread
xmega256A3BU USB-HID und Timer Problem
entweder USB-HID-Interface oder Timer Interrupt funktioniert aber sobald ich beides gleich zeit nutze geht es nicht. Für das HID-Interface nutze ich die Bibliothek aus dem ASF und hier ist vermute ich das Problem, da im sysclk_init alle Peripherie abgeschatet wird diese muss man expliziet dann jeweils
udc_start(); //clock_init(); //PLL_init(); init_timer2(); //interrupt_init(); PORTC.DIRSET = PIN7_bm; PORTCFG.CLKEVOUT = 0x01; // Ausgabe der CPU frequenz auf PC7 ulLaufzeit = 30000;//600000; PORTB.DIRSET = PIN2_bm; PORTB.DIRSET = PIN3_bm; while (1)
-
Thread
LCD (Funduino) ansteuern mit Bascom
Ausgang; Rest als Eingang Portd = &B10001111 'Eingänge auf high legen 'Config Portc.5 = Output 'zur Probe 'Config Portc.4 = Output Config Scl = Portc.5 'Konfigurieren von I2C Config Sda = Portc.4 Config Lcd = 16 * 2 'nicht unbedingt
LCD-Befehl umgesetzt! '****************** Initialisierung *********************** Config Scl = Portc.5 'Konfigurieren von I2C Config Sda = Portc.4 Config Lcd = 16 * 2 'nicht unbedingt nötig Config I2cdelay = 1 Initlcd Waitms 500
-
Thread
Programmable Waveform Generator
... und warum geht nicht https://www.hauptwerk.com/ mit einem MiniITX Mainboard oder (leistungsfähigem) Intel NUC? Ganz bestimmt unter 15kg ;-)
Beispiel: AD7524 an PORTD einer ATmega88PA, für Hüllkurve 6 bit-DAC mit Widerstandarray R-2R an PORTC (oder auch PWM, dafür reicht auch "normale" Fast-PWM ohne PLL). Kommunikation mit Steuereinheit per SPI (PORTB).
-
Thread
LED mit Schalter ein und ausschalten
Init_MCU(); While (1) { In=(~PINA&(1<<SWT1))==(1<<SWT1); If (IN) PortC|=(1<<LED1); Else Portc&=~(1<<LED1); } } Ich bekomme es aber nicht umgebaut, dass wenn ich eine Taste drücke der Zustand beibehalten wird. Ich habe versucht mit in Flanken und entprellen von Schalter einzulesen aber
t on = 0; while (1) { if ((~PINA & (1<<SWT1)) == (1<<SWT1) on = 1; if (on) PORTC |= (1 << LED1); else PORTC &= ~(1 << LED1); } [/c] Entprellen geht bspw. mit einem delay nach der 1. Messung der Pin-Zustände. Wenn dann nach dem delay der Zustand gleich ist, kannst
-
Thread
Wie bekomme ich LED am Controller völlig dunkel
verwendete Charlieplexing nicht, könnte mir aber vorstellen, das dein Problem in die gleiche Richtung geht.
hochohmig schaltet, sucht sich der Strom eben einen anderen Weg auch wenn der über eine andere LED geht. Vermutlich bekommt man das nur über ein Hystertese in den Griff.
-
Thread
Bitmanipulation beschleunigen
Vielleicht ist das bei moderneren besser gelöst: #define MOSI (1<<PCx) for(uint8_t m=128;m;DDRD&m?PORTC|=MOSI:(PORTC&=~MOSI),m=m/2); GCC checkt genau, was ich will, übersetzt es aber sehr umständlich, er nimmt einen 16-bit Schleifenzähler und zählt von 0000 bis 0008. [code] e2a: 90 e8
zumindest halb vergessen :-). Wichtiger ist die Erkenntnis, dass im Zweifelsfall (fast immer) noch was geht wenn es nötig wird.
-
Thread
stm32f103c8 lässt sic nich flashen
ST Visual programmer : http://www.st.com/en/development-tools/stvp-stm32.html Wenn der nicht geht, liegt es an der Hardware.
eine andere Datei aus dem Netz zu flashen, aber die muss natürlich compiliert sein. Der Quelltext geht da natürlich nicht, nie.
-
Thread
Einbinden eine Headerdatei schlägt fehl.
---------------------------------------- #ifndef HEADER_H_ #define HEADER_H_ #define PortLED PORTC #define PinLED PC5 #define DDRLED DDRC #endif /* HEADER_H_ */ --------------------------------------------------------------------------- Als Fehlermeldung bekomme ich: Warning
das Verzeichnis in dem der Header liegt auch in die Liste der Include-Verzeichnisse aufnehmen, dann geht auch <>, vor allem dann wenn es zwar ein eigener Header und kein Systemheader ist, dieser aber zur Übersichtlichkeit oder aus welchen Gründen auch immer in einem anderen Verzeichnis liegt.
-
Thread
Timer, Interrupt, Taster, C
minuten == 60){ minuten = 0; stunden++; } if(stunden == 12){ stunden = 0; } PORTC = minuten; PORTB = stunden; if(sekunden==0 || sekunden == 30){ PORTD ^= (1<<PD6); } PORTD ^= (1<<PD7); } int timer (void) { if(sekunden == 60) { minuten++; sekunden =
Interrupt), optimiert er da u.U. ungewollt Zugriffe weg. Typisches Symptom: mit -O0 (ohne Optimierung) geht es, mit Optimierung (egal ob auf Zeit oder Codegröße) geht es nicht mehr.
-
Thread
AVRCAN bekommt RX-Interrupt nicht mit
Einstellungen getestet, das zu Empfangenen Signal ist auf jeden Fall im Bus und sieht OK aus. Senden geht vom Controller aus wunderbar, der TX Interrupt feuert auch wenn man ihn aktiviert. Der RX Interrupt wird einfach nicht ausgelöst, Remote Requests Funktionieren auch nicht. Ich verwende eine leicht
PORTA = 0b00000000; DDRA = 0b00000000; PORTB = 0b00000000; DDRB = 0b00000000; PORTC = 0b00000000; DDRC = 0b00000000; PORTD = 0b00000000; DDRD = 0b00000100; PORTE = 0b00010000; DDRE = 0b00010000; //Led set as output (Bit4 = 1) PORTF = 0b00000000
-
Thread
Unklarheiten bei einem C Programm
Warum schreibt man denn PORTC = (0<<DDC0); anstelle PORTC = 0;
optimiert das weg. Aber der Schreiber / Leser des Codes kann so ausdrücken um welches Bit es ihm geht. Und genau diese hier so oft gescholtene, müffelige Zeile zeigt den Grund, warum das vorteilhaft ist: [c]PORTC = (0<<DDC0);[/c] So kann man schon beim Lesen des Codes erkennen, dass der Autor hier
-
Thread
Interrupt springt nicht in die Serviceroutine MKL26z128
extern void PORTC_PORTD_IRQHandler(void); #endif //__ISR_H [/c]
Register gesetzt? ganz fies: wenn der NMI PIN als GPIO angeschlossen und FOPT falsch gesetzt ist, geht gar nix.
-
Thread
Servo an Atmega328p funktioniert nicht
: > Config Adc = Single , Prescaler = Auto , Reference = Avcc > Config Portb = Output > Config Portc.0 = Output > Config Portc.1 = Output > Config Portc.2 = Output 2) Die Servos drehen sich jetzt nur noch um ca. 130°. Davor haben sie sich um volle 180° gedreht und mit der Hand geht es auch noch
poti 2 If Adcin2 < 40 Then 'LED's je nach Potistellung ein/aus Portc.0 = 1 Portc.1 = 0 Portc.2 = 0 Elseif Adcin2 < 984 Then Portc.2 = 0 Else Portc.0 = 0 Portc.1 = 0 Portc.2 = 1 End If Adcin2 = Adcin2
-
Thread
Atmega 2560 zu wenig Spannung am Ausgang
ATMega Pin: 59 Stiftleiste2:13 #define portIN2_13 PORTJ #define portIN1_13 PORTB #define portEN_13 PORTC #define portOCD_13 PORTC #define ddrIN2_13 DDRJ #define ddrIN1_13 DDRB #define ddrEN_13 DDRC #define ddrOCD_13 DDRC Und dann im main: portEN_13 |= (1<<EN_13); // Ich denke der Code ist in
PortC R.I.P.
-
Thread
Bits umtauschen (spiegeln)
und ich habe mein 16x10 LED Display vorgekramt. ATmega128 es werden 2x8Bit (PortA linke hälfte, PORTC rechte hälfte)) breit pro Zeile dargestellt und das alles 10x (PORTD mit 74HCT42 0-9 decodiert)nach unten widerholt.(PORTD=10->alles aus) Seinerzeit(tm) hatte ich das mit den Fastavr-"Compiler" (ähnlich
finde *hust*, stehe aber vor dem gleichen Hardwareproblem, denn hier hat sich ja nichts geändert. Geht das in C etwas eleganter zu lösen? Danke Axelr.
-
Thread
Externe .c bringt nur theater
links = HC_SR_04(); SERVO_RECHTS; _delay_ms(250); rechts = HC_SR_04(); PORTC = (1<<MOTORB_2) | (1<<MOTORA_2) | (1<<MOTORB_EN) | (1<<MOTORA_EN); MOTOR_PWM(10,10); _delay_ms(1000); PORTC = (0<<MOTORB_2) | (0<<MOTORA_2) | (1<<MOTORB_EN) | (1<<MOTORA_EN);
makefiles etc. - Backupfiles der Editoren vorher löschen) als ZIP zu posten. Einmal in der Variante die geht und einmal in der Variante die nicht geht. Dann kann das hier vielleicht jemand mal nachvollziehen - zumindest was das Compilieren und Linken angeht.
-
Thread
Interrupt Frage ATMEGA8535
0]; _delay_ms(1); PORTD = zaehlen[ZehnerM]; PORTC = driver[1]; _delay_ms(1); PORTD = zaehlen[EinerS]; PORTC = driver[2]; _delay_ms(1); PORTD = zaehlen[ZehnerS]; PORTC = driver[3]; _delay_ms(1); } return 0;
TIMSK |= (1<<OCIE1A); sei(); while (1) { PORTD = zaehlen[EinerM]; PORTC = driver[0]; _delay_us(100); PORTD = zaehlen[ZehnerM]; PORTC = driver[1]; _delay_us(100); PORTD = zaehlen[EinerS]; PORTC = driver[2]; _delay_us(100); PORTD =
-
Thread
Problem: 16 Bit Variable über UART zu empfangen
PORTD ^= (1<<PD2); _delay_us(100); PORTD ^= (1<<PD2); } void stop_conversion(void) { PORTC &= ~(1<<PC2); } void start_conversion(void) { PORTC |=(1<<PC2); } void reset_ADS1258(void) { PORTC &= ~(1<<PC0); _delay_us(100); PORTC |= (1<<PC0); _delay_ms(17); } void ADCInit
S. R. schrieb im Beitrag #4798101: > Ja. Das geht am einfachsten, indem du die Dezimalzahl ziffernweise als > Text überträgst und z.B. mit einem Endezeichen abschließt. Nope, am einfachsten geht das indem man die zwei Bytes überträgt und das ist
-
Thread
Neue 8-Bit Tinys vorgestellt: 417/814/816/817 Gesperrt
über UART z.B. geht dann > nicht mehr. Doch, geht sogar noch. PB1=ADC5, PB2/3 TX/RX sind just die 3 freien Pins. > programmiert ihr > den µC einmal und baut ihn dann erst in die Schaltung? Nicht so optimal bei
Jörg W. schrieb im Beitrag #4805028: > STlink an einem Atmel-Cortex-M Dass geht mit OpenOCD.
-
Thread
ATmega64: Zugriff DDR_ PORT_ in header files
LED programmiert welches einwandfrei funktioniert: [c] int main(void) { DDRC |= (1<<PC0); PORTC |= (1<<PC0); while (1) { _delay_ms(1000); PORTC ^=(1<<PC0); } } [/c] Versuche ich dieses Programm nun aufzuteilen in: [c] #include "IncFile1.h" int main(void) { void init() while (1) { _delay_ms(1000); PORTC ^=(1<<PC0); } } [/c] und [c] #ifndef INCFILE1_H_ #define INCFILE1_H_ #include <avr/io.h> #include <util/delay.h> void init() { DDRC |= (1<<PC0); PORTC |= (1<<PC0); }