-
Thread
Verilog for Schleife
schrieb im Beitrag #2739001: > geht es dort Nein, es gibt kein solches Bauteil: ein RAM, das ALLE Bits einzeln an eine Leitung heruasgeführt hätte. Oder doch ja: indem jedes Bit einzeln ein "richtiges" Flipflop einer Logikzelle auffrisst... :-o
Lothar Miller schrieb im Beitrag #2739085: > Nein, es gibt kein solches Bauteil: ein RAM, das ALLE Bits einzeln an > eine Leitung heruasgeführt hätte. > Oder doch ja: indem jedes Bit einzeln ein "richtiges" Flipflop einer > Logikzelle auffrisst... :-o Hat ja auch keiner was von 'nem RAM erzählt
-
Thread
Kommunikation zwischen zwei Mikrocontrollern. welches Protokoll?
hätte, hätte ich das mit CAN realisiert, aber das hätte einen weiteren Baustein erfordert, während I2C im uC schon drin war. Heute würde ich das gleiche mit UDP machen. I2C hat gut funktioniert, wir haben die Controller im 10bit Modus und mit relativ hoher Geschwindigkeit adressiert. Ich glaube aber
Protokoll eignet sich da am besten? > In Hardware könnte ich z.B. nutzen: > > USART > SPI > I2C/TWI > oder etwas eigenes > Es ist ein AVR-Controller. Wenn es einfach gehen sollte und wenn nicht ascii sondern Bytes zu übertragen sind, dann scheint mir USART in 9-bit-Mode am besten. 9. Bit kann
-
Thread
BMP180 I2C Problem?
Karl Heinz schrieb im Beitrag #4041973: > [c] > s16 bmp180_get_temperature(u32 v_uncomp_temperature_u32) > { > [/c] dafür ist der Eingangswert wieder ein unsigned mit 32 Bit, der von 16 Bit vom Sensor stammmt.
[c] v_x1_s32 = (((s32) v_uncomp_temperature_u32 - [/c] wieder auf einen signed mit 32 Bit umgecastet wird :-) Ganz ehrlich: Ruhmesblatt ist das alles nicht.
-
Thread
T6963C-Display flackert
daher mehrere Adressen beschreiben (z.B. 2 untereinander). Damit die einzelnen Zeichen nicht immer erst bei den nächsten 8 Bit einer Zeile beginnen, ver-odere ich die einzelnen Zeichen. Die einzelnen Zeichen werden in einer Funktion beschrieben. Damit das vorige Zeichen nicht
1. Wie ist dein Code geschrieben bzgl. der Abfrage des Statusworts des T6963C? Mit TimeOut oder richtige Abfrage vom Status? 2. Hat das Winstar einen kleineren RAM? 3. Sind die Konfigurationspins des T6963C richtig beschalten? Ralf
-
Thread
Timer0 mit abfallender Flanke
} else { counter = 0 ATOMIC_BLOCK(ATOMIC_FORCEON) { // 16-Bit Zuweisung ist nicht atomar deshalb ATOMIC_BLOCK counter = 0; } } } } } [/C] Wenn das zufriedenstellend läuft kannst du den while-Anweisungsblock in die ISR reinziehen
nichts. Du kannst nicht mehr den ganzen Port einfach so umstellen. Du musst schon gezielt ein einzelnes Bit (das mit der jeweiligen LED korrespondiert) entweder setzen oder löschen. Wenn du zb LED1_OFF ausführen lässt POTB = 0x00; dann löscht du damit ja auch gleichzeitig die LED2. Und
-
Thread
Timingprobleme bei Lesen und Schreiben in Array
Hi, über eine ISR empfange ich einzelne Bits, und setze diese dann zu einem Byte zusammen. Ist das Byte vollständig, so wird es in ein Array geschrieben, und in einem 2ten Array ein Flag gesetzt, dass in dem entsprechenden Feld ein neues Byte bereit liegt: [c] if ( receivedBit == 1 ) receivedByte |= (1<<receivedByteDigit); else receivedByte &= ~(1<<receivedByteDigit); lastBit = receivedBit; if ( receivedByteDigit == 7 ) { bytes[bytescounter] =
-
Thread
Einstieg in die MikroController Welt 8, 16Bit oder 32Bit?
8Bit,16Bit,24Bit und dann erst mit 32Bit anfangen? Was ich bis jetzt weiß ist: 8 und 16Bit Microcontroller sind gut geeignet für Messen, Steuern und Regeln Aufgabe. die 32Bit Architektur ist eher
Ich würde für den Einstieg 8 Bit AVR oder PIC nehmen. Vielleicht eventuell noch MSP430. Aber mehr nicht. Alles Andere ist mit Kanonen auf Spatzen geschossen. Bei einem 32 Bit uC würde ich mir übrigens nicht mehr selbst die
-
Thread
String empfangen
Vorausgesetzt das Empfangen der einzelnen Zeichen ist korrekt, dann hast du den String nicht 0-terminiert [C] while(inportb(com+5)&1) //Zeichen empfangen? { c=inportb(com); string[i++]=
Schleife geht schon, nur wird meistens höchstens ein Zeichen pro Durchlauf empfangen. Aber in die Abfrage auf CR gehört dann die Ausgabe rein: [c] if (c=='/r) { string[i] = 0; printf("%s", s); } [/c] oder so wie hier beschrieben: http://www.zeiner.at/c/serialport.html Aber solche Sachen
-
Thread
Tastenentprellen ADC
Danke erstmal, //Bis zur 2. Abfrage schätze ich mal 10µs Programmlaufzeit, das ist keine Entprellung. die Abfragen wollte ich nur zur Bestätigung haben, die eigentliche Entprellung wollte ich dann haben in dem ms wartet deswegen
gleiche Taste erkannt, wird sie gespeichert. Da es 12 Tasten sind, arbeitet die Entprellroutine mit 16Bit. Peter
-
Thread
Code fehler bei 74hc165 kette (einzelner geht)
_BV(DATA165_PIN)) ? 1 : 0; } [/c] wenn PINB & _BV(DATA165_PIN) in der Abfrage TRUE ergibt, dann kennst du bereits das Ergebnis, das die Funktion zurückgeben muss. Das kann dann nur noch 1 sein, weil ja der Pin auf 1 gewesen sein
Vorgehen hätte man das schon gesehen, dass das falsche Bit auf 1 geht. Muss also heissen [c] for (unsigned char i = 0; i < 8; ++i) { shiftResult <<= 1; if (PINB & _BV(DATA165_PIN)) shiftResult |= 0x0001; CLOCK165_low();
-
Thread
Registerinhalte vergleichen
Nabend, (oder guten Morgen?) ich will mehrere mögliche Zustände mit einer if-Abfrage erschlagen. Mein Statusbyte sieht bei einem TRUE wie folgt aus a)0011 0000 b)0001 0000 c)0000 0000 Da vor dem Vergleich noch ein Bit drinsteht, das mich nicht interressiert und das einen
Moinmoin! C unterscheidet zwischen Bit-Operatoren und logischen Operatoren. Die Bit-Operatoren sind z.B. "&" für AND, "|" für OR, "^" für XOR (jeweils zwischen den beiden Operanden) und "~" für NOT (vor dem einzelnen
-
Thread
[C-Code Optimierung] RDM responder
Hier der Disassembler-Code von "compare": [c] @0000009C: compare 161: uint8_t compare(uint8_t*a,const uint8_t*b) { // sollte man ueberpruefen wegen flash pointer. +0000009C: 01DC MOVW R26,R24 Copy register pair +0000009D
> swapInt wertet die Bedeutung eines eintreffenden Paketes (also die PID) > aus. Ich kenne die einzelnen Pakete, die später bei meinem Gerät > eintreffen, nicht zur Compilezeit... Brauchst auch nicht. Anstatt [c] switch (SWAP(var)) case A: case B: [/c] geht doch [c] switch (
-
Thread
8-Bit Latch mit "Read-back"
Memory-Mapped Ports. Das hat dann in meinem Fall den Vorteil, des sehr sehr einfachen Zugriffs auf ein einzelnen Bit des 8-Bit Ports (von denen ich übrigends 5 benötige) Der Zugriff sähe dann wie folgt aus: typedef struct { char bit0: 1; char bit1: 1; char bit2: 1; char bit3: 1; char bit4
Wenn es darum geht, Bits einzeln zu setzen/löschen zu können, ohne den vorherigen Zustand kennen zu müssen, dann tuts vielleicht auch der '259. Da gehen die Bits dann allerdings nur einzeln, weil adressierbares Latch. Dafür
-
Thread
printf in Verwendung mit eclipse+gcc für msp430
Wieso liest du nicht mal die C-Demos von TI? Da steht doch ganz klar drin, wie man die UART im Polling betreibt: Müsste bei dir dann heißen: int putchar(int c) { while (!(IFG1 & UTXIFG0)); // USART0 TX buffer
füttern, eine passende Frequenz einstellen und daraus die Baudrate generieren. Schau dir mal das C-Demo fet140_uart01_0115k_2.c an.
-
Thread
RFM12b von Polling zu Int (AVR)
Danke für deine schnelle Antwort. c-hater schrieb im Beitrag #5004864: > Maximal! > > Das Interruptflag wird aber gesetzt, sobald er das erste Byte im Sack > hat. Die restlichen Bits des FIFO sind nur der Puffer, der es dir > überhaupt
c-hater schrieb im Beitrag #5004993: >> und den FIFO neu gestartet > > Vollkommen falsch. Der muß einfach weiter laufen, um die nächsten 8 Bits > zu empfangen. Einige davon hat er mit einiger Wahrscheinlichkeit
-
Thread
Datenaustausch von µC und PC
) und kriegst den Wert ACCEL_XOUT[15:8] (also die oberen 8bit von einem 16bit Wert) zurück. Wenn du die unteren 8 Bit auch noch willst, dann musst du noch ein 3C schicken und kriegst das dann zurück. Wie das nachher aussieht ist dir komplett überlassen aber
ich das richtig > verstanden habe. Gibt es denn überhaupt µC mit Registern größer 8 Bit? Das macht doch überhaupt keinen Sinn, die UART überträgt immer jeweils ein Byte und das ist nunmal 8 Bit groß (obwohl es UARTs gibt die auch 9 Bits zulassen). D.h. auch
-
Thread
MMC/SD-Karte mit FAT16 an AVR
SPCR #define SPI_SPSR SPSR für den ATmega16, und entsprechendes für den ATmega644. In sd_raw.c ersetzt Du dann einfach alle Vorkommen von SPCR durch SPI_SPCR und SPSR durch SPI_SPSR. Entsprechendes für die einzelnen Bits, falls nötig. Gruß, Roland
hier nochmal die main.c einzeln
-
Thread
Probleme nach Optimierung
oben gezeigten Konstrukt ist nicht gewährleistet, dass das auch der Fall ist. Dafür gibt es eben in C extra die 16-Bit-Zugriffe über ADC bzw. ADCW, bei denen der Compiler das selber in der richtigen Reihenfolge macht.
dass eine Interrupt-Freigabe aus zwei Stufen besteht: /lokale/ Freigabe (über das jeweilige Enable-Bit, im Falle des ADC ist das ADIE) und /globale/ Freigabe über das I-Bit im Statusregister SREG (in WINAVR-C über die Funktion "sei()"). Wenn ein Interrupt freigegeben ist und es keine ISR dazu gibt, führt
-
Thread
avr asm LCD Problem
Resetpin funktionieren, wenn die Initsequenz korrekt ist. Ich würde den Fehler eher in den vielen C&P-Abschnitten suchen. C&P schreit regelrecht nach Fehler machen. Ich würde eine generische 8Bit-Ausgabefunktion schreiben, die überall in das LCD schreiben kann. Übergeben wird Position (X,Y) und Wert
solltest Du die Hälften mal einzeln über CS ansprechen und einzeln initialisieren.
-
Thread
Hilfe bei ATmega32 Programmierung
Hier: [c] #include <avr/io.h> #include <inttypes.h> #include <stdio.h> int main(void) { // Port D initialization // Function: Bit7=Out Bit6=Out Bit5=Out Bit4=In Bit3=In Bit2=In Bit1=Out Bit0=Out
Sebastian Kappel schrieb im Beitrag #3075549: [c] if ((PIND && (1<<PD2)) || (PIND && (1<<PD3)) || (PIND && (1<<PD4))) [/c] Willst du hier die Bits PD2 bis PD4 von PINB abfragen? Dann muss das so aussehen: [c] if ((PIND & (1<<PD2)) || (PIND
-
Thread
LCD Ansteuerung im 4bit-Modus
Was für einen Quarz hast du? Bist du sicher, dass dein uC auch läuft? Lass mal ne LED blinken. MfG Falk
Hallo, die Grundlagen sind schon gut. Hier noch ein Nachtrag zum einzelnen Schreiben von den beiden Zeilen. [c] void write_1st_line(char *s) { lcd_command(line1); lcd_out(" "); //16 signs empty lcd_command(line1); lcd_out(s); } void
-
Thread
Präprozess Makro >>> Fehler: undeclared
. [c] #define SETLOW do{CLR_BIT(PORTB,PB0);\ CLR_BIT(PORTB,PB1);\ CLR_BIT(PORTB,PB0);}while(0) [/c] So macht man das.
, als den Code zwischen den Klammern genau einmal auszuführen, aber es ist insgesamt wieder ein einzelnes Statement. Damit funktioniert die obige Abfrage auch wie erwartet: [C] #define X() do { a(); b(); } while (0) if (z == 3) X(); [/C] wird ersetzt durch: [C] if (z == 3) do {
-
Thread
HAL UART Fragen zum Grundverständnis
autodidaktischer Hobby-Programmierer und steige seit einiger Zeit vom AVR auf den STM32 um (ich programmiere in C) und habe seit Tagen Probleme, den UART in den Griff zu bekommen. Obwohl ich viel gelesen habe, habe ich den Eindruck, als ob mir da noch was vom Grundverständnis fehlt. ich möchte bei einer 8-bit-Übertragung
Die Abfrage von if( byte==0x90) bringt nichts, da byte ja nirgends gesetzt wird
-
Thread
Wlan2Serial Modul für 5 euro
würde daher jetzt ergänzen/ändern: ergänzen in include/driver/uart.h typedef enum { BIT_RATE_312500 = 31250, .. } UarBaudRate; ändern in user_main.c void user_init(void) vorher uart_init(BIT_RATE_115200, BIT_RATE_115200); nachher uart_init(BIT_RATE_31250, BIT_RATE
++) { sar_dout += sardata[i]; } tout = (sar_dout + 8) >> 4; //tout is 10 bits fraction // // re-enables interrupts rom_i2c_writeReg_Mask(0x6C,2,0,5,5,1); while (GET_PERI_REG_BITS(0x60000D50, 26, 24) > 0); //wait r_state == 0 CLEAR_PERI_REG_MASK(0x60000D5C, 0x200000
-
Thread
uC führt Code nicht aus, wenn in if-Abfrage zuvor zu viel Code ist?
Ich will einfach nur wissen warum ein uC etwas bestimmtes nur dann macht, wenn hinter einer Anweisung in einer if-Abfrage, die aufgrund ihrer Bedingung nicht mal "ausgeführt" wird, eine Endlosschleife ist. WARUM?? Steht ich irgendwie total
for(;;);"-Schleife fehlt .. EDIT: Und wenn dieser Code ausgeführt werden würde, dann würde der uC ja bereits bei der PIN-Code-Eingabe hängen bleiben (wegen der Endlosscheleife) .. Nochmal die Frage von vorher: Warum macht ein uC etwas bestimmtes nur dann, wenn hinter einer Anweisung in einer if-Abfrage
-
Thread
IF Statement
Eingangspin vom STK600 mit Taster so funktioniert, dass er bei NICHT gedrücktem Taster eine 1 liefert (Bit ist gesetzt) und bei gedrücktem Taster dieses Bit eine 0 liefert. Will man also etwas tun, wenn ein Taster gedrückt ist, dann lautet die Abfrage if( !(PIND & (1 << PIND1) ) { // Taster
ist??? > PORTA &= ~(1 << PA0) = Ein > PORTA |= (1 << PA0) = Aus Probiers doch einfach aus [C] int main() { DDRA = 0xFF; PORTA = 0b11110000; while( 1 ) ; } [/C] welche LED leuchten? Die bei denen du ein 0-Bit gesetzt hast, oder die bei denen du ein 1-Bit gesetzt hast?
-
Thread
Frage zu Portpinabfrage bei PWM
Register Pin7? Du meinst das Bit 7 von PIND, oder? Geht aber auch nicht. Aber vielleicht habe ich da auch was falsch gemacht. Wie würdest Du denn in C die Abfrage machen? Grüße und Danke für den Support! ;) Dennis
schon zwei Tage her, aber vielleicht trotzdem noch von Interesse: > Register Pin7? Du meinst das Bit 7 von PIND, oder? Ja, das war ein Schreibfehler, statt PIN7 sollte es PIND heißen. > Wie würdest Du denn in C die Abfrage machen? Die Abfrage geschieht wie üblich durch Maskieren: [c]
-
Thread
DOG S 102 Grafikdisplay - Grundlagen
Wenn du das Display nicht abfragen kannst muss du dir einen Buffer im RAM aufbauen, dort kannst du einzelne Bits manipulieren und dann diesen RAM im ganzen ausgeben. Schriftarten werden im Flash abgelegt, von dort die Bytes lesen
Holger W. schrieb im Beitrag #2393608: > Wenn du das Display nicht abfragen kannst muss du dir einen Buffer im > RAM aufbauen, dort kannst du einzelne Bits manipulieren und dann diesen > RAM im ganzen ausgeben. geht das mit einem atmega8? 8 pages und 102 Spalten sind
-
Thread
ATmega644 Timer1 CTC-Mode Timerinterrupt unregelmäßig
Marc Vesely schrieb: > Hast du es mit geänderter Abfrage oder mit anderer Adresse versucht ? Es steht jetzt im Code: [c] GraphicWriteDataOnLcd(0); [/c]
Also, auch mit der geänderten Abfrage ( >= ) bleibt der Fehler bestehen.
-
Thread
Mit MSP430F2132 den Hardware I2c Bus aufbauen um Temperatursensor anzusteuern
Habe jetzt mal was geschrieben kann mal da jemand drüberschauen ob das so funktioniert. [c] #include "msp430x21x2.h" #define FM75_CMD_INPUT 0x90 //Adresse FM75 mit Write Bit #define FM75_CMD_OUTPUT 0x91 //Adresse FM75 mit read Bit unsigned int RxByteCtr
Du hast Verständnisprobleme. Hast Du denn sichergestellt, daß Dein Programm die Abfrage des I2C-Busses mehrfach ausführt? Anscheinend nicht, sonst könntest Du das mit dem Oszilloskop auch sehen.
-
Thread
ESP8266 - Software I2C - Dauernd Resets
[c] uint8_t bitCycle; for(bitCycle = 7; bitCycle >= 0; bitCycle--){[/c] Ein uint8_t ist _immer_ >=0.
#p59024 [c] void transferByte(uint8_t byte){ uint8_t bitCycle; for(bitCycle = 7; bitCycle >= 0; bitCycle++){ uint8_t currentBit = (byte >> bitCycle) & 1; if(currentBit == 1) setHigh(SDA
-
Thread
Mehrere Eingänge
praktisch immer eine Timer-Sache. [[FAQ#Timer]] Aber um bei deinem Programm zu bleiben [C]ISR(INT0_vect) { cli(); /* Interrupt Code */ // EIN/AUS variable if ( PINC & (1<<PINC0) ) ... [/C] frag halt nicht jeden Pin einzeln ab [C] ISR(INT0_vect) {
]] Tu dir selbst einen Gefallen und stell dein 'Projekt' erst mal zurück. Experimentiere mit Bit setzen Bit löschen Bit abfragen (sowohl auf 1 als auch auf 0) Das sind die Grundbausteine eines µC-Programms. Sozusagen das kleine Einmal Eins. Solange diese 4 Dinge nicht 100% sicher sitzen
-
Thread
Interrupt/Pin-Abfrage beim ADUC831
zusammengeführt sind (??). Interessanterweise funktioniert der Zugriff auf INT0 zwar, also z.B.: [c] P2=INT0; //P2 sind die LEDs. [/c] Es leuchtet aber so immer nur die unterste LED (also binär 0001) beim Tastendruck, egal welche Taste ich drücke - sprich: INT0 ist anscheinend nur 1Bit breit.
Ich hab schon viel mit dem Vorgänger ADuC812 gemacht, welcher ja fast identisch ist. Der Interrupt 0 ist ein externer Interrupt (P3.2/INT0). Damit kann man aber ohne weiteren Aufwand nur eine Taste abfragen. Dazu muss auch zuvor der Interrupt
-
Thread
Handling von Meldungen
Merk dir doch wer die Meldung ausgelöst hat, statt wieviele Auslöser es gab. Ordne einfach einzelne Bits in deiner Variable einzelnen Auslösern zu. Dann hast du kein Problem mit Doppelmeldungen und kannst jederzeit Feststellen woher die Meldung kommt. Du musst dann nur bei der Anzeige selber zählen
zurückziehen kannst du mit needsVentilation=needsVentilation & ~MSG_VENTILATION_REASON_HUMID einzelne Gründe abfragen mit doesItStink=meedsVentilation & MSG_VENTILATION_REASON_STINK abfragen ob überhaupt gelüftet werden muss einfach indem du needsVentilation auf > 0 prüfst. Die Zuordnumg musst
-
Thread
Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?
"TARGET_STATE" und "CURRENT_STATE" dann jeweils eigene RGB-Werte wären und keine einzelnen Bits mehr.
[/c] Ohne BitSets sähe das anders aus. Ich will hier niemanden bekehren! Das ist nur mal zum Nachdenken.
-
Thread
Optokoppler an 230VAC
#6539864: > Wenn ich pech habe lese ich ihn dann immer genau zur falschen Zeit aus. Es gibt auch µC da setzt man die Werte zB auf L, der Prozessor arbeitetet weiter und wenn in der Zwischenzeit ein Impuls mit H an dem IO-Pin eingetroffen ist, dann ist beim nächsten Auslesen das betreffenden bit auf
des Optokoppler zwar nur zu 0.1V, dazu Gate-leakage des MOSFETs mit nochmal 100nA, aber bei 25 GradC. Alle 10 GradC verdoppelt sich der, bei 65 GradC kann die Schaltung schon aussteigen. Heinz schrieb im Beitrag #6542251: > Simuliert habe ich jetzt mit 20MOhm. Ich denke ich werde es mit 3MOhm
-
Thread
Gemeinsame Tastenabfrage mit Atmels XMega Serie?
Wie wäre es mit switch..case? [c] void button_interpreter(void) { switch(PORTD.IN) { case 0xFE : // Taste an Bit0 gedrückt // Tu was break; case 0xFD : // Taste auf Bit1 break; /
meinem Codefragment wird genau einmal PORTD.IN abgefragt. Wenns dir nur darum geht, irgendeine einzelne taste abzufragen: [c] void button_interpreter(void) { switch(PORTD.IN) { case 0xFE : // Taste an Bit0 gedrückt case 0xFD : // Taste auf Bit1 case 0xFB : case 0xF7 : case 0xEF :
-
Thread
AVR asm - Befehl nur jedes 2. mal ausführen
würden zwischen den Zündungen 220 Takte vergehen. Also baue ich eine Routine die alle 220 Takte ein 16bit-Register hochzählt. Dann kommt die ISR, der 16-bit Zähler wird übergeben. Ist der Zähler niedrig, ist die Drehzahl hoch und andersrum. Dann setze ich die obersten 2 Bits auf 1 und komplementiere
nun das zu verwendende Bitmuster ;Anzeigen sbrc r16,0 ; Skip if Bit in Register is Cleared; also wenn Bit 0 sbi PORTC,4 ; in r16 0 ist, dann nächste Anweisung (LED setzen) überspringen sbrc r16,1 ; und die einzelnen Bits in r16 abklappern... sbi
-
Thread
PCF8574 - Mal wieder (C/ATmega8)
geht das beim PCF8574 nicht. Was geht nicht? Du hast doch oben geschrieben, dass das hier ... [C] i2c_start_wait(0x70 + I2C_WRITE); i2c_write(0xff); i2c_stop(); [/C] ... funktioniert. Also was hindert dich jetzt daran [C] uint8_t portState; void SetBit( uint8_t bitNr ) { portState |= ( 1 << bitNr ); i2c_start_wait(0x70 + I2C_WRITE); i2c_write( portState ); i2c_stop(); } void ClearBit( uint8_t bitNr ) { portState &= ~( 1 << bitNr ); i2c_start_wait(0x70 + I2C_WRITE);
-
Thread
ATMega 128 Feststellen von einem Tastendruck
Beitrag #4398178: > Der Erklärung bezüglich der Vergleiche von dir konnte ich nicht folgen. > ein Bit hat doch immer nur den Zustand 0 oder 1 wir arbeiten in C aber nicht mit einzelnen Bits. Wir arbeiten immer mit einem Byte. Das besteht aus 8 Bit. Allerdings kann man in einem Byte bestimte Bits
c] ... if ( (UCSR1A & (1<<RXC1)) ) { uint8_t c = getc_USART1(); PORTB = c; } [/c] > Dann habe ich es auch noch mit der folgenden if-Abfrage versucht > if ( (UCSR1A
-
Thread
CAN Bus fifo
einer Struktur verwaltet braucht man mehr pointer, muss alle Fktion erweitern usw. Man hat ja max 4x8Bit für die CAN ID, zwischen 0 und 8x8Bit für die Daten und einmal 8Bit für dlc + ggf. weitere Parameter. Das muss ja alles programmiert werden. Legt man für jedes einen FIFO an, spart man das und muss
, block_size); [/c] Theoretisch müsste ja dann als erstes 1, dann 2 usw. aus dem fifo "kommen", wenn man einzeln abruft. Ich erhalte allerdings 2,3,4,1 nach ein paar Durchläufen. Mit Durchlauf meine ich array in
-
Thread
LCD nach Ein/Ausschalten TOT?
//Timer-Reg. auf NULL } } }} [/c] Vielen Dank!
drin. Sind bei 9600 Baud gut 1,25 Sekunden!) *Tastenabfrage* Übrigens: Du machst im Moment die Abfrage eines ganzen Ports, um eine Taste herauszufinden. Dadurch kannst du nicht zwei Tasten gleichzeitig abfragen (Scroll-Taste UND Sende-Taste). Es wäre besser die einzelnen Bits zu testen Statt
-
Thread
kurzer Denkanstoß zur Pin Ansteuerung per Uart im ATMega
und PORTB 0 bis 5 sind LED mit Treiber Transistoren. Jetzt würde ich gerne die LED per UART einzeln ein und aus schalten können. Was wäre eine einfache und simple Comandozeile, mit wenigen Byte? [code] einschalten: C12C14 -> PortC 2 an, 4 an. ausschalten: C02C04 -> PortC 2 aus, 4 aus. [
. Reicht doch wenn ihn der ATMega kennt! :) Man könnte ihn natürlich auch über selbigen Weg abfragen, wenn wirklich notwendig. Warum für ein Bit ein ganzes Byte verschwenden? Bit7 = Port; Bit6 = on/off; Bit5-0...... Oje, halb vier, egal wird schon passen ;)
-
Thread
mit utoa binär ausgeben, aber mit Anführungsnullen
if-Abfrage zu gestalten: nach dem Bit-Vergleich eine 1 oder 0 zu erhalten und dann 48 dazu addieren. Das ergibt dann eine '1' oder '0' ____________________________________ [c]byte <<= 1; //nächstes Bit
& 0x01) +'0'; [/c] So funktioniert das normale itoa. Siehe [[Festkommaarithmetik]]. Ist aber zumindest auf dem AVR nicht schneller, der kann einzelne Bits testen und verzweigen. >diesen "<<=" Operator habe ich
-
Thread
I2C Kommunikation mit 32 Geräten
Hallo Leute, ich möchte einen I2C Bus aufbauen. Folgende Infos: - 32 einzelne Arduino Mega werden mit einem I²C Schnittstellengerät von NI (https://www.ni.com/de-de/shop/select/i2c-spi-interface-device) ausgelesen - die Länge der
@Dave (Gast) >- 32 einzelne Arduino Mega werden mit einem I²C Schnittstellengerät von >NI (https://www.ni.com/de-de/shop/select/i2c-spi-inter...) >ausgelesen >- die Länge der Datenleitungen von jedem Prüfstand beträgt ca
-
Thread
"bus sniffer" oder sowas for Daten-/Adressbus gesucht
der Zeit graphisch anzuzeigen. Gibt es da auch Software mit der man die Scanergebnisse frei abfragen und programmieren kann? Z.B., dass stets der aktuelle 8 bit Wert des Datenbusses angezeigt wird, und zwar dann, wenn eine bestimmte Adresse am Adressbuss anliegt oder irgendein AE, WE oder CS Signal
nach meinem Laienverständnis doch die Adressen der Peripherie aber auch des Speicherzellen jeweils einzeln abfragen. Zum Speicher: Ich habe den Eindruck, dass die Programme so gestrickt sind, dass diesselben Daten immer an derselben Adresse abgelegt werden; deshalb meine Idee der Überwachung einzelner
-
Thread
Viele Kippschalter (ca. 40) auslesen / Mikrocontroller wake-up
Fall_, dass es doch SPST-Schalter werden müssen, habe ich nochmal über eine Matrix-Lösung mit einem µC nachgedacht, der regelmäßig geweckt wird. Die SW muss ja alle Kombinationen detektieren, also ohne "Phantom-keys". Vielleicht ginge das mit einem µC, der jeden einzelnen Pin zwischen Pull-Up und
Tastenmatrix wäre dieser: https://www.ebay.de/itm/1PCs-PCF8574-IO-Expansion-Board-I-O-Expander-I2C-Development-Module-8-Bit-TE255/232932082676?hash=item363bd583f4:g:TdYAAOSwr6RZnO2V:rk:2:pf:0
-
Thread
AT89C51CC03 Alarmanlage
Verknüpfungen von Bit-Ergebnissen werden in C mit || oder && erledigt. Außerdem dürfte einer der Taster bei dem Board prellen. Also lies mal was über geeignete Entprellmethoden nach.
deinem Programm von 14:59Uhr fehlt eine Klammer nach while(1). Damit wird nur die erste if-else-Abfrage ausgeführt. Die 2. Abfrage steht nach der Endlosschleife einsam da.
-
Thread
Servo delay board
wirklich die Flanken abfragen die ich haben will. Also für Startwert von low nach high und dann in der ISR umschalten für Int von high nach low. Vielleicht wirds dann besser. Die Idee, daß alles auf einem µC läuft gefällt mir sehr gut! Wie würde die Aufteilung der einzelnen Timer dann ausschauen ? Vielleicht so: * Messung mit 16bit Timer. * PWM ausgabe mit ersten 8bit Timer (Signal alle 50Hz) * Erzeugung der Pulsweite mit zweitem 8bit Timer Danke für Eure Hilfe
-
Thread
Rückgabe von Getkbd() - BASIC
LEDs schalten geht schon lange, genau wie einzelne Tasten abfragen (ohne matrix). Ich will doch nur wissen, welche Taste gedrückt wurde.
Simon Hat einen nick wrote: > LEDs schalten geht schon lange, genau wie einzelne Tasten abfragen (ohne > matrix). > Ich will doch nur wissen, welche Taste gedrückt wurde. Und was hindert dich jetzt daran, da an einen Port ein paar Leds anzuhängen und das Ergebnis vom Getkeybs