-
Thread
Programmierung MSP430
einen Wechsel a-b oder b-c bzw. c-a soll auf dem Port 1 eines MSP430 ein Synchronisiersignal ausgegeben werden. Bei a-b: 0x10, b-c: 0x20, c-a: 0x40. Das Programm soll die Wechsel der obigen Sequenzen a,b,c möglichst schnell erkennen
Port konfigurieren P1DIR |= 0x10; //Ausgang für b-Signal P1DIR |= 0x20; //Ausgang für c-Signal P1DIR |= 0x40; //Ausgang für a-Signal P1DIR &=~BIT8; //S2 als Eingang (oder schreibweise: 0x08) P1REN |= BIT8; //Eingang als Pull_Up aktivieren
-
Thread
Unzuverlässigkeit von Antivirus am praktischen Beispiel
Aktueller Stand: 27 von 49. BitDefender und GData haben nachgezogen.
Meinst Du sowas? http://www.heise.de/security/meldung/Trojaner-nutzt-GPU-zur-BitCoin-Gewinnung-1324195.html
-
Thread
interrupt-reihenfolge und timingproblem für pic16fxxx
In diesem Fall wird 65536 zu anzahl0 addiert. zu INTCONbits.T0IF: Wie man bei deinem Compiler einzelne bits abfragt musst du wissen, mein Code ist für den C18
pic_ler schrieb im Beitrag #3548941: > Wie ich das Bit abfrage muß ich natürlich noch > rausfinden, aber ich weiß jetzt, was ich machen > muß. [c] if((INTCON&0b00000100)&&(timerwert < 30)) [/c] So sollte es ziemlich sicher funktionieren.
-
Thread
Konflikt? WDT + INT0 + SLEEP
) Zur weiteren Anfrage von PB2/INT0 muss der Pin natürlich als Input geschaltet werden 2) Die Abfrage des PB2 in der Schleife war falsch: Da muss natürlich das Bit in PINB und nicht in PORTB abgeglichen werden. Soweit läuft es jetzt also und der Vollständigkeit halber: [c] #include <avr/power.h
scan=0; // flag löschen sei(); // interrupts wieder aktivieren } [/c] cli() deaktiviert aber auch die Timer, die ich benötige. Deshalb dachte ich, dass ich den INT0-Interrupt und den Watchdog einzeln deaktivieren könnte. [c] //cli(); GIMSK &= ~(1<<INT0); // INT0
-
Thread
Heizungs-Datenerfassung (HT3)
auslesen, um im Web > den Status anzuzeigen oder müsste ich dafür auf die SQLite Datenbank > abfragen? Zur Zeit geht eine Abfrage einzelner Werte nicht und man muss die RAW-Daten selber dekodieren und den benötigten Wert rausfischen. Es ist jedoch ein Zusatzmodul in Arbeit welches genau dies realisiert
;) https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/.mqtt_setup.sh#L69 nicht ausgereicht hat.
-
Thread
Ein µC oder auf mehrere verteilen?
für die einzelnen µCs. Die Leiterbahnbreiten sollten passen. Habe grundsätzlich 0,5mm mehr breite genommen als "norm" also man sagt ja in der Regel 1mm pro A Leiterbahnbreite bei 35er Cu auflage. I2C Verbindung
auch Bosch hat zu 8 Bit Zeiten als die µC noch nicht soviele Timer-(funtkionen), ADCs... hatten mehrere µC auch auf mehreren Platinen verwendet. Auch von der Programmierung wirst du dich leichter tun wenn ein µC unabhängig
-
Thread
"Universelle Tastenabfrage" auf Attiny2313
Okay, leider durchsteige ich schon diese Zeile nicht: [c]TCCR0 = 1<<CS02^1<<CS00; // divide by 1024[/c] Ich verstehe, dass Bits in dem Timerregister TCCR0 gesetzt werden, aber was bedeutet CS02 und CS00 ?
mehr, mal ins Datenblatt zu schauen.. Im Datenblatt sieht es so aus, als wären die Clock Select Bits beim Atmega16 und Attiny2313 die gleichen. Ich habe jetzt [c]TCCR0 = 1<<CS02^1<<CS00; // divide by 1024[/c] gegen [c]TCCR0A = 1<<CS02^1<<CS00; // divide by 1024[/c] getauscht. Da kommt
-
Thread
Halben Port in "switch" auslesen
unzufrieden. Denn der springende Punkt ist: Du kannst einen Port immer nur als ganzes auslesen. Alle 8 Bit. Das ist so, weil in C die kleinste Einheit nun mal ein Byte ist. Aber: Es steht dir natürlich frei, von diesen 8 Bit diejenigen Bits, die du nicht benötigst, gezielt auf 0 zu setzen. Genau das machst
PORT hab ich nun auch raus... Mit PORT lese ich nur den Zustand des Pullups aus. Alles klar, also Abfrage auf PINB. Und zum dritten Punkt: Achso, ich verändere mit der Maske also nicht den Bereich den ich auslese, sondern ich verunde dann jedes einzelne Bit des Ports mit meiner "Maske"!
-
Thread
Ich suche einen "etwas anderen" C-Compiler Gesperrt
Peter II schrieb im Beitrag #3526328: > warum sollte das in C nicht genauso gehen? Weil C nicht korrekt auf den Taktzyklus genau eine 16-bit-Konstante auf den aktuellen unbekannten Timerwert aufaddieren kann, ohne daß es zu Fehlern kommt.
UART mit hoher Datenrate und eine selbst definierte synchrone serielle Schnittstelle) von einem 8-Bit-µC mittels priorisiertem Interrupt gleichzeitig bedient. Ich glaube nicht, dass ich es auch in C hinbekommen hätte.
-
Thread
Unterprogramme bei Signal sofort verlassen
wird aufgerufen Im Interrupt eine Variable setzen, und diese Variable dann in der Hauptschleife abfragen, und dann entsprechend verzweigen. Grüße
jemand helfen kann. Du programmierst so, wie man einen sog. "Programmablaufplan" macht. Wenn ein µC auf nix anderes zu achten hat und immer nur stur dieses zu tun hat, dann geht es ja so. Aber schon das Drücken eines Knopfes ist etwas, das den µC beim Abarbeiten deines Programmes eben aus der Bahn
-
Thread
DIP-Schalter an ATmega8515
desto trotz: Pins einzeln abfragen ist Basisfertigkeit. Das muss sitzen (mit einem großen MUSS)
wie kommst du auf die merkwürdige Idee, PD0 wäre eine /Variable/? Um den Zustand der Pins an Port C abzufragen, liest man das PINC Register. Und schaut dann, ob in diesem 8-Bit Wert (aka unsigned char) das Bit mit der Nummer PC0 gesetzt ist: [c] if (PINC & (1<<PC0)) { return 1; } else {
-
Thread
DMX empfang in C funktioniert nicht richtig.
Das [c] if(1<<FE) [/c] ist natürlich Quatsch. Denn dieser WErt ist immer wahr. Was du oin wirklichkeit wolltest. Du wolltest ein Register befragen, ob dort drinnen das bewusste FE Bit auf 1 ist oder
) [/c] sondern [c] if( PINB & ( 1 << PB0 ) ) [/c] also die Kombination aus: Nimm das Register PINB her und betrachte nur das Bit PB0 - ist das 0 oder 1? Und hier bei dir ist das nicht anders. Das
-
Thread
RFID Weitbereichsleser RS485 Arduino
Abfrage bekomme ich allerdings nur Quatsch und irgendwelche Zeichen aus dem erweiterten ASCII Code. ... das kann schon sein, es wird beim Empfang eben die 40 Bit jeweils als 5 Byte dargestellt, das können
Also verstehe ich es richtig, dass der Arduino selbst Start und Stop Bit erkennen müsste, sodass ich nur noch die fünf einzelnen Bytes voneinander trennen muss? Sprich ich selbst muss in der Software nicht mehr nach Start und Stopbit suchen? Aber dann stellt sich
-
Thread
µKontroller-Übertragung
die 8 bit in das uart-senderegister schieben und der rest macht dein µC, wenn du die UART richtig konfiguriert hast und das sollte im datenblatt stehen. und ansonsten zum 8051 sollte es einige beispiele geben zur benutzung der UART-schnittstelle in C bei deinem µC2 musst du die UART-schnittstelle konfigurieren und dann entweder ein bit pollen (ständig abfragen), ob was im empfangen wurde oder eben auch ein interrupt auslösen lassen, wenn die schnittstelle
-
Thread
20 PINs umschalten ?
gleichzeitig 1:1 Umschalten können. > > Und das gerne mit 4 Platinen. > > Genau geht es darum eine C64 Tastatur an 4 C64 anzuschliessen. Also die Steuerplatine (Tastatur) immer auf einen einzelnen C64, drei C64 bleiben jeweils unbeschaltet - richtig? Wenn Mechanisch reicht besorg dir bei Ebay
einem NMI auslöst. Das kannst Du mit > Arduinos umsetzen, aber die Tastatur mit einem AVR/Arduino abfragen und > den C64 eine andere Tastaturschnittstelle beibringen vereinfacht die > Umschaltung unheimlich. Klingt schon mal gut. Wie kann ich das verstehen 'dem C64 eine andere Tastaturschnittstelle
-
Thread
µC von 0 auf lernen. ASM oder C?
es anders aussehen, aber wer jetzt mit µC einsteigt, sollte es sowieso nicht mehr auf 8 bit tun.
Was ist denn an c schwer?! :-)) Ich habe die Firmware meines kompletten Quadrokopters in c geschrieben. Was habe ich hauptsächlich benötigt? - If-Abfragen - For-Schleifen - While-Schleifen - Case-Abfragen -
-
Thread
4 Stepper mit einem Arduino ansteuern
Indistrietechnik studierst, solltest du lernen als erstes immer nach Doku zu suchen. > , hier kommt C** du könntest wenigstens den Namen deiner Programmiersprache richtig schreiben. Die Sprache heißt C++ und nicht C** > und MC > ziemlich kurz bzw MC gar nicht vor ! Und? Was ändert das daran
> mit dem DUE Und ich wollte Dir schon Code für den ATmega328 nahelegen, weil Du immer mit 10 Bit Werten vom ADC gerechnet hast. Der ADC vom Due hat 12 Bit Auflösung, wenn ich das Datenblatt richtig lese.
-
Thread
LANC Implementierung
habe es gerade noch mal ohne Abfrage probiert: [c]while(1) { // Rec? PORTC = lanc[4]; }[/c] Da ich in genau diesem Byte entweder 0xEB oder 0xFB drinstehen habe, ergibt dies genau eine Änderung des 3. Bits
können auch c.a. 0,7V gewesen sein, auf dem Oszi ist das immer nicht so ganz genau ablesbar... Das mit den zwei Stopbits ist mir auch aufgefallen, sollte aber egal sein, da ich ja zwei einzeln getriggerte bytes sende
-
Thread
AVRStudio6.1 Compiler meckert (warnt) bei Struct-Pointer-Übergabe
du jedes einzelne C-File, jedes einzelne Header-File durch und fragst dich bei jedem #include 'Brauch ich den da drinnen?', 'Wird hier, in diesem File, irgendetwas verwendet, was diesen #include notwendig machen würde
, S0/1 den Speedmode des ADC und darauf für das CSV-Format mit Semikolon getrennt der 16Bit ADC-Wert und Timestamp kommen. Was ich also erwarte und in 50% der Fälle erhalte: z.B. [c] M0;C0;S0;113D;3131 [/c] Was ich bekomme (nach hier 11 Requests): [c]M0;C0;S0;113D;3131 M0;C0;S0;113E
-
Thread
8051 carryflag
; Wait Startwert = 1 ,1x 5ms dieser wird im timer 0 dekrementiert CLR C ; Carryflag wird gelöscht im Register PSW MOV A, R0 ; Werte von Port 2 werden in Akku geladen ANL A, #0Fh ; ---- FFFF : höherwertige bits von port 2 werden ausgeschaltet
Du hast übrigends auch einen Bufferoverflow, nämlich einen Stackoverflow: [c] read: ... CALL check ... check: ... JMP read [/c]
-
Thread
LTC2468 4CH 16BIT ADC - overrange indication - Beschaltung falsch?
durch die Abfrage des Temperaturwertes (die der LTC messen und ausgeben kann) - 22°C klang glaubhaft. Mein Problem ist nun: wenn ich die einzelnen Channel abfrage, bekomme ich nur eine over-range-indication und
to 0V, this bit is HIGH. If VIN < 0, this bit is LOW." MSB: B"it 20 (fourth output bit) is the most significant bit (MSB) of the result. This bit in conjunction with Bit 21 also provides underrange and overrange
-
Thread
Schwerpunkte in den Datenblättern
denn die SFRs von Timer, PWM, ... mit C zu tun? Das einzige, was du von C-Ebene dazu wissen musst -- dito für C++, Assembler, ist: - Wie wird ein SFR gelesen, geschrieben? - Wie setze / lösche / toggle ich einzelne Bits in einem Wert?
der zur Komponente gehörenden SFRs und Bedeutung der einzelnen Bits. Beim Lesen gehe ich dann in der Reigenfolge 1 - 3 - 2 vor. Lesen von 3 gibt schon mal einen sehr guten Überblick was die Komponente kann und wie diese tickt. Gory Details gibt es dann
-
Thread
CTC-Modus beim ATmega32 ?1us mit 10MHz?
[C] int zaehler [/C] [[FAQ#Was hat es mit volatile auf sich]]
Bit NICHT!
-
Thread
Anfänger sucht geeignete Hardware zur Zustandsschätzung eines Systems mit Hilfe von LUTs
Evaluationboards wie z.B. diese hier gedacht: http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_114_123&products_id=830 http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_47&products_id=631 Ich bin mir allerdings nicht sicher, ob diese Boards meine Anforderungen erfüllen.
ein Packet anfängt habe ich eben ein schönes Format ausgedacht. Bei mir sind das je Byte immer 7 Bits Nutzlast und 1 Bit um zu erkennen ob Packetstart oder nicht. Am PC kann man das dann total einfach mit C parsen und auswerten. Oder eben Labview hernehmen, das kann ja auch RS232 annehmen.
-
Thread
Midi Platine bauen
verdammt gut, oder er weiß nicht was er tut. Der Rest von uns (inklusive mir), setzt einfach einen einzelnen Prozessor ein und baut gegebenenfalls die Hardware drumherum mit 'klassischen' IC auf (also nicht µC-gesteuert)
value (note), silent velocity (0x00): noteOn(0x90, note, 0x00); delay(100); } } [/c] Warum schreiben immer alle [c] noteOn(0x90, note, 0x45); noteOn(0x90, note, 0x00); [/c] und nicht [c] noteOn(0x90, note, 0x45); noteOff(0x80, note, 0x00); [/c] beim
-
Thread
Zweidimensionales Array im EEPROM eines ATMEGA168A auslagern (nur lesen)
davon in ein einziges byte packen. Am besten schreibst du dir zwei Funktionen, mit denen du die einzelnen Bits komfortabel lesen und schreiben kannst. Stichwort dafür sind Bitoperationen.
Möglichkeit die "0" und "1" Werte platzsparender > als mit uint8_t zu speichern? Guck mal in deinem C-Grundlagen Buch nach "bit field"
-
Thread
pow() Flash-speichersparend ?
Yalu X. schrieb im Beitrag #3482377: > - Hat int auf deinem µC 16 Bit? Die Variablen sind tatsächlich so groß wie definiert, d.h. es findet bei 255 kein Überlauf statt. > > - Wenn ja, geht also der Wertebereich von x von -32768 bis +32767? Der Wertebereich
Helge schrieb im Beitrag #3482407: > Yalu X. schrieb: >> - Hat int auf deinem µC 16 Bit? > Die Variablen sind tatsächlich so groß wie definiert, d.h. es findet bei > 255 kein Überlauf statt. Das ist keine Antwort auf diese Frage. Was er wissen will ist sizeof(int), dass ist
-
Thread
Erfahrungen mit Oszi Rigol DS1074Z bzw. DS1104Z?
3158 (den > Wert habe ich im Header allerdings nicht gefunden). Beziehst du dich mit 3158 (0x0C56) auf den Adress-Offset in einer WFM Datei, ab welcher die eigentlichen 8Bit Samples gespeichert werden? Ciao, Rainer
R. W. schrieb im Beitrag #4203925: > Beziehst du dich mit 3158 (0x0C56) auf den Adress-Offset in einer WFM > Datei, ab welcher die eigentlichen 8Bit Samples gespeichert werden? Jain: Adress-Offset in meiner WFM-Datei von (nur) Kanal 2. Gefunden durch Vergleich mit
-
Thread
Auswahl des richtigen AVR -Controllers für einen Leistungsdimmer?
zwar solche Ausgänge besitzen aber oft mit unterschiedlichen Timer. Zum Beispiel Atmega8 hat ein 8-Bit PWM Ausgang (Timer 2) und zwei 16-Bit PWM Ausgänge (Timer 1). Ich denke, um so grÖßer der Wert (8-Bit 16-Bit usw..), desto längere und präzisere Zeitmessungen können mit Timer durchgeführt werden.
ist schnell implementiert und du bekommst eine große Anzahl an Kanälen und große Genauigkeit (10+ Bit) damit hin. Für einen Dimmer brauchst du aber i.A. keine 16 Bit, da reichen auch 8 Bit locker.
-
Thread
was spricht eigentlich gegen die xmega? Gesperrt
altes Modell, den würde ich heute bei einer neuen Schaltung nicht mehr einsetzen wollen. Ein 8-Bit AVR kann natürlich 16Bit verarbeiten. Wenn man damit allerdings in Assembler rechnen will, dann wird das etwas kniffliger, daher besser die Hochsprache C nehmen. Bei einem 16 oder 32Bit µC kann man
glatt übersehen. Das ist doch mist, da braucht man wieder einen Spannungsregler ( 12V => 5V = 16-Bit ADC => 3,3V = µC ). Bernd_Stein
-
Thread
Datensatz aus UART "gewinnen"
Abweichung. Die driftet dann auf PC > Seite irgendwann weg... Beim UART-Empfang werden mit jedem Start-Bit, i.e. für jedes einzelne Zeichen die Karten neu gemischt. Wie soll da irgendetwas irgendwann ins Driften kommen?
// Oups two '$' in one > record! > // TODO: Error Flag? > } > } > [/c] Hier hat sich leider ein Fehler eingeschlichen! :( Das wird so nicht klappen, die Abfrage sollte besser an anderer Stelle passieren.
-
Thread
DS18s20 Probleme mit Timer 8051
Also des ist en 16-Bit Timer : 2^16 = 65535 (mit 0 ) wenn ich zum Beispiel 755 uSekunden warten will muss ich rechnen : x = 65535-755 = 64780 in Hex: 0xFD0C " TH0 = 0xFD; " und " TL0= 0x0C; " daher die zeit =) soll
Interrupt 0 auf fallende Flanke konfiguriert. Die Priorität würde mit PX0=1; erhöht. Wenn (wie beim AT89C5131) 4 Prioritäts-Ebenen möglich sind, kann man das niederwertige Bit aus IPL0 einzeln setzen (Register ist Bitadressierbar). Die Bits in IPH0, IPL1 und IPH1 muss man über Maskierung setzen. Meiner
-
Thread
erst programmieren, dann schalten
benötigt somit nur - 1x Daten-Ausgang - 1x Clock - 1x Latchen und die Daten werden so seriell vom µC ausgegeben bis alle 104 Bits gesendet wurden und dann ein mal gelatcht und die 104 Ausgänge werden geschrieben.
send(schieberegister1) send(schieberegister2) ... LE=1 LE=0 }[/code] Ich würde in µC für jedes Schieberegister eine Variable erstellen, die mit 0 initialisiert wird und abhängig von der Schalterposition in diesen Variablen einzelne bits Setzen und löschen. Am ende jeden Schleifendurchlaufs
-
Thread
Erstes größeres Projekt - Multitasking Konzept
/attachment/111803/MdkM.c vorgeschlagen in einzelne Tasks mit jeweils einer State Machine pro task unterteilt. Standardmässig laufen diese im Zustand 'idle', der prüft, ob der dazugehörige Timer abgelaufen ist und wechselt dann
@ Jan K. (jan_k) >Darunter fällt das Abfragen des Sensors über SPI jede Millisekunde (875 >kHz SPI Takt, 4*16 Bit werden geholt). Dieser Prozess wird blockierend >betrieben, ich warte also bis die paar Bytes da sind. Ich dachte mir, >dass
-
Thread
LEDs mit Timer ansteuern
; // Die 2 Minuten laufen doch ab und dann leuchtet die LED oder? } } } } [/c]
Wenn mir jemand das in C schreibt, ich nerve nie wieder! Ich bitte euch aus tiefstem Herzen..
-
Thread
woher nehmt ihr boolean?
Macro zu definieren? > und zum anderen kann man dann auch mal die Variable > schnell auf FALSE abfragen. Konsequenterweise müsstest du dann aber auch folgendes schreiben: [c]Boolean flag = TRUE; if( (flag == FALSE) == TRUE ) ...[/c] Ein boolean typ is sicher hilfreich, aber *nicht* für Vergleiche
Namen gibt. Boolesche Funktionen haben oft den Präfix "is", wie bspw. in isPrime oder is_convex. Die Abfrage [c] if (isPrime(number)) ... [/c] liest sich dann fast schon wie Prosa, und ein zusätzliches ==true wäre doppelt gemoppelt und würde die Sache eher unübersichtlicher machen.
-
Thread
Processing Arduino Uart Lösungsfindung
mein Arduino Board? Ein Bit kann ich schon rüberschaufeln. Aber 3 Bits? Hat jmd eine Idee? Vielen Dank schonmal im vorraus.
-4-8 Als MOUSE TAG nehme ich das ENABLE DIR und MODE Als Int Value übergebe ich das High low bit. Somit kann ich mit einem Datensatz abfragen welches Bit wie gesetzt werden soll. Es funktioniert, aber irgendwie finde ich es immer noch nicht so elegant. Ich tüftel mal weiter.
-
Thread
Atmega168 ADC - Schwankungen/Beeinflussungen vom Nachbarpin
} uint16_t ADC_Read_Avg_10bit( uint8_t channel, uint8_t average) { uint16_t result = 0; for (uint8_t i = 0; i < average; ++i ) result += ADC_Read_10bit( channel ); return (uint16_t)( result / average ); } [/c
Unterdrückung von 50 und 100 Hz. Nebenbei kann man durch das Oversampling auch noch etwas (vielleicht 1-2 Bit) an Auflösung gewinnen.
-
Thread
EleLa - Elektronik Lagerverwaltung Entwicklung V3.0
bekam nur Unmengen von unveränderlichen "<Neuer Eintrag>". Meine Umgebung: Client: Windows 7, 64 Bit, tagesaktuell gepatcht, mysql-connector-c-6.1.5-win32 Server: MySQL V5.5.33 unter Linux
die DLL "libmysql.dll" Homepage von MySQL geladen werden: "http://dev.mysql.com/downloads/connector/c/" Falls der Link nicht mehr funktioniert: "http://dev.mysql.com/" >> Downloads >> Community >> MySQL Connectors >> Connector/C (libmysqlclient) Hier kann das Windows ZIP Archiv für 32 oder 64 Bit
-
Thread
[AVR][ATMega8]Problem mit PortB6 und PortB7 als Eingang an Schalter
defektes Bauteil auszuschließen. Zudem benutze ich einen Internen RC Oscillator und auch das AS2 Bit ist 0. Ansonsten würde auch überhaupt keine Eingabe angenommen werden. Ich habe den kritischen Code mal zusammengefasst: [c] //main --> Initialisierung des Controllers ASSR = (0 << AS2); /
Florian Schulze schrieb im Beitrag #3452160: > [c] > if(!PINB&0x80 && !PINB&0x40) // Mittelstellung --> beide Pins = 0 > [/c] > > Bei meinen Tests ist mir aufgefallen, dass die letzte if-Abfrage nie > TRUE wird, also nie beide Pins gleichzeitig
-
Thread
EMS > Adapter > NetIO > Raspi
0x13 ... [/code] Abfrage von 0x0C Bytes -> Antwort erfolgt //Niffko
wert!!! Daran lags. Problem ist: Bei mir läuft der AVR mit 20 MHz. Das hat in der Berechnung von BIT_TIME in ems_uart.c zu einem berechneten Wert von 260 geführt - ist natürlich zu viel für 8 Bit. Drum war bei mir der Break dann auch so kurz. Als Quick-und Dirty-Hack habe ich BIT_TIME halbiert
-
Thread
Micronucleus - USB-Bootloader für ATtiny
USB_INTR_CFG_CLR 0 */ /* #define USB_INTR_ENABLE GIMSK */ /* #define USB_INTR_ENABLE_BIT INT0 */ /* #define USB_INTR_PENDING GIFR */ /* #define USB_INTR_PENDING_BIT INTF0 */ /* #define USB_INTR_VECTOR INT0_vect */ [/c] Den Teil vom Code habt ihr gar nicht angefasst
GIMSK #define USB_INTR_ENABLE_BIT PCIE #define USB_INTR_PENDING GIFR #define USB_INTR_PENDING_BIT PCIF #define USB_INTR_VECTOR PCINT0_vect [/c] Daher halte ich dein Statement für ausgesprochen unglücklich
-
Thread
Hilfe bei Atmega32 Initialisierung
ADCSRA |= ( 1 << ADSC ); // nächste Messung starten } ... } [/c] verbraucht in Summe mit Sicherheit weniger Zeit, als dein ganzer Interrupt Klimbim samt Free-Running Modus und 3 Millionen globale Variablen und Flags. Abfragen musst du sowieso. Ob du jetzt eine Flag-Variable abfragst oder gleich das ADCSRA Register ist Jacke wie Hose. Edit: Nach genauerem Überlegen geht sogar die direkte ADCSRA Abfrage schneller als das globale Flag. Und zwar auf einem Mega32 deutlich schneller
-
Thread
Rundenzähler Carrera
dass du dich in der Behandlung des Reset-Tasters um die 7-Seg Anzeige kümmern musst, in dem du die einzelnen Bits ansteuerst. Deine loop sieht dann so aus [c] void loop() { Logik, welche diverse Eingangsleitungen überwacht uns auswertet. Als Ergebnis dieser Auswertungen verändert sich der
[C] // Um die Runden der Fahrzeuge zu zählen, bedarf es einer Abfrage am Startzielbogen // um dem Mikrocontroller mitzuteilen ob das Fahrzeuge durchgefahren ist oder nicht. // Die Kontrolle
-
Thread
VUSB - Device wird nicht erkannt.
/* 300 ms disconnect */ _delay_ms(10); } usbDeviceConnect(); DDRB |= 1 << BIT_LED; /* output for LED */ PORTB |= 1 << BIT_KEY; /* pull-up on key input */ PORTB |= 1 << BIT_ENC_DIR; /* pull-up on "key" input */ wdt_enable(WDTO_1S); timerInit(); init_encInt
/ nextDigit = NULL; } timerPoll();//Drucktaster des Encoders abfragen if(enc_changed) { evaluateENC(); enc_changed=0; }//oo } return 0; } [/c] Ich habe testweise nach "odDebugInit();" ein "_delay_ms()" mit verschiedenen Zeiten eingefügt. So, dass
-
Thread
7-Segment Anzeige 3-3tellig
(ich schalte nicht alle Anzeigen aus, sondern die letzte wirklich leuchtende) @Karl Heinz: Die Abfrage des State ist dazu da um führende Nullen nicht anzuzeigen... [c] d++; if(d == 30) { PORTD &= ~(1<<PNP_1); PORTB = Zahl[Hunderter]; if(is_state_km) //Geschwindigkeitsanzeige
sowieso nicht sein. Der Zeitunterschied zwischen einer if-then-else Leiter mit gezieltem CBI eines Bits und einem IN-AND-OUT Zyklus fällt dabei locker zugunsten Letzterm aus. Diese ganzen Teile [C] PORTB = Zahl[Hunderter]; [/c] ... also die Bestimmung des anzuzeigenden Musters, wenn die Ziffer
-
Thread
LEDs an PIC ausglimmen lassen
>> decfsz pwm,f ; Am Anfang ist es gut, diese Warnings eingeschaltet zu haben. Message[302] C:\MTC_3_T-336.ASM 115 : Register in operand not in bank 0. Ensure that bank bits are correct. Message[305] C:\MTC_3_T-336.ASM 151 : Using default destination of 1 (file). Wenn man dann ASM beherrscht
1<<0 => 1 , oder bit 0 ist on 1<<3 => 8 , oder bit 3 ist on INTCON = 1<<GIE|1<<T0IE ; -- INTCON = 0x84 -- oder 10000100b , also bit GIE und bit T0IE ist on, sprich die Zahl eins 7 mal nach links geschoben und 1<<T0IE