-
Thread
C Programm, kleine Frage
1 ) { switch ( state ) { case 0: if ( !counter0 ) { PORTB = 0x00; PORTC = 0x00; PORTD = 0x00; state = 1; counter0 = 1000; } break; case 1: if ( !counter0 ) { PORTB = 0x3F; PORTC = 0x3F; PORTD = 0xFF;
dieses Buch besorgen und die ganzen Tutorials lesen. Wenn ich die Hardware erst mal verstanden habe, geht das mit dem C auch leichter, davon bin ich überzeugt. Mit dem Programm oben experimentiere ich aber trotzdem noch rum *zwinker*
-
Thread
AVR ATMEGA328PB mit UART.h stürzt ab
define UART_BAUD_RATE 200000 //115200 #define RESET PC4 #define RESET_SLAVES {(PORTC |= (1 << RESET)); (DDRC |= (1 << RESET)); _delay_ms(100); (PORTC &= ~(1 << RESET)); _delay_ms(100);} #define T_TRIGGER_512 37499 #define T_TRIGGER_256 9374 #define DATA_FREQ_512
Beitrag #7304031: > Für so einen kleinen Controller ist es generell kein guter Stil Naja, was geht das geht .... bis es halt kracht.
-
Thread
LCD AVR C ROUTINEN
schreibst du das auch so rein [C] #define LCD_RS PB4 [/C] und deine Enable-Leitung vom LCD geht auf Pin PB5 [C] #define LCD_EN PB5 [/C] Ist doch nicht so schwer, oder?
na ja dafür,dass ich erst seit zwei Tagen dabei bin und es immerhin schon blinkt und läuft...geht doch oder??
-
Thread
Frage zum TWI
main (void) { DDRC |=(1 << PC5);//LED DDRB &=~(1 << PB1); //Taster while(1) { PORTC |=(1<<PC5); if((PINB & (1<<PB1))) { TWCR =| (1<<TWEN); } } } [/c]
Dshing Sung schrieb im Beitrag #2896054: > PORTC |=(1<<PC5); Hat evtl. der TWI was mit dem Pin C5 zu tun? Was steht denn dazu im Datenblatt? [pre] SCL/ADC5/PCINT13 – Port C, bit 5 SCL, 2-wire Serial Interface Clock: When the TWEN bit in TWCR
-
Thread
ATMega8 Reset bei SIGNAL()
uint_8t k; SIGNAL(SIG_INTERRUPT0) { k++; if (k==100) {k=0;} if (k<50) {sbi(PORTC,PC5);} else {cbi(PORTC,PC5);} } ... und in main(): ... sbi(DDRC,PC5); sbi(DDRC,PC4); sbi(MCUCR,ISC01); cbi(MCUCR,ISC00); enable_external_int (1<<INT0); asm volatile ("
liegen. Gleichzeitig mache ich folgendes: Nach dem Einschalten der Spannung lasse ich eine LED an PORTC4 im Hauptprogramm für ein paar Sekunden leuchten. Dann geht sie aus. Nein, dann soll sie ausgehen. Sie tut es nur, wenn ich "sei" rausnehme. Lasse ich das sei drin, leuchtet sie immer weiter. Allerdings
-
Thread
Gang(un)genauigkeit Quartz?
Hallo, es geht nochmal um meine Skizeitnahme. Hab ja schon vor ein paar Wochen mal angefragt wegen der Funkübertragung; die XBee-Module sind mittlerweile da und schauen recht vielversprechend aus. Jetzt geht
code] #include <avr/io.h> int main(void) { DDRC = 0xFF; long i; while(1) { PORTC = 0xFF; for (i=0;i<50;i++) asm("NOP"); PORTC = 0x00; for (i=0;i<950UL;i++) asm("NOP"); } } [/code] läuft. Die µC laufen mit Ext. Crystal Oscillator, 11.0592 MHz. Am Port
-
Thread
1Mbit I2C Eeprom - nur lesen möglich. Tomaten auf den Augen.
$framesize = 32 $swstack = 32 $hwstack = 32 $baud = 115200 $crystal = 20e6 Config 1wire = Portc.7 $lib "i2c_twi.lbx" Config Scl = Portc.0 'Ports fuer IIC-Bus Config Sda = Portc.1 Config Twi = 100000 ' Takt 100kHz
Alles klar, jetzt gehts. Hab mir schon gedacht, dass ich da irgendwo was übersehen habe.
-
Thread
TIMER in C, AVR, Hilfe! danke!
; } else { PORTB |= (1<<0); } if(bit_is_clear (PINB,2)) { PORTC &=~(1<<0); } } }
ISR wurde in der Zwischenzeit weit genug hochgezählt und du schaltest die LED ein. Gut. Aber wie gehts weiter? Nach Abarbeitung der ISR gehts an der Stelle im Hauptprogramm weiter, an der unterbrochen wurde. Und es kommt wie es kommen muss: die Hauptschleife kommt irgendwann zur bewussten Abfrage ob
-
Thread
Stoppuhr Code Optimierung
= (1<<CS10); //Timer 1 TIMSK |= (1<<TOIE1); sei(); //Freigabe der Interrupts PORTC |= 0x1C; PORTD |= ~0xFB; while (1) { } } ISR(TIMER1_OVF_vect) { if (x2 == 1) { x1++; } if (x2 == 0) { x1 = 0; } if (x1 == 15/6) //Für
var = 0; digit++; if (digit > 4) { digit = 1; } } PORTC |= 0x1E; PORTC &= ~(1 << digit); PORTD = damn[counts[digit - 1]]; } ISR(INT0_vect) { PORTB ^= (1<<PB0); //Debug LED x2++; if (x2 == 2) { x2 = 0; } if (x2 == 1)
-
Thread
Problem beim Konfigurieren von EUSART PIC18 Assembler
Das Programm Funktioniert bis jetzt wie folgt. Wenn ich eine Taste auf der Tastatur drücke, dann geht die LED an. Drücke ich nochmal drauf passiert nichts. Die LED bleibt jetzt immer an. Hat jemand eine Idee, was da mit dem QT nicht stimmt? Mit freundlichen Grüßen David
ANSELB; Set all pins to digital output MOVLW 0x00 MOVWF ANSELB ; Configuration of PORTC CLRF PORTC ; Clear PORTC MOVLW 0x00 MOVWF PORTC CLRF TRISC ; Set all pins to output MOVLW 0xF0 MOVWF TRISC CLRF ANSELC; Set all pins to digital output MOVLW 0x30
-
Thread
schnelles SPI für ATXMEGA 256
Nun kommt mein Problem: Wenn ich die SPI Geschwindigkeit so konfiguriere, das es schneller geht als 2 Mhz gehen regelmäßig Bytes verloren. Dies beobachte ich mit Hilfe des AARDVARK(Beagle) SPI/I2C Protocol Analyzer von Totalphase.com . Hat jemand eine Idee, wie ich SPI Datenpakete schneller
ist die Nettorate etwas niedriger, da der XMega jedes Byte nachladen muss. Oder Du nimmst DMA, dann geht´s schneller.
-
Thread
ATtiny8 und GIMSK
Hallo Dieter bin da von ausgegangen, wenn kein PCIE geht auch kein Interrupt geht. Das hatte ich dabei nicht berücksichtigt bzw. bin noch nicht so weit gekommen. Freue mich mehr, wenn das obere von mir stimmt. Da ja kein Wiederspruch kommt, nehme ich an,
Achim Seeger schrieb im Beitrag #3872826: > bin da von ausgegangen, wenn kein PCIE geht auch kein Interrupt geht. Wie kommst Du darauf, dass es für PC7 kein PCIE.. gibt? Es ist der gleiche wie für PC2. Der Interrupt wird immer für eine Gruppe von Pins aktiviert, welche Du im Einzelnen
-
Thread
Bascom Code
m128def.dat" $baud = 9600 $crystal = 14300000 Config Portc = Input Config Porta = Output Do If Portc.1 = 1 Then Porta.0 = 0 Print "0" Elseif Portc.1 = 0 Then Porta.0 = 1 Print "1" Else Print "nix" End
Vielen dank jetzt gehts. Das Print war nür für mich als Ausgabe gedacht so das ich über ein Terminal Programm am COM Port was sehe. Tom
-
Thread
DMX-Transmitter Code von Henne’s Sites ändern
> Dieser kann aber auf 1% und besser kalibriert werden, was ja > ausreichend genau ist. Wie geht das? Kann mir jemand folgenden Befehl erklären: [c]DmxField[0]= ~(PINC);[/c]
vollständig macht) immer zunächst ein Break gesendet (damit die diversen Empfänger wissen, jetzt gehts los, quasi ein Synchronzeichen) und dann 512 Bytes (ein sog. "Universum") und dann gehts von vorne wieder los. Den Break kann man übrigens als "dirty trick" auch dadurch erzeugen, indem man zunächst
-
Thread
ATMEGA8 --> I2C
Ich gehe jetzt mal davon aus, dass das BASCOM AVR jetzt für mich regelt. Ich habe Config Scl = Portc.5 Config Sda = Portc.4 definiert. Was mir jetzt auffällt, dass Portd.1 die ganze Zeit auf high ist. Meine angeschlossene LED leuchtet die ganze Zeit. Muss ich unter BASCOM noch irgendwie sagen
Baustein von 00:00 Uhr losläuft. Mhh, eigenartig. Die Schaltung muss richtig sein, denn auslesen geht ja. Wenn noch jemand eine Idee für mich hat...
-
Thread
Maskieren modern?
Name angesprochen. Damit kann man nicht die falschen Bits im falschen > Register ansprechen. Ok,geht also nicht in C
schrieb im Beitrag #7379805: >> Ich möchte einfach, dass ein Unsinn wie >> ... nicht kompiliert. > Geht leider nicht. Das gilt eben nur für C, in C++ geht es.
-
Thread
Tasten entprellen - Bulletproof
ct1 & ~ct0 & i; key_state ^= i; Habe den Programmcode durch den Simulator laufen lassen: -> geht! Andi
Kann es sein, dass nach dem Reset, nach 4 Timer-zyklen key_press einmal auf 255 geht ? Ich hab hier nämlich das phänomen...
-
Thread
Taster mit mehreren Funktionen
{ DDRB=0xff; DDRC=0x00; PORTB=0x00; PORTC=0x00; unsigned int x; while(1){ if ( PINC &(1<<PC0)) { PORTB=0x00; } if ( PINC &(1<<PC0)) { PORTB=0xff; } if (
Mit "PORTC=0x00" aktiviest du doch pulldown. D. h. wenn der Taster nicht gedrückt ist, liegt eine Null am Eingang... Mit "if (PINC &(1<<PC0))" fragst du ab ob der Pin auf 1 (Versorgungsspannung) gezogen wurde
-
Thread
Lerne LCD zu programmieren
meldet mir in der lcdsetup.h eine falsche Deklaration vor "x". Wenn ich die Variable als int verwende geht es. Nach Übertragung in den Atmega8 funktioniert das Ganze aber gar nicht. Es erscheint immer ein schwarzer Balken im Display. Aber nur einer, Textausgabe habe ich auch schon versucht, geht aber auch
#define LCD_PORT PORTC #define LCD_DDR DDRC #define LCD_RS PB4 #define LCD_EN PB5 Geht mit dem Code nicht. Muss alles an PORTC.
-
Thread
Problem mit SPI Flash AT45DB321D
into buffer, sends the data*/ UDR0 = data; } int main(void) { //5 Leds DDRC = 0xff; PORTC = 0x00; SPI_MasterInit(); USART_Init(8); //16Mhz, Baud: 115200 char msg[] = {"Hello... Ready!"}; for(uint8_t i=0;i<15;i++) { USART_Transmit(msg[i]); } PORTC =
. Und was ich auch gerade noch festgestellt habe ist, dass anscheint der FLASH_CS niemals auf LOW geht, obwohl er das eigentlich müsste. MfG Philipp
-
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
ATMega644 & EA-DOGL128 Kommunikation
direkt von der 12V Spannungsversorgung der das ganze auf 3,3V regelt. Die Schaltung steht bereits, mir geht es eigentlich um die kommunikation zwischen mC und Display Programmtechnisch. So damit ich meinen eigenen Takt irgentwie vorgebe und darauf mein SCL anlegen kann. Was die absteigende und ansteigende
(BIT_SI)|BIT(BIT_SCL)); PORTD&=BITN(BIT_SCL); PORTD|=BIT(BIT_CS); DDRC|=BIT(BIT_RST); PORTC|=BIT(BIT_RST); // hier ggf Delay PORTC&=BITN(BIT_RST); // hier ggf Delay PORTC|=BIT(BIT_RST); // hier ggf Delay } void lcd_ctrl_init(void) { LCD_CS_LO(); LCD_A0_LO(); lcd_sendbyte
-
Thread
Loxone Link - CAN-Bus
else { if (((b2 & (1 << (i - 8))) >> (i - 8)) == 1) PORTC |= (1 << (i-8)); else PORTC &= ~(1 << (i-8)); } } } } } } } [/code] Der Code ist noch nicht vollständig
Ja genau, es geht in dem Repo um Loxone Hardware die über den LoxLink oder TreeBus verbunden ist. ich wüsste auch nicht warum man reale Hardware kaufen sollte um dann den Miniserver zu Simulieren. Darum geht es auch
-
Thread
Stack Monitor Disabled ????
out DDRD, temp ; PORTD configured for Ausgang ;ldi temp, 0xFF ;out DDRC, temp ; PORTC configured for output ;ldi temp, 0xFF ;out PORTC, temp ; LEDs ausschalten ldi temp,0b00000000 ; steigende Flanke out MCUCR, temp ldi temp,0b01000000 ; INT0 und INT1 aktivieren
das stimmt wohl. Ich kann mir den unterschied zwischen rcall und rjmp nicht erklären. hnlich geht es mir auch mit dem reti und ret, huerbei ist auch das Problem an welcher Stelle ich éinen dieser beiden Befehle einzetzten soll. Ich hab zwar schon in einem Buch daüber gelesen, dort ist es aber
-
Thread
gemessene Frequenz mit UART verschicken
[c] zw_Erg = ((overflow * 65536) + ic_zp_B - ic_zp_A); // Overflow berücksichtigen [/c] Das geht schief. Zwar nur bei bestimmten Frequenzen, dann aber gründlich. Du mußt zu jedem Capture den Overflowzähler speichern und erstmal feststellen, ob er vor oder hinter dem Capture kam. Sonst hast
@ Karl Heinz: das sieht ganz gut aus. Die Zeitdauer fürs Empfangen geht nicht über die 1ms drüber, wenn man das so messen kann?: am Empfänger: PORTC |= (1<<PC6); a = uart_getc(); PORTC &= ~(1<<PC6); und dann am Oszi den Pin anschauen. @ Wolfram: das mit dem
-
Thread
Verwaltung von Pins und Peripherie global oder lokal
eine Änderung und keine externen Listen (brrr das ist sowieso so eine Idee aus der Hölle). Das geht auch, wenn ein Modul die Zuweisungen nur über #defines bekommt. gruß cyblord
_PORT PORTC #define SPARE1 PC2 #define SPARE1_PIN PINC #define SPARE1_DDR DDRC #define SPARE1_PORT PORTC #define SPARE2 PD7 #define SPARE2_PIN PIND #define SPARE2_DDR DDRD #define SPARE2_PORT PORTD
-
Thread
Linux MPLABX XC8 usart.h nicht gefunden/vorhanden
finden. Das manuelle Durchsuchen von /opt/microchip (und aller Unterordner) brachte keine Ergebnisse. Geht das nur mir so oder fehlt die Bibliothek tatsächlich?
#pragma config WDTEN = OFF #pragma config WDTPS = 32768 // CONFIG3H #pragma config CCP2MX = PORTC1 #pragma config PBADEN = ON #pragma config CCP3MX = PORTB5 #pragma config HFOFST = OFF #pragma config T3CMX = PORTC0 #pragma config P2BMX = PORTD2 #pragma config MCLRE = EXTMCLR // CONFIG4L
-
Thread
PWM liefert dauerhaft 2.5 Volt?
<avr/interrupt.h> int main(void){ DDRC &= ~(1 << PC5); // PC5 als Eingang festlegen PORTC |= (1 << PC5); // Pullup für PC5 aktivieren DDRC &= ~(1 << PC4); // PC4 als Eingang festlegen PORTC |= (1 << PC4); // Pullup für PC4 aktivieren //Hardware-PWM initialisieren DDRB
Wenn du die Tasten etwas länger drückst, dann ist die LED ganz hell oder ganz aus. Mit kurz antippen geht es stufenweise.
-
Thread
DAC Schieberegister
Code noch nicht richtig liege. #include <avr/io.h> #include <util/delay.h> #define DAC_PORT PORTC #define DAC_LOAD 1 #define DAC_CLOCK 0 void dac_data(unsigned char temp1); void dac_enable(void); void dac_data(unsigned char temp1) { unsigned char temp2 = temp1; DAC_PORT |=
Hinweis: selbst wenn du das SS-Pin nicht, benutzt sollte es als Ausgang geschaltet sein. Ansonsten geht die SPI nach der Übertragung in den Slave-Modus MfG Spess
-
Thread
Warum verwendet WinAVR nie swap/mul ?
einschlägigen Mailinglisten mal verfolgt (die meisten ernsthaften Entwickler meiden Webforen, wo's nur geht, weil sie im Vergleich zu Mailinglisten oder Newsgruppen eigentlich nur Nachteile haben), kann man z. B. sehen, dass Björn Haase gerade einiges gemacht hat. > Was mich auch wundert ist, daß bei
wie weit reicht der support dafür??? ;) ich steh einfach auf oop.. und bei 128k flash und 64k ram geht das doch ohne probs ;) 73
-
Thread
Dumme? Frage zum Präprozessor
, dass sie im Nicht-Debug-Code zu rein gar nichts evaluieren. Das ging im C90 gar nicht. Im C99 geht es als: [c] #if DEBUG # define DPRINTF(...) fprintf(stderr, __VA_ARGS__) #else # define DPRINTF(...) /* nothing */ #endif [/c]
Das müßte portabel sein (geht zumindest auch mit Codevision): [c]/* Code to manipulate PORTx, PINx, and DDRx using definitions like those above */ #define PORT(port,pin) (PORT##port) #define DDR(port,pin) (DDR##port
-
Thread
Allgemeines Toggle LED Problem
Woran liegt das? Beispiel Programm:[c] if(adcval < 140) // Kleiner 684mV { PORTC |= (1<<PC0); PORTC &= ~(1<<PC1); PORTC &= ~(1<<PC2); } [/c] funktioniert natürlich, aber [c] if(adcval < 140) // Kleiner 684mV { PORTC
(1<< PD5); if(counter%7==6) PORTD ^= (1<< PD6); [/c] funktioniert nicht einwandfrei. Mal geht direkt eine LED An und Aus anstelle nur An oder wenn sie ausgehen müsste, verliert sie nur die halbe Ausgangsspannung. Die LEDs haben jeweils 1k Ohm als Vorwiderstand. [c] DDRB = 0xFF; // Blaue
-
Thread
Kommunikations FPGA<-PIC: Fehlerhafte Erkennung der Daten
delay_ms(500); if(portc.2==1) //Wenn shake=1, sende Daten { portd=0x01; //Sende Daten delay_ms(500); portb=0x0; //setze Hand-Signale wieder auf 0 } } [/c] EDIT: Nur, dass du mich nicht falsch
auf Datenbus portb=0x01; // Setze Bits auf Kombination für send:Adresse "01" (Hand-Signal) portc.2 = 1; // Datenübergabe delay_us(10); portc.2 = 1; [/c] Und auf der FPGA-Seite: [vhdl] Use IEEE.Std_Logic_1164.All; Use IEEE.Numeric_Std.All; entity uCread_topModule is Port ( clock
-
Thread
Timer/Counter0 Overflow Interrupt kommt nicht
PORTA = 0x00; DDRB = (1<<PB3) | (1<<PB4); DDRD = (1<<PD6) | (1<<PD7); DDRC = 0xFF; PORTC = 0x00; PORTC |= (1<<PC1); // Timer0: Enable Phase correct PWM(non-inverted), prescaler = 8 TCCR0A = (1<<WGM02) | (0<<WGM01) | (1<<WGM00) | (1<< COM0A1) | (0<< COM0A0); TCCR0B
bei 249 bist. Im nächsten Schritt werden wieder 10 addiert, dann bist du bei 3 (259 - 256), es geht weiter mit 13, 23, …, 253. Diese if-Bedingung greift nur sowas von selten, dass du sie genauso gut komplett weglassen kannst.
-
Thread
I2C Problem (Peter Fleury) Adressierung?
rn Control. Habe das Sensorboard an Port C Hängen. Die Ports aktiviere ich so: DDRC =0xFF; PORTC = 0xFF; Danke für die Hilfe!
. Hab das gerade mal bei meinem Selbstbau getestet. Sobald ich die LEDs an den Pins dran mache geht meine I2C Verbindung auch nicht. Mach die mal ab und teste nochmal.
-
Thread
AVR-ctrl Demoprogramm fehler?
> DDRA = 0xff; Das setzt die Pins auf Eingang. Ausgang geht so: DDRA = 0x00;
0xff; PORTA = 0b11111111; DDRB = 0xff; PORTB = 0b11111111; DDRC = 0xff; PORTC = 0b11111111; DDRD = 0xff; PORTD = 0b11111111; } }
-
Thread
t6963c.h von Mega32 auf AtMega644p
Übersetzt du das Programm auch für einen ATMega644p neu? Oder nimmst du dieselbe HEX-Datei? Das geht nicht.
jtag fuse ?? portC is jtag
-
Thread
wie 2 Timer gleichzeitig auf ATMega8
augenscheinliche Anfängerfrage) Je 100nF zwischen Vcc und GND bzw. AVcc und GND. So nah dran wie geht. mfg.
Kann es sein, dass Du AVcc und AGND nicht angeschlossen hast? Das würde zumindest erklären, warum PortC spinnt. ...
-
Thread
Nach Interrupt-Routine lange Pause!?
Also ich frage im HP Bitzustände am PORTC ab und gebe dementsprechend Meldungen auf einem LCD aus. Der Hardwareinterrupt wird durch ein Funksignal ausgelöst. Dadurch wird dann ein Bit an PORTx auf High gesetzt und eine Meldung am LCD erscheint
Was anderes kanns eigentlich nicht sein. Ein Interrupt is schneller als die Polizei erlaubt...der geht keine Minute.
-
Thread
Atmega UART1 Pins
m64def.dat" $crystal = 8000000 $baud = 9600 Config Porta = Output Config Portb = Output Config Portc = Output Config Portd = Output Config Porte = Output Config Portf = Output Config Portg = Output Do Porta = 0 Portb = 0 Portc = 0 Portd = 0 Porte = 0 Portf = 0 Portg = 0 Wait
Irgendwo ist der Wurm drin, es geht auch im 103 Modus nicht MfG
-
Thread
C komisches Verhalten
Simon Budig schrieb im Beitrag #3119288: > Das riecht nach WS2811/WS2812? Genau darum geht es ;) Hier mal der Code der L_High Funktion: void L_High() { PORTC |= 0b00000001; asm volatile ("nop"); asm volatile ("nop"); asm volatile ("nop"); asm volatile ("nop"); PORTC
Die Datenausgabe würde dann über diesen HET laufen. Helfender schrieb im Beitrag #3119421: > Geht es vielleicht mit SPI? Nein geht nicht, da man bei SPI den Dutycycle nicht manipulieren kann.
-
Thread
Tasterschaltung in AVR
leuchtet auf. Du lässt die Taste los und nichts weiter passiert. Drückst du erneut auf die Taste so geht die LED wieder aus. Lässt du los passiert nichts weiter. Der erste Fall ist der einfachere. Man muss dort auch nichts entprellen [C] int main() { .... while( 1 ) { if( !( PORTB
//Ausgang definieren (LED) DDRC &= ~_BV(PC0); //Eingang definieren (Taster) PORTC|= _BV(PC0); //internen Pull-Up-Widerstand einschalten while(1){ if (bit_is_clear(PINC,0)) {PORTD &=~_BV(PD0);} //LED an else {PORTD |=
-
Thread
LCD mit NT3881D
auf die Sprünge helfen kann...: Aaaalso, was ich habe: ich benutze einen ATMega32. An seinem PortC hängt ein LCD, was im 4-bit-Mode angesteuert werden soll. Die technichen Details sind in den Datenblättern im Anhang zu finden. Das LCD ist von Optrex und vom Typ C-51847 NFQJ-LG-ACN. Laut dem DB
ja, also aus dem datenblatt geht leider nicht so viel hervor, aber ich habe natürlich am anfang, beovor ich mit messwerten gearbeitet habe und so, testanzeigen gemacht. das hat mit den routinen aus der lcd-routines.c super geklappt
-
Thread
Problem mit ATMega16
generieren VCC über 100 Ohm zum Portpin vom Pin mit 10k gegen Masse. Entprellt muessen die nicht sein, geht ja nur um an oder aus. LED will aber nicht ausgehen. Weiss da jemand Rat? Vielen Dank Daniel
ja die sind noch dran, hab hier keine Loetkolben. aber geht ja auch mit wenn ich das mit dem Pull Up beachte.
-
Thread
AVR Studio 5/Debug: No Source Available
util/delay.h> int main(void) { DDRC = 0xFF; // Alle auf Ausgang while(1) { PORTC = 0x00; _delay_ms(1000); PORTC = 0xFF; _delay_ms(1000); } } Wenn ich das nun debugge, erscheint eine neuer Tab, darin steht: "No disassembly available" Die Meldung "No
erscheint der disassemblierte Code im Tab. Wenn ich dann mehrmals F10 drücke sehe ich, der gelbe Pfeil geht immer tiefer, scheint etwas auszuführen. Dann irgendwann erscheint 'Disassembly cannot be displayed in run mode". Ich krieg es einfach nicht hin, diesen einfachen Code zu debuggen. Kann mir jemand
-
Thread
SPI macht Reset
1 << SPE) |(0 << DORD) | (1 << CPOL) | (1 << CPHA) | (1 << SPR1) | (1 << SPR0); SPDR = 0xFF; PORTC = 0xff; } void main(void) { DDRC = 0xff; PORTC = 0xff; SPI_MasterInit(); //Initialisieren und PORTC Ausgänge auf High setzen //sei(); // Sei() freischalten while(1) { /
Reset geht nicht nur durch den entsprechenden Pin. Auch durch Sprung nach 0, Watchdog, Spannungseinbruch (z.B. durch Pin-Kurzschluss), ... Wirf beim Start mal einen Blick ins MCUCR/MCUCSR. Da steht der Grund
-
Thread
wieder mal die pointer.
kontrolliert man zb mit HTerm noch ob sie auf PC Seite noch korrekt ankommen. Wenn sie das tun, dann gehts weiter im Debugger auf dem PC bis man bei der Ausgabe angelangt ist.
float_bytes_t foo; foo.f_val = 1.0f; PORTA = foo.bytes[3]; PORTB = foo.bytes[2]; PORTC = foo.bytes[1]; PORTD = foo.bytes[0]; while(1) { asm volatile("nop"); } } [/c] Ergebnis: PORTA = 0x3F PORTB = 0x80 PORTC = 0x00 PORTD = 0x00
-
Thread
AVR bootloader Probleme
nur ein Compilerproblem sein, wenn alle Einstellungen + Programm identisch sind und es beim einen geht, beim anderen nicht, ... ?
Auslesen des Tabelleneintrags wird nur ein lpm verwendet (kein elpm/RAMPZ). Bei einem Bootloader geht das auf Grund seiner besonderen Adresslage in die Hose und es kracht. Ich würde es mit -fno-jump-tables versuchen.
-
Thread
Brauche dringend Hilfe! Gesperrt
Also bei dem Betreff des Threads wusste ich sofort um was es geht!
Da gibt es gleich 5 Threads. Hättest Du da nicht einfach in einem weiter schreiben können, denn es geht hier ja offensichtlich um das gleiche Thema.