-
Thread
Dip-Schalter an Port-Pins abfragen?
<uP-Portpin> | | | | R R R R <10K-Widerstände> | | | | o-o-o-o | GND Die einzelnen Portpins sind DDR = 0 definiert. Die Schalter wollte ich in ein Struct ablegen, etwa so. [c] struct dipbits{ byte b0 : 1; byte b1 : 1; byte b2 : 1; byte b3 : 1; byte b4 : 1;
Achso, Du meinst, daß ich damit zwar die einzelnen Bits im Struct setzen kann, nicht aber den Zustand der Pins, ob High oder Low, einlesen kann?
-
Thread
Dimmer für den Verteilerschrank mit Steuerinterface
X1/X2 potentialbehaftet ist und ich mit einem µC alle Dimmer, welche an unterschiedlichen Phasen hängen in der Lichtsteuerung abfragen will gibts da Probleme. Eine Lösung könnte sein, einen analogen Optokoppler je Dimmer zu nehmen. Die andere
nach Rohrmotornachrüstung eine noch als Widerlager aktiv ist aber ohne Gurt) auslesen und dann via I²C an den Hauptcontroller die aktuelle Höhe des Rolladens melden (Ausserdem wird der I"C Controller noch die Fenstersensoren abfragen sowie die Helligkeit mittels Sensor aufnehmen und dann als Paket an
-
Thread
24 bit signed data in 32 bit int (ARM SAMS4) und das sparsam über UART
[/c] Bezüglich der Abfrage des Vorzeichenbits des MSB der 24bit daten ergibt sich bei mir allerdings ein Fragezeichen. Im Post oben prüft holger (hier übertragen auf mein Beispiel) bit D7 vom MSB (bei mir in buffer[0]) und setzt daraufhin bits 31:24 zu 1 und castet danach die uint32 auf eine int32. [c] if(buffer[0]& 0x80) temp |= 0xFF000000; int32_t temp2 = (int32_t)temp; [/c] Wenn ich nun aber die obersten 8 bit einer signed 32bit
-
Thread
Arduino: digitalRead in Interrupt ist unzuverlässig
() [/c] nennen ...
(); [/c] und [c] KlasseVorZuruckController ObjektinstanzVonKlasseVorZuruckController; [/c] was dann im Interrupthandler resultiert im Aufruf von [c] ObjektinstanzVonKlasseVorZuruckController.FunctionToHandleVorZuruckCalledFromTimerInterruptEvery1000msec
-
Thread
Entprellung mit Dannegger-Code auf unterschiedlichen Ports
D_OUT_1_off; } [/c] Jetzt die eingelesenen DIN-Zustände mit den Taster-Zuständen in ein Bit verheiraten (hier liegen die einzelnen Bits günstig, falls nicht, dann noch zurechtschieben): [c] i = key_state ^
auch nach Lust und Laune aus mehreren Pin Registern zusammensetzen ... komplette Pins nehmen ... einzelne Bits ausmaskieren, was immer du willst. Hauptsache jeder Taster hat in tmp sein eigenes Bit [C] tmp = ( PINB & 0x01 ) | ( PINC & 0x02 ) | ( PINC & 0x01 ) << 2; i = key_state ^ ~tmp; ..
-
Thread
Lange Rechenzeit von kurzem C-Code
miso[18] = {0}; bcm2835_spi_transfernb(mosi, miso, 18); // Zusammensetzen der 18bit-Daten aus den einzelnen Empfangenen Bytes long AD1_Ch1 = ( miso[0] << 10) + (miso[1] << 2) + (miso[2] >> 6); long AD1_Ch2 = ((miso[2] & 63) << 12) + (miso[3] << 4) + (miso[4] >> 4);
!= 'Z') [/c] es gibt wirklich keinen Grund, hier den ASCII Code von 'Z' selber hinschreiben zu müssen. Dann kannst du dir auch den Kommentar sparen. Denn was eine Abfrage des File Handles auf NULL bedeutet,
-
Thread
I2C-Bus-Problem
Ja, das glaube ich auch. Durch die laufende Abfrage des AD-Wandlers hat sich die Anzahl der Zugriffe auf den I2C-Bus stark erhöht. Alle I2C-Devices lassen sich jedoch einzeln problemlos und fehlerfrei ansteuern. Ich programmiere in C mit Codevision
Gestern habe ich die Abfrage des AD-Wandlers zur Stromausfallerkennung von der Interruptroutine in die main-Schleife verschoben. Seither sind die Probleme mit dem I2C-Bus nicht mehr aufgetreten ! Die Rolladensteuerung befindet
-
Thread
Gesucht: Bus-System um mehrere uC zu vernetzen
keinen LAN Anschluss, weil der uC STM32F4xx nicht genug Ressourcen hat. SPI, I2C, LIN, ModBus, und weitere, auch ältere Bussysteme sind mir bekannt, aber ich müsste einen recht umfangreichen Protokollstack schreiben, damit man die
Andreas I. schrieb im Beitrag #6860021: > mehrere uC Boards von ST Andreas I. schrieb im Beitrag #6861790: > Als eindeutige Identifikation > (UID) möchte ich die Seriennummer des uC nehmen. Die hat aber 96 Bit, ein wenig sperrig für z.B. 24 Bit
-
Thread
AVR ATMEGA8-16 -- Problem mit Bedingungen in Abfragen (while, if)
daß du nicht logisch (im Sinne boole'scher Logik), sondern umgangssprachlich denkst. Du willst abfragen, ob PIND0 /UND/ PIND1 gesetzt sind, also schreibst du eine UND-Verknüpfung hin. Aber das ist falsch. Bei [C] (1 << PIND0) & (1 << PIND1) [/C] wrd jedes einzelne Bit aus 1 << PIND0 mit dem entsprechenden
******************************* (1 << PIND0) & (1 << PIND1) = 00000000 [/Code] Aus deiner Abfrage wird also ein: [C] if (PIND & 0) [/C] Und bei dieser Verknüpfung kann im Ergebnis kein Bit jemals 1 sein, da auf der rechten Seite alle Bits 0 sind. > ist schon schwer, wenn man alleine
-
Thread
40 Spannungen einlesen und an AtMega8 übertragen
<<PCINT0); //an PB0 sei(); TCCR0B = (1<<CS01); //8-Bit Vorteiler OCR0A = 124; //bei 1.5ms while(1); } [/c]
[c] 8MHz / 5kHz / 8 * 4 = 800 [/c] 800 paßt nicht in einen 8-Bit Timer, der Compiler sollte ne Warnung ausgeben. Warnungen muß man lesen! Peter
-
Thread
Mehr als zwei externe Interrupts
diesen einen Entprellvorgang), da wird meist die Soße teurer als der Braten. Dagegen bringt die Abfrage der Taster (meist sind es ja mehrere) im (sowiso vorhandenen) Timer-Interrupt nur Vorteile. Die eigentliche Routine braucht nur wenige Takte, als Ergebnis stehen für jeden Taster mehrere Bits zur
Programmiersprache. Da wo es notwendig ist, passt Assembler sehr gut. ( zb Spezeille Registerzugriffe bei einzelnene µC) Für alle anderen Fälle steht der Aufwand der Assemblerprogrammierung in keinem vernünftigen Verhältnis zum Ergebnis. Ich will jetzt keinem der in Assembler programmiert sagen das er was
-
Thread
Arduino Register abfragen
mich jetzt noch nicht alzu lange mit den Registern des Arduinos beschäftigt und hänge gerade beim abfragen einzelner Pins als Schleife. Dachte mir irgend etwas in diese richtung: for (short i = 0; i <= 3 ; i++){ Schalter_[i] = PIND & (1<<PD[i]); if (i == 4){
arduino hört sich nach gcc an, wäre da > nicht ... uint8_t ... besser? Naja... Es gibt auch viele 32 Bit Arduinos, bzw. über die IDE nutzbare µC. Da kann dann uint8_t oder byte evtl ungünstiger sein. Aber egal. Das ist Mikrooptimierung! Und damit in den seltensten Fällen interessant.
-
Thread
Dumme Frage zum "C" mit AVR's
(1 << PB1); } [/c] Damit sind zumindest die einzelnen Bits auf einem Port unabhängig und können nicht durch race conditions "kaputt gehen". Greifst du natürlich auf einen Pin sowohl im Interrupt, als auch im Hauptprogramm
www.mikrocontroller.net/topic/340330?goto=new#3744804 Ist auch schön logisch zu bedienen: Pin auf '1' setzen: [c] BF_PORTB.portb3 = 1;[/c] Pin auf '0' setzen: [c] BF_PORTB.portb3 = 0;[/c] Pin toggeln: [c] BF_PORTB.portb3 ^= 1;[/c] Pin auf '1' abfragen: [c] if(BF_PINB.pinb3)[/c] Pin auf '0' abfragen
-
Thread
AVR Sendepuffer prüfen
] Bits aus einem Register abfragen/testen ist elementarstes C.
Hallo, an das Abfragen des Bits direkt habe ich schon gedacht wie: Mike R. schrieb im Beitrag #6180909: > while ( !( UCSRA & (1<<UDRE)) ); Aber da ich Zeichen mit uart_putc einzeln Sende, funktioniert das nicht so
-
Thread
Berechnungsfehler?
C. S. schrieb im Beitrag #1838772: > also beide temp variablen sind als double initialisiert. Desweitern > führe ich in meiner ADC_read Funktion eine Berechnung durch, um von den > 10 Bit auf eine Voltzahl
C. S. schrieb im Beitrag #1840008: > Ich persönlich finde es zwar anschaulicher, allerdings bläht das mein > ohnehin schon langes Programm nurnoch auf. Zumal dort noch eine > if-Abfrage hinzukommt.
-
Thread
einzelne Prozessorpins per #define Ansprechen (ATmega16) AVR
Einschränkungen: Man kann damit nur einzelne Bits setzen oder Abfragen. Möchte man ganze Bitgruppen gemeinsam behandlen, muss man wieder auf Bitoperationen zurückgreifen, die dann noch kryptischer aussehen, weil man sie nicht mehr gewohnt
Portzuordnung zu jedem Portpin ein eigenes Define für den zugehörigen Port gibt. Ob dann im Code [c] TESTSIG_BIT1_PORT.TESTSIG_BIT1 = 1; [/c] oder [c] TESTSIG_BIT1_PORT |= (1<<TESTSIG_BIT1); [/c] steht, ist völlig nebensächlich. Oliver
-
Thread
TWI/I2C am ATtiny417
//TWI0_SADDRMASK = 0xff; TWI0_SCTRLA = 0x71; TWI0_SCTRLB = 0x7; [/code] Abfrage um festzustellen ob Adresse stimmt [code] if(twi_test_ap() | twi_test_apif()) { REG->wr_bits.led_vtr1 = ~REG->wr_bits.led_vtr1; twi_ackact(); state = (TWI0_SDATA
Hallo, default für I2C ist Pin PB0 und PB1. Mit Portmux liegt I2C auf PA0 und PA1. Das heißt wenn du im PORTMUX.CTRLB das "TWI0" Bit setzt, dann ist I2C auf PA0, PA1 aktiv. Was du aber nicht machen darfst, wenn du auf Port.A
-
Thread
RST bei Buffernutzung
dass der Eingabetext reset::ssid\t (für \t drück ich natürlich den Tabulator) auf diese Abfrage [C] else if(strstr(buffer,"set:ssid\t")) [/C] passt? strncmp eignet sich für solche Auswertungen besser als strstr [C] else if( strncmp( buffer, "set::ssid\t", 10 ) == 0 ) [/C]
aus if...if ist längst ein if else geworden. Mir ist auch bewusst, dass ich ein Bit aus einem 8-Bit char einzeln toggeln könnte. Dann müsste ich aber wieder die Bitmasken nutzen, sowohl bei der Zuweisung, als auch bei der Abfrage des Flags...
-
Thread
Ein VB6-Programm dekodiert das DCF77-Signal. Das kommt von einem Mikrocontroller/avrasm über COM1 Gesperrt
Zusammenhang nicht entsprechen. Wie gesagt, der Ursprung war eine reine Hardwarelösung, nur mit PC und ohne µC. >Kleine Anmerkung, soll kein meckern sein, den die Projekt-Idee ist gut! >Versuch mal bitte nicht jedes einzelne Verzeichnis zu komprimieren... >hat jetzt 'ne Weile gedauert, bis ich alles entpackt
wenn ein DCF-Modul direkt an die CTS-Leitung angeschlossen wird, also die Variante ohne weiteren µC. Der COM-Port registriert die einzelnen Pegeländerungen, misst die Zeiten und errechnet die DCF-Zeit durch VBA. Ich vermute, das Steuerelement "mscomm" reagiert auf eine CTS-Zustandsänderung (wie
-
Thread
3-Kanäle PWM messen
anfänglich auch gedacht, der > Vorteil davon wäre: Ich könnte natürlich mehr als 3 Kanäle einfach > abfragen. Das halte ich nun wieder für dämlich. Das skaliert nämlich nicht, wenn du für jeden weiteren Kanal einen Pin um µC brauchst. Die Hardware- Variante von oben braucht lediglich weitere drei Bauteile
Langsamen schon mit der Armbanduhr schief gehen wird, dann geht es /sicher/ auch im Schnellen mit dem uC-Timer schief. Das merkt man natürlich nicht sofort (in der Anwendung /hier/ mit einem exklusiven Timer für die Aufgabe gar nicht), aber einzelne Takte summieren sich auf. Und wenn man mehrere solcher
-
Thread
ENC28J60 Basics[Beispielprogramm in AVRGCC für atmega8]
meine Version von avrgcc glaube ich noch aus dem nicht-winavr zeitalter, ich hab pnotepad und gcc einzeln installiert, der GCC ansich ist jedenfalls version : avr-gcc (GCC) 3.4.3 Die Warnings kann ich mir immer noch nicht erklären stack.c: In function `ip': stack.c:87: Warnung: Zuweisung von inkompatiblem
Was mich jetzt allerdings störte war, dass ich nur mit diesem extra C Programm die Sachen abfragen konnte also habe ich ein kleines php Script geschriebe. Da das Ganze wunderbar funktionierte, habe ich es immer mehr erweitert. Es ist längst noch nicht fertig aber hat schon
-
Thread
0-pointer in c
Die einzelnen Bits testen?
Ganzzahl in irgend einem Register. Das hst du auch nicht begriffen? Das Zeroflag ist ein einzelnes Bit - genau das was man zum Speichern einer booleschen Variable minimal braucht. Und die Regeln nach denen die ALU das Zeroflag setzt, sind die gleichen nach denen C den booleschen Wert einer Variable
-
Thread
seriell FTDI TTL UART SUART ich blicke nicht mehr Durch!
besagten Zeilen geht mit dem switch case, dann könnte man das bestimmt vereinfachen. Das extrahierte c, der gewünschte Bit Zustand am Port, ist an dem Punkt schon im switch(c) mit 0 oder 1 ermittelt wurden. Würde für mich bedeuten man kann im case 1 gnadenlos die aktuelle BitPosition verodern/setzen und
i = 0; i < 8; i++) { if (optlen == 0) break; optlen--; char c = opt_s[optlen]; switch (c) { case '1': // Soll Bit Zustand 1 if ((ist & maske) == 0) toggleData |= maske; break; case '0': // Soll Bit Zustand
-
Thread
adch und adcl an display ausgeben ??
Hallo Peter, ich würde es einfach so machen, indem ich das Carrybit abfrage. Schiebe die Daten vom DAC einfach nach rechts, jedes Byte natürlich einzeln. Ist das BIT eine NULL gewesen beim Schieben nach rechts, wird das Carrybit nicht gesetzt, also sende ans LCD eine Null
brcs Write_1 ; springe wenn Bit gesetzt nach Write_1 ldi temp, '0' ; lade den Wert für Null, Carry war 0 rcall out_irgendwieLCD ; senden einer Zahl, hier 0 zurück zur Abfrage ; nächstes Bit abfragen, 7mal
-
Thread
MSP430 PIN-Abfrage immer True
Hallo Forum, ich hab momentan ein Problem mit der Abfrage eines Pins am MSP430. Meine Abfrage: [c] if(P1IN & BIT3) { Do1(); } else { Do2(); } [/c] An P1.3 liegen dabei 4V oder 0V an. In beiden Fällen wird aber die Funktion Do1() ausgeführt
Hi Karol, wo es "noch" lief.. naja, wenn Do1() oder Do2() einzeln ablaufen... der Quellcode mit Initialisierung: [c] //INIT: P1OUT &= 0x00; // Shut down evrything P1DIR &= 0x00; // evrything is a input P1IE |= BIT1 + BIT2; //
-
Thread
Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung
Beispiele: [code]{00} 20:41:29 14.10.12: 0B 90 3F 57 06 00 {8E} 20:41:29 14.10.12: 10 0B 3F 57 01 09 0C 05 0A 0C 8E {30} 20:41:32 14.10.12: 0B 10 3F 57 01 09 0C 05 0A 0C 30 {--} 20:41:32 14.10.12: 01[/code] Bei diesem Beispiel von 0x0B (PC) zu 0x10 (RC30) mit Bit 7 gesetzt (Abfrage). Telegramm 3F
beschrieben: {00} 20:41:29 14.10.12: 0B 90 3F 57 06 00 {8E} 20:41:29 14.10.12: 10 0B 3F 57 01 09 0C 05 0A 0C 8E Das erste Telegramm ist das was ich gesendet habe und das zweite die Antwort. Die Bedeutung: 0B = Absender (EMS-Gateway) 90 = Empfänger 0x10 + 0x80 ( 0x80 = Abfrage-Bit) 3f = Telegrammtyp
-
Thread
Switch Case verzweigung so Anwendbar auf ATmega 32?
A. K. schrieb im Beitrag #2701615: > Aber eben nur in GNU-C, nicht in Standard-C. Leider. In Standard-C muß man die 65536 Case alle untereinander schreiben. Und bei 32 oder 64 Bit: no way. Peter
) ; [/c] Die Gründe dafür: 1. Weniger Redundanz im Quelltext: Bei der Case-Methode tauchen die oberen Intervallgrenzen einer Case-Abfrage um 1 erhöht in der nächsten Case-Abfrage noch einmal auf
-
Thread
Tasterentprellen für Dummies
schrieb im Beitrag #7887173: > Was hat's mit den ALL_KEYS auf sich, ist das ne Maske oder ne > Abfrage? Steht doch in debounce.h. Das ist eine Maske für alle abzufragenden Tasten. Im Beispiel sind es drei Tasten, die parallel abgefragt werden: [c] #define ALL_KEYS (KEY0 | KEY1 | KEY2)
sauberes programmieren möchtest, dann schreibe dir eine Klasse. Hast ja schließlich Arduino und kannst C++ verwenden. Damit haste dann saubere Datenkapselung, saubere Methodenaufrufe usw.. Die ganzen Unsicherheiten fallen weg. Verwende millis() für zeitlich gesteuerte Abfragen und lass die Timer in Ruhe
-
Thread
C Anfängerproblem
Weil Du durch die Zuweisung immer alle 8 Bits auf einmal setzt. Wenn PORTB vorher 0b00000001 war und Du dann 0b00000010 zuweist, dann hat er danach eben den Wert 0b00000010 und nicht 0b00000011. Wenn Du nur einzelne Bits ändern willst, musst Du in C zuerst den alten Wert lesen, das Bit mit einer Maske ändern und den ganzen Wert wieder zurückschreiben: http://www.mikrocontroller.net/articles/Bitmanipulation
-
Thread
Webasto W-Bus
03= ? > A1 = ? in der Antwort der Heizung wird zu dem Kommando was du gesendet hast noch das Bit 7 gesetzt. 0x21 + 0x80 = 0xA1 > 3C = 60min (hex 3C = dez 60) > D1 = Checksum (XOR aus 4F 03 A1 3C D1)? > > > Befehl alle 10 Sek an Heizgerät(zur Erhaltung): > F4 04 44 21 00 95 > > F4 = Wesbasto
* Boost capability */ Hi Sascha! Also folgendes bekomme ich aus MEINER Heizung raus: 4F 0A D1 0C 31 3C C0 E3 3F 80 00 09 D0 = 0x0C = 0b00001100 Bit 4 mit PH ist klar. Aber was bedeutet Bit 3? Ist auch in der WBus-Lib nicht vorhanden. D1 = 0x31 = 0b0011 0001 0000 0001 ??? 0000 0010
-
Thread
if( message>>16 == 0xF084 ) vergleichen ohne verändern?
Scherzkeks. Du hast q1 und q2 als 16 Bit Werte definiert. Damit wirfst du alle anderen Bits weg. D.h. deine beiden letzten IF Abfragen sollten eigentlich auf if(q2==0x9FA0B748) puts("Mute\r\n"); if(q2==0x9FA08778) puts
funktioniert. Nimm doch mal die Tomaten von den Augen. ;-) Du musst in den „inneren“ if-Abfragen schreiben [c] if ((message & 0xffff) == 0xB748) { ... } [/c] oder, wie Thomas in https://www.mikrocontroller.net/topic/307611#3308851 schreibt, den Vergleich sofort als 32-Bit-Zahl aufschreiben
-
Thread
RS232 Schnittstelle außerhalb der main Datei
dem das entsprechende Bit der Bitmaske gleich 0 oder das entsprechende Bit des anderen Operanden gleich 0 ist. >Aber knnte man da ncit gleich schreiben c==...? In diesem Fall vielleicht schon. Aber der Code [c] unsigned
Heute ist es vielleicht so, dass das bei dir so ist. Aber in 2 Monaten brauchst du ev. ein neues Bit, welches dir einen Fehler anzeigt. Machst du die Abfrage gleich richtig, indem du nur dieses eine Bit, welches du abfragen willst, ausmaskierst, dann ändert sich beim verwendenden Code gar nichts. Es
-
Thread
vom µC zum PC
@Philip: Du teilst Byte durch Bit. 200.000 Byte/s / 8 Bit = 200.000kHz. @Lord Witty: Er hat zwei Sensoren, also 200 KByte/s bzw. 1.600.000 Bit
Hallo, ich habe in GFA-Basic eine Abfrage von 2 8-Bit AD-Wandlern am Par-Port geschrieben. Auf einen Athlon XP1900 schafft man damit ca. 40.000 Byte/s. Also nicht wirklich schnell. Um richtig schnell zu werden, wie Klausi es will, braucht
-
Thread
PIC18F2520 Ports abfragen
Wenn ich das richtig verstanden habe musst du nur die unteren drei Bits ausblenden. [c]keys = PORTB & 0xf8;[/c] Bits 0, 1 und 2 sind dann immer 0. Dürfte effizienter sein als jedes Bit einzeln zu lesen.
gesamten Portzustand doch zu vewenden? In deinem Fall macht man so: Ganzen Port lesen, mit einer Bit-Maske UND-verknüpfen, wobei alle Bits der Maske auf 1 gesetzt werden, deren Zustand dich am Port interessiert. Danach ggf. noch 3x Shift oder Division durch 8. > Ich benutze MPLAB und C18 Compiler
-
Thread
Datenübertragung mit mehreren ATMegas
und übersendet die Bits dem System... Nur ein Problem habe ich: Ich weiß letztlich nie, wieviele dieser Karten angeschlossen ist, aber der Mega muss bei Abfrage jedesmal einen String von 48 Bits übertragen... also:
ich: >Ich weiß letztlich nie, wieviele dieser Karten angeschlossen ist, aber >der Mega muss bei Abfrage jedesmal einen String von 48 Bits >übertragen... Immer wieder lustig, wenn der Fragesteller nach längerer Zeit mit dem eigentlichem Problem herausrückt. MfG Spess
-
Thread
Mikrocontroller Datenbank?
Was passiert eigentlich theoretisch in der Datenbankabfrage, wenn ich einen uC mit min. 1kB Speicher, min. 4 IOs und min. 1x 8bit-Timer benötige? Das ergibt dann 178324 Treffer von 178348 insgesamt. Welches Fabrikat wird dann vorrangig ausgespuckt bzw. empfohlen?
universal digital blocks (UDB), programmable to create any number of functions: • 8-, 16-, 24-, and 32-bit timers, counters, and PWMs • I2C, UART, SPI, I2S, LIN 2.0 interfaces • Cyclic redundancy check (CRC) • Pseudo random sequence (PRS) generators • Quadrature decoders • Gate-level logic functions
-
Thread
ATtiny2313 ungewollter Reset?
gerade glücklich für eine Routine, die permanent Runden dreht), wirst Du trotzdem noch sehen, daß der I2C schneller wird, wenn der Lüfter schneller wird. Wobei "schneller" wohl nur bedeutet, daß die einzelnen Datenpakete in geringerem Abstand gesendet werden dabei, aber die Baudrate eines einzelnen Pakets
HIGH oder LOW Phase mit der Abfrage beginne. Ich werd jetz mal nen andern µC probieren. Wenn noch jemandem etwas auffällt bitte melden.
-
Thread
Mini-Farbdisplay (+mehr) für 1 Euro
Ja, man muss die Spannung minimal erhöhen. Das geht hier: [c] lcd_writecom(0x81 ); // Electronic Volume Control lcd_writedat(0x3d ); // EV:Vop[5:0]_6bit lcd_writedat(0x02 ); // EV:Vop[8:6]_3bit [/c] Ob das der ideale Wert ist, habe ich noch nicht ausprobiert
PC Programm geschrieben, um Bilder im BMP Format über die Serielle Schnittstelle an den USART vom µC zu schicken (Später natürlich von SD lesen). Da ich keinen Converter gefunden habe um das 24bit Format in 16bit zu wandeln, muss der µC halt intern von 24bit auf 16bit umrechnen. > In Display12x16Font
-
Thread
mit Tastern auswählen (ATMEGA8)
Gegend rumfloaten. Ein Funktionieren wäre dann purer Zufall. Der einzig zuverlässige Weg, einzelne Eingänge zu erkennen, ist das UNDieren des jeweiligen Bits. Peter
wenn du den WINAVR nimmst, geht die abfrage auch einfacher - nämlich mit dem Makro: bit_is_clear(): Und else-if Ketten sind (angeblich) besser auf Controllern, daher mein Vorschlag: if( bit_is_clear(PINB, 0) ) function0(); else if
-
Thread
UART Problem mit Initialisierung
Wenn du unbedingt bei den if-Abfragen bleiben willst und mehrzeilige Anweisungen schreiben willst, musst du beim Setzen von Bits in UCSRC halt *immer* das URSEL Bit mitsetzen. if (ZBits == 8) { UCSRC |= (1<<URSEL) | (1<<UCSZ0
als eine einfache Zuweisung von Bits. Es *kann* sein, dass bei der Hardwareinitialisierung mehrere Bits zusammen gesetzt werden müssen (siehe URSEL + andere Bits) und das kleckern einzelner Bits nicht wie gewünscht arbeitet. Näheres dazu
-
Thread
if Abfrage in main() ignoriert?
[c] ISR (TIMER1_OVF_vect) // ISR for counting the time with 16-Bit Timer1; Overflow every 20ms {static uint8_t _20_ms=0; _20_ms++; if (_20_ms == 50) { Second++; _20_ms = 0; PORTC ^= (1<<PC0); } } [/c] Du setzt jedes mal wenn du in die ISR kommst deinen Wert von _20_ms auf Null. Dann geht er ja schon nie in die if Abfrage in deiner ISR. Wie sollte dann Second jemals 5 werden?
-
Thread
Viele Flags effizient speichern und schreiben/Byte in Bitfeld?
: 1; unsigned int bit12 : 1; unsigned int bit13 : 1; unsigned int bit14 : 1; unsigned int bit15 : 1; } bits; unsigned int data; } packet_t; [/c] Bitte lies mal in Deinem C Buch
Unions mit 1-4 Byte Zugriff macht man eigentlich nur für Register des µC, um die einzelnen Bits manipulieren zu können und dann in einem Rutsch zu lesen und zu schreiben. Telegramme, vor allem wenn sie mehr als 4 Byte enthalten, schreibt man eigentlich in einer (verschachtelten
-
Thread
ADC Ergebnis auf dem Display ausgeben
möchte, dass ich dann wohl den Datentyp float nicht umgehen >kann....zumindest sagen mir das meine C-Kenntnisse..... Oder sollte ich >falsch liegen?! Du liegst falsch. Man kann auch wunderbar mit Integer/Festkomma arbeiten. Z.B. nimmt man ein long (32 Bit) und verwendet die oberen 16 Bit für den
ADCL; >>>> x_h = ADCH; >>>> vari = (x_h<<2) | x_l; > >>der kommt wieder.... > > Die Abfragen-Reihenfolge ist dch richtig. Schau dir mal den Zusammenbau des Gesamtergebnisses an. Manchmal frag ich mich schon was so toll am einzelnen Auslesen von 2 8-Bit Registern ist. Der Compiler
-
Thread
RS232 über C++ auslesen Gesperrt
Hallo! Folgendes Problem: Ich sende mit einzelne Byte's mit meinem µC über RS232 an den PC. Ich möchte die Daten der RS232 mit einem C++ auslesen und im Programm damit weiterrechnen. Ich hab im Internet schon verzweifelt nach brauchbaren Infos
&= ~PARENB options.c_cflag &= ~CSTOPB options.c_cflag &= ~CSIZE; options.c_cflag |= CS8; wäre für mich zutreffent ! und ich denke mal da habe ich doch alles richtig. Selbst wenn es duch das abfragen mein rechner blockiert
-
Thread
UART-Daten eines FTDI-Chips in C# auslesen
für empfangene Bits definieren UInt32 numBytesToRead = 0; // Variable für verfügbare Bits definieren byte[] r = new byte[15]; // Verfügbare Bitanzahl abfragen myFtdiDevice.GetRxBytesAvailable(ref numBytesToRead
. einzelne Bytes @ 7 Bit, welche ich in ein ASCII-Zeichen umwandeln muss (8 Bit?!) oder sämtliche Bits, welche gerade empfangen werden? vielen Dank :-)
-
Thread
Maßnahmen gegen das Hängen bei SPI/I2C Kommunikation
Störung oder einem Reset gerade ein Slave als Sender > adressiert, kann dieser SDA auf low ziehen (0-Bit senden). Da helfen > dann bis zu 9 Takte auf SCL. Diese 9 Takte sind eigentlich fast immer das Patentrezept, wenn der I2C-Bus klemmt. Ich konnte das bei Tests nachvollziehen. Wird der µC mitten
das I2C in genau diesem Zustand. Man verdächtig dann den I2C-Slave, obwohl der Fehler an einer völlig anderen Stelle passiert. Trick 17 wäre natürlich: - SDA abfragen - SCL 10* takten // above 9 but not
-
Thread
Algorithmus für Zeit zw 2 Zeiten
Sekunden um???? Sollte ich direkt die Jahre in Sekunden umwandeln und dann den Monat mit select case einzeln in 12 abfragen in Sekunden umwandeln??? Sorry jungs, aber mir fällt dazu wieder keine bessere Idee ein....
> dann den Monat mit > select case einzeln in 12 abfragen in Sekunden umwandeln??? Der Februar hat nicht immer gleich viele Tage ;) Ohne gregorianische Kalender wirst du hin und wieder kräftige Sprünge in deiner Zeitdifferenz bekommen
-
Thread
$21 $c9
Hallo! Ich bin gerade im AVR-Tutorial am arbeiten, und bin auf 2 kleine offnen Frage gestoßen: Im 4ten teil steht ldi Temp1, $21 Temp1 ist ja nichts anderes, als der name für einen register. aber was bedeutet "$21" ? ist das ein eigenes Zahlensystem? Wofür steht brne? aus der HTML Hilfe werde ich nicht schlau?!?! danke für die Hilfe!!
-
Thread
Parallele Reedkontakte mit Toggle
c-hater schrieb im Beitrag #6745041: > Du mußt also eine Schaltung finden, die das separiert. Man kann das > durch Differenzierglieder (AKA: Kondensatoren) erledigen, für jeden > einzelnen Kontakt
macht ein Port-Expander an Pin INT genau das, was ich für den Reset des ESP brauche. Die Status der einzelnen Eingänge könnte ich dann über I2C einlesen, richtig? Danke für den Hinweis @c-hater https://www.mikrocontroller.net/articles/Port-Expander_PCF8574 Pin7 wäre dann ein Beispiel für die Beschaltung
-
Thread
kein Zugriff auf I2C-EEPROM
/write operation select bit. A read operation is initiated if this bit is high and a write operation is initiated if this bit is low. [/c]
Marc V. schrieb im Beitrag #4900943: > Das man nicht über 0x78 abfragen soll, ist nur meine Empfehlung, > verboten ist es nicht. > 0x78 bis 0x7B ist reserviert für 10-bit Adressen. > 0x7C bis 0x7F ist reserviert für zukünftige Erweiterungen. hmmm die Idee kam