-
Thread
Kosmos CP1 Emulator mit ATmega
, 8 Bits zu einem Port zusammen zu fassen. Hier kann einem Port entweder mittels einer Zuweisung eines uint8_t Wertes der ganze "Port" auf einmal gelesen geschrieben werden, oder einzelne Bits können gesetzt
Expander, einen für die 8-Bit Informationen der 7-Segmentanzeige (7 Segmente plus Dezimalpunkt), 6-Bit Information für die MPX-Leitungen. Hmm, insgesamt dann 4 Bausteine I/O Expander plus µC ? (nur damit es THT bleibt) ? Ich
-
Thread
LCD Display Problem
Hugo H. schrieb im Beitrag #7785056: > Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig. Vermutlich hast du den Satz anders gemeint, als er wirkt. Der 4-Bit Modus funktioniert auch ohne Busy-Abfrage (z.B. mit passenden Delays
so mal (versehentlich) für HD44780 Kompatible programmiert, also bei jedem 4Bit Zugriff... Tut natürlich nicht, abfragen erst nach dem 2.Nibble!
-
Thread
strings übergeben
device-Controller)diese 6 werte will ich höchstens jede sekunde > (wahrscheinlich alle 10 sek.) abfragen via mainboard. > also habe ich im worst case pro sekunde 6 kommands zu senden und 6 Werte > zu empfangen. Und in der Zwischenzeit löst dein µC noch mindestens 1000 teuflisch schwierige quadratische
nicht ausreichen wird, also zwei byte übertragen und irgendwie zusammenstricken, am einfachsten nen 16bit int als low und highbyte übertragen. Mal ne Frage, wenn ich nen *signed* int habe, denn ich in zwei einzelne bytes zerrupfe, auf der empfängerseite dann aus den beiden bytes wieder ein *signed* zusammenstricke
-
Thread
PIC12F675 brauche Hilfe
Damit ist der Eingang solide auf GND, wenn der Taster nicht betaetigt ist. LED Einschalten: gp4_bit = 1; LED Ausschalten: gp4_bit = 0; GP5 high? abfragen: if (gp5_bit) { .... } oder if (gp5_bit > 0) { .... } warten solange GP0 noch low ist: while (!gp0_bit) {} oder while (gp0_bit == 0
when the TMR0 > register timer/counter overflows from FFh to 00h. This > overflow sets the *T0IF* bit Das Flag kannst du ohne Interrupt Abfragen. Stefan Haussmann schrieb im Beitrag #2433934: > Ich hoffe dass es in diesem Forum einige Experten gibt, die mir einen > kleinen C-Code zukommen
-
Thread
DS18B20 1-Wire Implementierung - Timing-Probleme
Ich bin nun an einem recht frustrierten Punkt: Ich kann zwar den internen 64-bit ROM-Code auslesen (bzw. das was mir der Logic-Analyzer anzeigt sieht gut aus) - allerdings werden einzelne Bits falsch eingelesen (obwohl im Logic Analyzer alle 1er Bits bzw. 0er Bits identisch aussehen
dir das Leben schwerer machst als nötig. Das einzig wirklich interessante Timing ist das eines einzelnen Bits.
-
Thread
C oder Assembler
es gültiges C wäre. Aber PORT.bit (sofern mit `bit' eine Ziffer von 0 bis 7 gemeint ist), kann nach alldem, was ich von der C-Syntax kenne, kein gültiges C sein (weil Feldnamen innerhalb von structs nicht mit
. In C muss man sich erst des Debuggers bedienen und dann die zusätzlichen Laufzeiten manuell irgendwo rausrechnen. Mein Delay unter C habe ich jetzt mit dem 16 Bit-Timer geregelt, was mir zwar den Timer
-
Thread
MSP430xG46x TimerB Capture Compare Register Funktion
|= BIT1; P1DIR&=~0x02;[/c] Das reicht um die C&C Funktion zu nutzen. Damit springt er bei jeder hi/lo oder hi/lo habs nicht im Kopf in den ISR.
= 0x04 gesetzt. --> Sprung in ISR TimerB1 --> ABFRAGE [c] if (TBIV == 0x02) [/c] ... negativ, also sprung zu [c] else if (TBIV == 0x04) [/c] ABER gleichzeitig löscht er das TBIV --> ABFRAGE [c] else if (TBIV == 0x04) [/c] --> negativ, da TBIV ja eben
-
Thread
LCD mit Interrupts?
Teo D. schrieb im Beitrag #5344761: > Das BusyBit abfragen dauert genauso lang. Das zu nutzen für 'nö nächstes > mal bitte' ist eigentlich völlig unnötig, Taktverschwendung. Ja, ich habe das nun auch verstanden: BUSY bringt in Realität nichts.
kürzer macht. In Interrupt, auch ISR_NAKED, wird lediglich Bit in GPIOR0 gesetzt, alles anderes in Hauptschleife. Mit Busy ist so: ich habe zwei Varianten für bedingte Compielen gemacht, mit Busy und mit Delay. [c]//#define LCD_BUSY 1 #define LCD_DELAY 2
-
Thread
UART Protokoll für µC
ziemlich lange nach einer Lib oder einem Standard für die serielle (UART) Kommunikation zwischen µC und PC bzw. µC und µC. Anwendungsfall wäre üblicherweise folgender: Ich hab irgendein Gerät mit einem (relativ kleinen) µC (Atmega o.Ä.) der per UART (+ FTDI, CP2102) an einem PC hängt. Jetzt
.. FFh = binäre Meßwerte. Bedeutung je nach Art des aktuellen Kurvenprotokolles." [/c] Die mit hohem Datenaufkommen daherkommenden Meßwerte werden in 7 Bit Portionen über die Serielle geschickt. Das ist hier der Knackpunkt. Die Wertebereiche $10..$1F und $70..$FF sind also der Übertragung
-
Thread
Probleme Tachosignal Auswertung
aber erst später im Programm dieses BIT setzen und schreibe an die entsprechende stelle im Programm; [c] ADCSRA = _BV ( ADSC ); //Starte AD - Messung [/c] Wie verhalten sich die anderen BITS in dem Register, die ich ja schon vorher
, und NUR DIESES eine Bit zu setzen und alle anderen unverändert zu lassen, veroderst du das Bit [c] ADCSRA |= _BV( ADSC ); [/c] WEnn du 1 Bit gezielt auf 0 zwingen willst, dann wird es als 'Kehrwert' verundet [c]
-
Thread
Gibt es eine Art Allround-Logik-IC?
Microchip haben (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en538621). Das ist ein 2 KiBit EEPROM, mit einer internen "Pre-programmed Globally Unique, 48-bit Node Address" und einer einzelnen Datenleitung. Es ist auch Absicht, dass es nicht ein vergleichbarer Speicher mit I²C Schnittstelle
mit 6 bit, die z.B. ein Schieberegister liefert, 64 Stück einzeln selektieren. mfg mf
-
Thread
IC gesucht zum seriellen Tasterauslesen
Hallo zusammen! Ich will für ein Projekt ca. 100 Taster abfragen. Die Taster sitzen auf einzelnen Platinen, die in Reihe aneinander angeschlossen sind. Ich suche nun nach einer Lösung, wie ich die Taster mit möglichst nur einer Datenleitung abfragen kann. Inspiriert
Guten Morgen, wie wäre es denn mit ein paar MCP23017 16-Bit I2C I/O Expander und einem µC? Gruß
-
Thread
canbus mit SN65HVD230D und FlexCan
sizeof(sysData.b)); CANbus.write(msg); delay(3); msg.id = 0x102; msg.len = sizeof(sysData.c); memcpy(msg.buf, &sysData.c, sizeof(sysData.c)); CANbus.write(msg); delay(3); msg.id = 0x103; msg.len = sizeof(sysData.d); memcpy(msg.buf, &sysData.d, sizeof(sysData.d)); CANbus.write
>>> verstehe was ihr alle eigentlich meint, >>> umsetzen kann ich das dann schon ... >> >> >> [c] >> void v_SendMessage() > [...] >> [/c] oh man ... c ist schon eine tolle sprache, arrays nur mit werten gleichen types, über structs kann man nicht iterieren ... na hauptsache der compiler
-
Thread
50ns Delay mit STM32H7
50ns warten > soll bis er MISO abfrägt? Oh je! Soviele Experten und soviel Unsinniges Zeug. [c] GPIOB->BSRR = (SET_GPIO << PB3); // IO-Bit set GPIOB->BSRR = (RESET_GPIO << PB3); // IO-Bit reset GPIOB->BSRR = (SET_GPIO << PB3); // IO-Bit set [/c] Diese Befehlsfolge erzeugt einen
übrigens nicht. Ich messe damit die komplette Abtropfschale (Wägezelle bis 3kg) und würde am liebsten einzelne Tropfen detektieren (0.05g) was einer Auflösung von 16 bit entspricht (ein Tropfen = ein Bit). Von daher wären >20 Bit nicht schlecht, und dann kann ich eben gleich den nehmen. Der erste Tropfen
-
Thread
Atmega8 - ds1620 direkt ansprechen
OOOH Ein codebeispiel *applaus* ! Jetzt weiß ich tatsächlich was du meinst. Was soll der C Compiler denn intern damit machen, selbst wenn du dieses einzelne Bit herausdefinieren könntest? zaubern? Nee, der MUSS das zwangsläufig in SBI/CBI umsetzen, weil wie soll das anders gehen? Nimm den
auch, nur wenn ich beim Debuggen nicht blind war, müsste er auf meine Methode auch richtig die einzelnen Bits schieben. thx
-
Thread
C++ Frage zum invertieren
Der ~-Operator invertiert jedes einzelne Bit einer Integerzahl, d.h aus 1 wird -2 [pre] dezimal binär 1 -> 00000000000000000000000000000001 -2 <- 11111111111111111111111111111110 [/pre] und aus 0 wird
_t i = 0; i<32; ++i) { std::cout << (tempSubNetMask & 0x80000000U):'1':'0'; // testet oberstes bit tempSubNetMask <<= 1; // alle bits eins hoch schieben. } std::cout << "b" << std::endl; [/c]
-
Thread
AS 6 mit STK500 programmieren "Error ID 0x11"
minimalprogamme zum LED-Blinken an, und wie dort Schleifen und funktionsaufrufe verwendet werden. C-Buch von vorn nach hinten durcharbeiten könnte auch helfen. Zum anderen sind deine Bit-abfragen falsch. Guckst du hier http://www.mikrocontroller.net/articles/Bitmanipulation wie man einzelne Bits
minimalprogamme zum LED-Blinken an, und wie > dort Schleifen und funktionsaufrufe verwendet werden. C-Buch von vorn > nach hinten durcharbeiten könnte auch helfen. Zum anderen sind deine > Bit-abfragen falsch. Guckst du hier Das sind meine ersten Anfänge. Einen Main-Programmablauf habe ich schon
-
Thread
24 serielle Schnittstellen am PC
2-3k€ und lass auf einem Port ein GPS timing modul laufen. Jedoch sollte das Timing Modul auch uC unterstützt sein, ansonsten wenn beim nächsten Terroranschlag das GPS abgeschaltet wird, gibt es keine Daten. Ev. findet sich ein DCF77 Modul mit uC was dafür geeignet ist.
ms Zeitdifferenz zustandekommen im worst case. Ich würde da je serielle Schnittstelle einen uC nehmen von HW RS232 auf spi und einen Master welcher dann den Zeitslot vorgibt sowie auch die Daten ausgibt mit 250Kbps sowie einen uC welcher mittels GPS/DCF77 einen Timestamp ausgibt. Da aber dann
-
Thread
Komm mit der while Anweisung net klar
geben. Normaleweise denkt man so while ((UCSR1A & BitMaske) <> 0) oder while ((UCSR1A & BitMaske) == 0) Nun gilt aber im C 1.) != statt <> 2.) kann man diese Schreibweise abkürzen durch Weglassen des Vergleiches, und das ist sau doofe C
Das führte aber zwangsläufig dazu das sich die Syntaxgrenzen zwischen den einzelnen Sprachelementen verwischten. Also Zuweisung und Boolsche Abfragen in einem einzigsten Konstrukt. Und das wäre mein Hauptkritikpunkt an C. Andere Sprache reduzierten absichtlich diese Möglichkeiten
-
Thread
Vier Gewinnt auf Mikrocontroller ohne KI?
schrieb im Beitrag #1764944: > Ja aber wo speichern wir das ganze? Denk dir was aus. Dein µC hat ja Speicher mit. > sollen wir die Leds mit x und y machen also z.b. x1 bit p1.0 > y1 bit p2.0 > und vor allem wie genau soll die gewinnabfrage
R. W. schrieb im Beitrag #1768596: > also ich möchte nicht jeden bit ansprechen und ausgeben > sondern das array direkt auf die zeile schicken, geht das? Ja, das ist sogar noch viel einfacher als jedes Bit einzeln. Du kannst den Port, an dem die LEDs der Zeile angeschlossen
-
Thread
Auswertung "schneller" Inkrementalgeber
7 Bit Zähler nehmen und die vordersten beiden Bits wieder in den Graycode überführen. Oder gleich einen Graycode-Vorteiler verwenden. Dann käme der eingesetze uC locker zum Auswerten und könnte auch noch
Das ist ja auch Blendercode, der vortäuschen soll, kurz und schnell zu sein. Ohne permanente ext. Abfrage läuft der 8 Bit Wert schnell über und verfälscht den Zählerstand. Hier reicht allein eine Encoderdrehung. Inkrementaldecoder müssen eigenständig im Hintergrund ohne Fehler bei der Zählung laufen
-
Thread
8bit-Computing mit FPGA
Assemblersyntax schon als Hochsprache bezeichnest, wie sieht bei Dir dann eine maschinennahe Sprache aus? Bits? Sind Deine Bits eigentlich trinär oder quaternär? > sondern es reichen einfache Unterprogramme, bei welchen > alle Übergabe-Parameter gleichberechtigt sind. Oder aber auch in C: [c] for
C-3PO schrieb im Beitrag #4281093: > oder ist das perfekt isoliert von allem ? http://www.mikrocontroller.net/articles/8bit-Computer:_bo8h
-
Thread
PIC - Port B - Abfrage
Hallo, leider hab ich schon wieder eine Anfängerfrage. Der Port B ist von BIT 1 bis 6 auf Ausgang, BIT 7 und 8 als Eingang geschaltet. Um den Port B zu steurn benutze ich zum Bsp.: MOVLW B'00100000' ; BIT 6 gesetzt MOVWF PORTB Zur Abfrage: MOVLW B'00100000'
als platzhalter für ein register w steht immer für das arbeitsregister mit den befehlen bsf "b-bit s- set f-flag" und bcf "bit clear flag" aknnst du auch einzelne bits geziehlt setzten/rücksetzen. bsf Variable_1,0 ;setzt bit null btfss "b-bit t-test f-flag s-skip if c-clear
-
Thread
Tasten von verschiedenen Ports auslesen
Mach das abfragen einfach mit ner fallenden Flanke. Bsp: if (bit_is_set(PIND, PIND5) { loop_until_bit_is_clear(PIND, 5); ...
www.mikrocontroller.net/forum/read-4-49709.html#new Daraus geht auch hervor, wie Du die Tasten einzeln abfragst: Danach kannst Du dann die Erweiterung auf verschiedene Ports probieren. Anbei die Rangfolge in C. Peter
-
Thread
24-Kanal PWM Led-Controller mit key-scan
Mit STM32G431R6T im LQFP-64 geht es praktisch ±0 auf. Der hat Hardware für 25 PWM-Kanäle mit 16 Bit Auflösung bei max. 2600 Hz. Die restlichen Pins reichen für 7 bis 10 ADC-Eingänge für die Tastenmatrix, zwei 12-Bit-DACs zum Dimmen, je ein UART, I2C, SPI und USB. Da der auch keinen Quarz braucht,
Ein LL-MOSFET, der den Strom schalten kann (z.B. IRLML2502). Und ein PWM-tauglicher GPIO an deinen µC. Fertig. 24 × 25mA (jede LED einzeln) ergibt halt schon 600mA. Da muß deine "Fernbedienung" schon eine dicke Batterie mitbringen.
-
Thread
Was kostet eine Funktion?
Fabian O. schrieb im Beitrag #3027658: > In C eigentlich auch nicht. Kleine Funktionen in der gleichen > Übersetzungseinheit (C-Datei) inlint der Compiler von selber, wenn es > sich lohnt. Das würde ich so nicht unterschreiben wollen, weil
leicht einzuhalten), wo eine einzelne Codezeile i.Allg. sehr viel mehr tut als in C, aber für C ist die Regel unsinnig.
-
Thread
Programmierung - Doppelbelegung einer Taste
// hier die zweite uhrzeit (EndUhrzeit) ausgeben und in toc speichern toc = HAL_GetTick(); [/c]
ist es im Timerinterrupt eine Variable zählen zu lassen und ist ein bestimmter Wert erreicht, das Bit für Langdruck zu setzen. Das Main kann dann bequem die beiden Bits für kurz oder lang auswerten.
-
Thread
Profitiert double von der 32bit FPU?
mit > -fsingle-precision-constant kompiliert Diese primitive Lösung bei der double und float 32bit hat gibt es nur bei den C/C++-Compilern der 8bit PICs und 8bit AVRs.
>> -fsingle-precision-constant kompiliert > > Diese primitive Lösung bei der double und float 32bit hat gibt es nur > bei den C/C++-Compilern der 8bit PICs und 8bit AVRs. -fsingle-precision-constant bewirkt eben _nicht_, dass double äquivalent zu float ist, sondern nur dass Konstanten (auch ohne
-
Thread
LED Matrix Zeile für Zeile leuchten lassen
Optimierungsversuche so dass jedes Bit benutzt // werden kann uint8_t Display[160]; uint8_t CurRow; uint8_t RowCodes[] = { 0x08, 0x0C, 0x06, 0x0A, 0x00, 0x04, 0x02 }; ISR( TIMER0_OVF_vect ) { uint8_t Mask; uint8_t
wird PB0 auf 1 gesetzt > => somit 40x 1-en oder sehe ich das Falsch?? Das siehst du falsch. [C] if( Display[i] & Mask ) PORTB |= ( 1 << PB0 ); else PORTB &= ~( 1 << PB0 ); [/C] Abhängig vom Zustand des i-ten Bits in Display[i] wird entweder eine 1 oder eine 0 an den
-
Thread
Zählrichtung festlegen
Ich würde die ZU-Variable einsparen. Die Information AUF oder ZU eigentlich in einem einzelnen Bit/ bzw in C einer Variable abbildbar --> "AUF"-gedrückt --> AUF = 1; sowie "ZU" gedrückt --> AUF = 0; So merkst du dir die letzte aktivierte Richtung und zählst bei einem Impuls, der ja nur kommt
else { zaehlerstand = zaehlerstand -1; } zaehlerstand_anzeigen(); P2IFG&=~BIT5; } [/c]
-
Thread
LED Streifen mit light_ws2812
bit (RxC0), den kann man zwischendurch > mal gemutlich abfragen, anstatt mit ISR zu arbeiten, etwa so: [c] Byt2WS2812: ... ;*** DataPin fur WS2812 auf High, bit holen (shift) 7
bits UART abfragen, > nur darf die Pause zwischen den einzelnen Bytes nicht langer als 10us > sein, ansonsten wird Reset ausgelost (WS2812 ist da zickig, nichts mit > 50us wie im DaBla). > UART braucht
-
Thread
Problem mit Programmunterbrechung
erklären >könnte.......... Bitte! :) Bitte? Pollen ist neudeutsch (aka englisch) und bedeutet abfragen. Man fragt also den Pin ab und reagiert entsprechend. Je nach Programmstruktur kann die Abfrage direkt im Programmfluß stehen oder in einerm periodischen Timer-[[Interrupt]]. [c] if (PINC &
benutzen kannst, dann ist er vernünftig. > sondern den Pin > jedes mal am ende der Endlosschleife abfragen? Wenn es nur um diesen Pin geht und es um die Fragestellung geht "soll ich den Pin in jedem einzelnen State jedesmal wieder neu abfragen" dann kann man sich dafür entscheiden. Aber wie angesprochen
-
Thread
AVR64EA28: PIT-Interrupt
Vergleich der Silizium-Revision. Es ist jedenfalls sehr, sehr unwahrscheinlich, dass S.L. ein einzelnes Exemplar mit einem derart spezifischen Fehler erwischt hat. > Welches Device-Pack ist denn > in Deiner Solution eingestellt? Das ist wohl ziemlich irrelevant. Die paar verwendeten Bits und
/avrdude/blob/main/AUTHORS System wide configuration file is C:\avrToolchain\avrdude\avrdude.conf Using port : com5 Using programmer : jtag2updi Programmer baud rate : 115200 Setting bit clk period: 500.0
-
Thread
Sensorwerte vom µC an den PC übertragen
Paritätsbit setzen, es erfolgt aber meist kein Abbruch, wenn es nicht stimmt. Man kann es aber abfragen. Also wartest Du einfach auf das erste Paket, mit fehlerhafter Parität und freust Dich ab diesem Zeitpunkt. Du kannst auf diese Weise das Paritätsbit sozusagen als Marke bzw. neuntes Bit betrachten
Frank K. schrieb im Beitrag #6467414: > Manche UARTs können auch einen 9-Bit Modus. Da kannst Du das 9. Bit als > Blockindikator verwenden. Die meisten μC können das. Aber ich wüsste kein OS auf dem PC das 9 Datenbits unterstützt was auch dazu führt das Seriell-2-USB Wandler
-
Thread
RFM12 Statusabfrage
Um 16Bit per SPI zu übertragen einfach 2x hintereinander abfragen. Das funktioniert problemlos. Du musst nur dadrauf achten, zwischen den beiden Übertragungen die nSEL Leitung auf 0 zu belassen. Ciao,
, digital filter rf12_trans(0xCA81); // FIFO generates IT @ 8 bit received data bits, no sensitive reset rf12_trans(0xC483); // AFC a1, oe, en rf12_trans(0x9852); // Tx configuration, FSK modulation parameters, output power -5dB rf12_trans(0xE000
-
Thread
Spartan 3AN RAM schreiben und lesen über RS232
ich nur einzelne definierte Einträge aus dem Array abfrage (weil er mir dann beim synthetisieren den Rest wegoptimiert). Ich würde allerdings gerne abhängig von einem anderen Signal Einträge aus diesem Array abfragen
Stattdessen gibt es ein "Schlüsselloch" namens Adress- und Datenbus, über das man immer nur ein par einzelne Bits des gesamten RAM ansprechen kan...
-
Thread
[Cortex M3] Festkomma vs Fließkomma
Die üblichen DSPs haben dafür ne Menge Rundungs- und Shift-Modifier schon eingebaut, die Du in C teils recht mühsam implementieren musst. Das Shiften ist Pipifax, aber die Abfrage einzelner Bitsequenzen innerhalb einer dicken Schleife kann ganz schön Zeit verbraten (if-Abfragen sind fast immer schlecht
Die üblichen DSPs haben dafür ne Menge Rundungs- und Shift-Modifier > schon eingebaut, die Du in C teils recht mühsam implementieren musst. > Das Shiften ist Pipifax, aber die Abfrage einzelner Bitsequenzen > innerhalb einer dicken Schleife kann ganz schön Zeit verbraten > (if-Abfragen sind
-
Thread
Flugzeug-Daten auf 1090 MHz empfangen
Hat sich jemand schonmal auf 1030 MHz umgeschaut? Wie viele Abfragen trudeln da so pro Sekunde ein, kann man einzelne Bodenstationen anhand fester Abfrageintervalle und gleichbleibender Feldstärke erkennen? Werden die Modes A, C, S alternierend bei jeder Antennenumdrehung
falsch schrieb im Beitrag #4134035: > Die ADS-B Signale werden ohne Abfrage gesandt Korrekt, das B in ADS-B steht für Broadcast, was genau das aussagt. Verfahren die auf gesendete Signale antworten sind ADS-A und ADS-C. Siehe auch hier: http://de.wikipedia.org/wiki
-
Thread
STM32: Wie funktioniert diese Entprellung?
verallgemeinern? Ich würde an die Funktion den Pin und Port übergeben (z.B. PD2) und dort eine switch-case Abfrage mit allen möglichen Pins. In dieser Abfrage dann den jeweiligen Pin einlesen. Peter D. schrieb im Beitrag #4608892: > Z.B. reicht ein 2Bit-Zähler bei ~10ms > Timerintervall aus. Dann kann
Stellen zugreifen? Falls du meinst, wie ich in main() darauf zugreife, dann mit einer solchen Abfrage (maskierte Abfrage): [c] if (Pin0_state & 0x8000) { // Tastendruck lang, tu etwas } else if (Pin0_state & 0x4000) { // Tastendruck normal, tu etwas } [/c] oder so (bit Abfrage
-
Thread
LCD Busy Flag Abfrage im 8 Bit Modus - die zweite
ein LCD-Zugriff mit Delay durchgeführt (das geht ja laut TO) und danach noch einer per BusyFlag-Abfrage. Dann würde ich mir das ansehen. Ich vermute, das nach dem Ansteuern des Displays das Busyflag noch nicht gesetzt ist, aber der µC das bereits als nicht-mehr-gesetztes Flag auswertet und weiterläuft
ich das busy flag, damit ich im Betrieb "volle Kanne LCD" fahren kann. Verwende nobs zwischen den einzelnen Befehlen, die kannst du später Häppchenweise wieder raus nehmen und testen ob es immer noch funzt. 1. R/W lo schalten, dadurch geht das LCD auf Input. 2. den µC-Port auf Input schalten 3. nops
-
Thread
über uart string empfangen und auswerten!
Es würde ja reichen, wenn Du ein einzelnes Charakter über den UART an den µC schickst. Dann brauchst Du nur eine einzelne "char" variable, würdest das Zeichen speichern und in der Switch Anweisung abfragen.
buffer[pbuffer] & 0x0F; //bits die ausgewertet werden sollen, eingrenzen } x = y/w - z; // x=x - z; //hier sprintf() } [/C] Beantworte doch mal schnell eine Frage: Welchen Wert hat denn y, wenn pbuffer nicht
-
Thread
bit7 bis bit0 einer uint8_t lesen
hallo, ich möchte von einer uint8_t die bits 7 bis bits 0 abfragen ob diese 1 sind in einer for-schleife. finde keinen weg mit winavr-c, da gibt es einmal & und einmal &&. wer kann mir hier mit einer einfachen lösung weiterhelfen und darstellen
"Bei C kann man sehr faul sein ..." ich habe gehört und versuche es einzuhalten, in "c" diszipliniert zu proggen als anfänger. warum fängt man in c wieder als fachmann...an zu schlabbern. ist das insider-c
-
Thread
Böse Falle Boolean
kein Vergleich != > gemacht. Lothar M. schrieb im Beitrag #5200617: > Das kommt jetzt auf io_bitIsSet() an... [c] static_always_inline uint16_t io_bitIsSet(GPIO_t * const GPIOx, const IOPin_t Pin) { return GPIOx->IDR & Pin; } [/c] For your convenience, the expression
Wenn PeDa ein Patent halten würde auf das Layout seines 2bit 8(/16/32)-Fach Parallelzählers, dann könnte ich es verstehen, wenn man versucht die Bits anders zu layouten und statt binär zu zählen, vier einzelne Bits nach der vier Finger-Methode aufreiht. Da aber
-
Thread
Fremd Matrix Abfragen
darauf schon Feststelltaster und gewönliche Taster verbaut und ich will die Fremd Matrix mit einem µC abfragen. Ich habe einen alten Schaltplan auch dazu ausgegraben, das stimmt auch soweit mit der alten Platte überein. Gegeben sind mir an einem Anschluss 6 pins. 1 0V DIG 2 +10V 3 AC CLK
auslesen will bzw welche Datenregister ich setze , RW wäre mein Read oder Write für das setzen der einzelnen Statuse zum abfragen der Daten. Wie ich das ganze anfangen soll, weiss ich leider im Moment gar nicht. Eventuell so: CLK ( high oder low ? ) Setzen des RW Status auf Write ( high oder
-
Thread
Ansteuerung EEPROM 93AA96C funktioniert nicht richtig
Oszilloskop auf, daß der Ausgang des EEPROMs genau dann high wird, um "ready" anzuzeigen, wennn das erste Bit des Lesebefehls gegeben wird. Während des Befehls wird der Ausgang dann low und bringt am Ende die zu lesenden Bits raus. Also stmmen die Abläufe nicht. Diese "ready/busy" - Abfrage ist in irgendeiner
danach soll man noch den Staus entsperren, indem man ein einzelnes Bit ausgibt? Kann mir da mal bitte jemand helfen, die Korrekturen zu finden? mit freundlichem Gruß
-
Thread
Controller hängt sich nach sehr langer Zeit auf Ursache?
Nachlässigkeit, die ich mir in der Vergangenheit zu schulden kommen habe lassen, aber wirklich jede einzelne, sei es ein Designfehler von dem ich wusste, sei es eine lasche Implementierung, sei es Abfrage von Fehlersituationen die ich auf 'später' verschoben habe, egal was ... jede einzelne dieser bewussten
Nachlässigkeit, die ich mir in der Vergangenheit zu > schulden kommen habe lassen, aber wirklich jede einzelne, sei es ein > Designfehler von dem ich wusste, sei es eine lasche Implementierung, sei > es Abfrage von Fehlersituationen die ich auf 'später' verschoben habe, > egal was ... jede einzelne dieser
-
Thread
Tastenentprellen während externen Interrupt - ATmega16
Thomas Eckmann schrieb im Beitrag #3985073: > Das ist ein µC-Kurs in der Technikerschule. Im nächsten Schritt wird > wahrscheinlich die einzelne LED zum Lauflicht ausgebaut. Dann sieht > jeder, dass die Interruptabfrage Mist ist. Oder es wird der Taster durch
frage nur Bedingungen ab. So wie das mit der Zeit angedeutet, kann man auch Ereignisbits nehmen und abfragen. Sind sie gesetzt, werden Subnroutinen abgearbeitet und die Bits gelöscht. So ist erst eine erneute Bearbeitung fällig, wenn dises Bit wieder gesetzt wird. Das sind die "Tuwas" Anweisungen. Wenn du
-
Thread
RS485 Bus aufbauen
c. wrote: > Bei Pic´s , 9bit Übertragungen, bit 9 gesetzt = Node-Addresse, > ansonten nur 8bit verwenden, aber 9bit Senden. > So vermeidet man Probleme mit Syncronisation oder sonstigen Errors. Okay
Hallo Michael, für Multi-Master ohne absolut sichere Abfragen, ob der Bus wirklich frei ist, empfiehlt sich - auch bei niedrigen Nutzdatenraten eine hohe Übertragungsfrequenz, dann ist der Bus nur kurze Zeit belegt. Ich habe derzeit bei 115,2kBit/s 13 RS485
-
Thread
Uart HEX 00 Senden
Geht nicht. printf versendet Strings und die \x00 ist das Zeichen für Stringende in C. Versende die 6 Zeichen einzeln mit 6 putc()-Aufrufen hintereinander.
txBuf[index_txBuf_W&0xf] = parameter; // nur 16 Speicherplätze, deshalb Maske über die unteren 4 Bits index_txBuf_W++; // der Index darf ruhig weiterlaufen, es werden ja nur die unteren 4 Bits verwendet } // Abfrage, ob ein Element im Puffer if (index_txBuf_W!=index_txBuf_R
-
Thread
array auf nullen überprüfen
anderen weg? Oder wäre es besser, einen integer zu nehmen und jeden Sensor durch Bitmanipulation ein einzelnes Bit beschreiben zu lassen? Dann wäre die Überprüfung ja if((variable & 0xFF) == 0xFF) wenn ja, haben alle geantwortet, wenn nein, müsste ich ebenfalls jedes Bit durchgehen, ob dieses 1 oder 0 ist
geht das bequem mit einer 8-Bit, oder 16-Bit-Variablen. Der zeiliche Vorteil ist minimal, bringt eher was bei knappem Speicher. Ablauf: - Antwort-Variable = 0 - Bei erfolgreicher Abfrage des jeweiligen Sensors addierst