-
Thread
Diverse fragen zu Hash Maps in C
U_SM_KEY_TYPE UNHASH(DPA__U_SM_KEY_ENTRY_TYPE num){ return (DPA__U_SM_KEY_TYPE)(num ^ (num<<2)); } [/c] Ich verwende die obersten Bits, also schaue ich einfach, dass diese von möglichst allen Bits abhängig sind. Die Funktion ist nicht ideal wenn die Bits des Keys im vornherein schon nicht unabhängig
unsigned char b[sizeof(a)]; hash(len, b, a); return *(UINT*)b+(sizeof(b)-sizeof(UINT)); } [/c] Wobei das dafür gedacht ist, wenn man die oberen Bits nutzt. Für die unteren bits müsste man es auf die andere Seite Shiften: https://godbolt.org/z/oWbzr37Yn [c] void hash(size_t n, unsigned
-
Thread
Welchen Mikrocontroller für Millisekunden-Stoppuhr?
Ich hatte zuerst mit 80C51 angefangen, konkret AT89C2051. Der hat nur 2 16Bit-Timer. Ein Timer ging für die UART als Baudratengenerator drauf, blieb also nur noch einer übrig. Den konnte man teilen und hatte somit 2 * 8Bit Timer
Familienpackung schon für 0,287 € pro Stück gibt. Einzeln 1,52 €. Peter D. schrieb im Beitrag #7830526: > Ich hatte zuerst mit 80C51 angefangen, konkret AT89C2051. ... Peter D. (peda) schlägt den AT89C2051 vor. Sieht interessant aus. Da werde ich mal
-
Thread
atmega8<--->SPI<--->atmega8
20 bit 3 * 8 = 24 Also die 20 Bit in 3 Bytes aufteilen und nacheinander senden. In welchem Datentyp hast du den die 20 Bit? (geraten: long. da long aus 4 Bytes besteht, würde ich der Einfachheit halber
Vielleicht noch mal kurz zur Erklärung (Du scheinst noch nicht sonderlich viel Erfahrung in Sachen µC zu haben): Tritt ein Interrupt auf, dann löscht die Hardware das I-Bit im Statusregister, wodurch die Bearbeitung neuer Interrupts während der Ausführung der Interrupt-Routine verhindert wird. Wenn
-
Thread
einfache pin abfrage problem
einer for-Schleife quitiert der Compiler > mit: >> error: 'for' loop initial declaration used outside C99 > mode) Nicht, wenn man ihn in den C99-Modus schaltet :) Übrigens wundert mich, daß hier noch keiner eingewendet hat, daß so eine Schleife nichts bringt. Da der Compiler erkennt, daß sie nichts
assembler > da wird das gemacht wat man auch eintippt. Genau... Übrigens kann (fast) jeder *gute* C-Programmierer etwas ASM. Diese Diskussion ist für mich ein Grund mehr, bei ASM zu bleiben... Bit- & Bytebruch... ...HanneS...
-
Thread
qtouch - sekt oder selters
nochmal, folgendes macht mich an meiner Programmierung stutzig...nach folgender Vorgabe: ... [c] #define MAX_CYCLE_PortB 4000 #define MAX_CYCLE_PortD 4000 [/c] wenn ich nun den Wert an Port B und C abfrage: [c] read_senskey_PortB(); read_senskey_PortD(); [/c] funktioniert alles blendend... allerdings ist mir aufgefallen, wenn ich nun eine Abfrage auskommentiere z.B. [c] read_senskey_PortB(); // read_senskey_PortD(); AUSKOMMENTIERT [/c] funktioniert der Tousch-Schalter nicht mehr bzw. der Wert in der Abfrage: [c] if(keys_PortB
-
Thread
Netzwerkkarte mit RTL8019
, bit) do { } while (bit_is_set(sfr, bit)) Unter Linux muessen ausserdem alle Dateinamen, die Grossbuchstaben enthalten (Device.c, Device.h und ARP.c), in Kleinbuchstaben geaendert werden (device.c,
[C]Port D Bit 0[/C] stimmt nicht. Es sollte Bit 7 sein. Kommt davon, weil ich zusammenkopiert habe.
-
Thread
Brauche Unterstützung beim OV7670 (bzw. SCCB)
das "übliche" I2C-Problem. I2C benutzt 7Bit-Adressen in Bit7...Bit1. Bit0 ist eben R/W. Ich kenne genug Datenblätter die es mit R/W als 2x 8Bit-Adresse angeben, ungefähr genausoviele, die die 7Bit-Adresse angeben und
Hi, wenn ich schon mal am schauen bin ... [c] UCSR0C = 0b00001110; ^^|||||| USART Mode Select ^^|||| Parity Mode Bits ^||| STOP Bit Select -> damit setzt Du 2 Stop-Bits
-
Thread
Viele Drehimpulsgeber an einem PIC
und den Status einzeln abfragen. Das braucht dann 22 Ports und du muss die Encoder mit Dioden entkoppeln. Die Abfragezeit für alle machst du dann etwas größer als die Entprellzeit, dann hast du nach 2 Abfragen den Zustand
>Ich würde vorschlagen, einen kleinen MC (14-Pin) für je 4 Encoder und >dann per I2C oder SPI vom Master auslesen. Wenn schon I2C dann mit PCF8574 oder sein 16bit Bruder und auf Interrupt reagieren. Wobei die Sache mit den Shiftregistern wohl am billigsten sein dürfte und auch vollkommen
-
Thread
Tasterabfrage per Interrupt
Widerstand dort nur zum dauerhaften Heizen über die 5V Versorgung dient und nicht als Pulldown. Der µC dort müsste also schaltbare Pulldowns haben, damit das überhaupt funktioniert. Das können nur wenige µC. Michael B. schrieb im Beitrag #7816100: > Lothar M. schrieb: >> Das "seltene" Abfragen allein
Entprellen > sollte man hier nicht so einen Unsinn schreiben. Axel hat Recht, denn natürlich hat keine einzelne Abfrage (und sei sie noch so verzögert) irgendeine Wirkung, die tatsächlich entprellt. Die gefühlte "Entprellfunktion" geschieht dabei nur durch die künstliche Verzögerung der Abfrage. Wenn in der
-
Thread
Höchstmögliche Schaltfrequenz an einem normalen AVR Ausgangs-Pin
möchtest: > > Statt nur eines ATmega328P könntest du auch zwei davon einsetzen, um > sechs 16-Bit-Timer zur Verfügung zu haben. Caesar folgend - parte et divide - kann man dann auch gleich sechs ATmega328 nehmen. Es hängt aber von der Aufgabe ab, inwieweit die einzelnen Stepper synchron zueinander
Wenn man deswegen auf einen anderen Controller wechselt, kann man auch gleich einen mit sechs 16-Bit-Timern nehmen, dann läuft die Impulserzeugung komplett in Hardware, und die Software muss nur noch die Periodendauern vorgeben. So bleibt genug Rechenzeit übrig für die I²C-Kommunikation, das Zählen
-
Thread
PIC Assembler auf- abzählen
rückwärts zu zählen und hin und her. Ich habe probiert mit BTFSC/BTFSS zu arbeiten, kann man auch 8 Bit gleichzeitig abfragen? Außerdem habe ich schon probiert mit dem CARRY Bit im Statusregister zu arbeiten... Bitte um unterstützung. [avrasm] Main incf 0x20,1 movf 0x20,0 movwf PORTB
Ralf G. schrieb im Beitrag #3220438: > btfsc STATUS,C ; Wenn Carry-Bit=0 überspringe nächsten Befehl So wird das nix. Druck Dir TABLE 7-2: PIC16CXXX INSTRUCTION SET aus und lege es Dir auf den Tisch. Und dann schau nach, welcher Befehl das C
-
Thread
Taschenrechner Kommunikation
Paste-Fehler. Bei den beiden Timern des Atmega162 hast du diese Stelle drin, Kommentare von mir. [C] // Je ein 8-Bit Timer pro UART TCCR0 |= (1<<CS00)|(1<<CS02); // Vorteiler 1024 TCCR2 |= (1<<CS00)|(1<<CS02); // Vorteiler 128 !!! [/C] Das bedeutet, auf UART0 hast du bei 7,3728 MHz
Um bei Timer2 ebenfalls einen Vorteiler von 1024 einzustellen, müsste die Zeile so lauten: [C] // Je ein 8-Bit Timer pro UART TCCR0 |= (1<<CS00)|(1<<CS02); // Vorteiler 1024 TCCR2 |= (1<<CS22)|(1<<CS21)|(1<<CS20); // Vorteiler 1024 [/C]
-
Thread
port brav nach c Standard setzen
pushen, IP ablegen und dann einen JUMP Befehl zu deiner Funktion. Wirklich effektiv ist das nicht. [c] #define LED_PIN 3 // Pin 3 an Port x #define SET_BIT( BIT_ , PORT_) \ PORT_ = (PORT_ | (1 << BIT_)) void main (void) { SET_BIT(LED_PIN,PORTB); } [/c] Und jetzt die Quizfrage: Wieviel
unsigned char register_8bit = 0x10; unsigned short register_16bit = 0x00; register_16bit = ~(register_8bit); [/c] ??? Bei Cosmic C Compiler ist es z.B. so, dass der 8 Bit wert auf einen 16 bit Wert gecastet wird und
-
Thread
c167 bit_compare
dies ein bitcompare ist nur ist mir nicht klar was dieser befehl macht. werden hier die ersten 12 bits von R0 mit R15 verglichen oder was wird hier verglichen? Gruß marcs
Das 13te Bit aus R0 wird mit dem 1stem Bit aus R15 verglichen. Aber bevor du alle instruction hier einzeln abfragst, schaust du hier: http://www.keil.com/dd/docs/datashts/infineon/c166ism.pdf
-
Thread
uC from Scratch
Zeug was du da treiben willst reicht ein viel *uebersichtlicherer* 8-bitter alle mal. Ein Silabs C8051F020 hat 8 12 bit ADC-Eingaenge 8 8 bit ADC-Eingaenge 2 12 bit DAC-Ausgaenge noch 8 Ports mit je 8 GPIO (das macht 64 GPIOs 5 V-tolerant). Den anderen Kleinkram wie I2C, UARTs, SPI und Timer
aber ich hoffe jetzt > ist die ganze Sache ein bisschen klarer. OK, du willst vornehmlich mit I2C arbeiten, also ist das Ganze doch eher eine langsame Sache - und nix mit "Ich muss vorallem analoge Eingänge schnell auswerten können. (schneller als 10us)". Schließlich braucht ein einzelnes Bit am
-
Thread
C versus Assembler->Performance Gesperrt
RxDCommandWriteMemGetFirstLengthByte(uint8_t receivedByte); void RxDCommandWriteMemGetSecondLengthByte(uint8_t receivedByte); [/c] kannst man das nicht eine packen und mitgeben welches Byte man haben will? [c] void PS2ReceiveBit0(); void PS2ReceiveBit1(); void PS2ReceiveBit2(); void PS2ReceiveBit3(); void PS2ReceiveBit4
MOVC A,@A+DPTR, JMP @A+DTPR hab ich sehr oft benötigt. Und Bitlogik ging auch sehr einfach mit MOV C,bit, ORL C,(/)bit, MOV bit,C, CPL bit, JBC usw. Ich fands genial, was der Herr Keil da geleistet hat. Meine Assemblerprogramme waren durchweg länger, als später in C geschrieben. Und das Funktionen
-
Thread
ATtiny85 benötige Taster und kein freier Port
mutliplexer oder mit logik IC welche das CS zum Display sperren. Es bietet sich Reset high an, wenn der µC nicht im Programmiermodus ist oder der DS-Port wenn gerade keine DS18b20 Abfrage läuft! Das liegt doch alles in Programmiererhand!
würde. Da hast Du allerdings recht. In https://www.mikrocontroller.net/articles/SPI_Daisychain#.C3.84nderungen_in_der_Steuerung ist das Daisychaining ganz gut erklärt. Hier ist es wohl tatsächlich so, dass mit steigender Flanke von SS jeder Slave die letzten 8 übermittelten Bits dann übernimmt. Hier
-
Thread
2-Stellige 7-Segment Anzeige im Multiplexbetrieb
keine Rolle) Nun: ein DIP-Schalter wäre ja doch dann P1.1 als beispiel. Das ist doch nur ein einzelnes Bit,wie kann ich dann dort eine ganze Zahl anlegen? Das ist mir nun ein Rätsel..
LoTTo schrieb im Beitrag #2901670: > aber Diese 'Schleifen' kann ich ja doch dann nur in C programmieren,aber > nicht mit Assembler,oder? Schleifen, (bedingte) Abfragen, Zuweisungen: Das sind alles die "Grundbausteine" von Algorithmen, egal ob die in C, Assembler, oder in "Pseudocode"
-
Thread
Marderschreck Selbstprogramm
Wozu eigentlich ... [C] void Timer1(){ TCCR1 |=(1<<CTC1)|(1<<PWM1A)|(1<<COM1A1)|(1<<CS12); ... [/c] das CTC Bit? Alles was du brauchst ist PWM1A. Das erzeugt doch bereits eine PWM basierend auf OCR1A (Duty Cycle
bit gesetzt ist ist Timer1 zurückgesetzt und zählt dannn bis es ein Match mit dem OCR1C register hat also mit mein maxpwm ...so hab ich gedacht
-
Thread
4-wire resistive Touchscreen Schaltung TWI USART-Anbindung ATmega8 Assembler LS-7 LS-8
Hallo Bernhard, du verwendest Warteschleifen zwischen den einzelnen Schritten der Abfrage. Um keine Warteschleifen zu bekommen benutze ich eine Art Ablaufsteuerung für die einzelnen Schritte der Touch-Abfrage. Ein Timer-Irq löst dabei eine Abfrage aus, welcher
1,3V. Für den oberen Wert hätte ich besser gegen 1,8V gehen können, aber da der ADC des XMega mit 12 Bit arbeitet, bleibt mir so noch immer eine Auflösung von 1800 Bit für die y-Koordinate und 2000 Bit für die X-Koordinate übrig. Die Wert der einzelnen Widerstände sind: untere Widerstände: 100 Ohm, obere
-
Thread
Servomotor steuern - C Routine von dieser Seite
Was genau machst du hier? Eine art Convertierung? [c] actServo = line[1] - '0'; [/c]
Mit deiner Abfrage klappt es nicht. Ohne klappt es 1 x und dann nicht wieder. [c] if( haveLine ) { // } [/c]
-
Thread
Magnetic Loop Steuerung (Arduino)
zu diesem thema: I would suggest using the same strategy you'd use to eat an elephant: take it one bite at a time. :-) Wenn man den Aufwand, C in funktionierenden C++ Code umzuschreiben mit dem Essen eines Elefanten Vergleicht, fange ich das erst gar nicht an! Vor allem macht es keinen Sinn, ich
Versuche mal die Interrupts bei der Abfrage zu sperren. [c] cli(); if (LastStepperPos != StepperPos) { Serial.println("LastStepperPos"); Serial.println(LastStepperPos); LastStepperPos = StepperPos; Serial.println
-
Thread
-
Thread
Mit 3.3V Mikrocontroller 5V schalten
dann zu überlegen, ob man den tatsächlichen Ausgabestatus der Schieberegister ggfs. auch nochmal abfragen und damit gegenchecken könnte, um bei Nicht-Übereinstimmung des gesendeten Bit- bzw. LED/Relais-Patterns nochmal komplett alle Bits neu durchzuschicken...wie könnte man das lösen ? Also als grobe
> Da müsste man doch dann eigentlich andauernd in minimalen > Zeitintervallen neu den Zustand abfragen und alle 54 Bits (zzgl. ggfs. 2 > "Leer-Bits", um die 7x8 = 56 voll zu machen) für den ganzen > Schalterblock durchjagen und das "Ergebnis" auswerten, oder ? Ja. Dazu solltest das Timing abschätzen
-
Thread
Assembler Schleifen Tricks
[c]unsigned toggle (unsigned i) { return i ^ (1u << 15); }[/c] avr-gcc: [avrasm] toggle: subi r25,-128 ret [/avrasm]
In Assembler habe ich schon lange nicht mehr ein ganzes Programm geschrieben. Höchsten ein paar einzelne Zeilen, um es besser zu machen, als C. Das kommt nur noch selten vor, weil der Compiler immer besser wird und die Chips immer schneller.
-
Thread
Statusvariable als struct?
Ob Du nun 16 Bits in einem Bitfeld oder in zwei Bytes unterbringst, läuft vom Platzbedarf her auf *exakt* das gleiche heraus. Der Zugriff auf ein einzelnes Bit in einem Byte ist nicht wirklich kompliziert, weder beim
8 Bit Zugriffe aufteilt. Ein nicht ausgerichteter 32 Bit Lesezugriff auf einem 386 und aufwärts wird damit in 4 einzelne Lesezugriffe aufgeteilt.
-
Thread
DCF-Uhr, Sonnenstand, TWI-Port, Alarmfunktion für m8 in C
der Abfrage setze ich eine LED auf on und danach auf off. LED bleibt an, so dass die Verarbeitung in der While-Schleife hängt. Laut dcf_77.c wird ein Quarz benötigt: // PB.6/7 XTAL // der Quarz benötigt
habe ich inzwischen die Ungereimtheiten in der Protokollausgabe eingekreist: Wenn weniger als 58 Bit empfangen werden, dann erfolgt keine Ausgabe der DCF-Bits in der Log-Datei. Daher habe ich direkt vor dem Löschen der DCF-Bits (der letzten Minute) noch eine Abfrage auf Vollständigkeit der DCF-Bits
-
Thread
TWI / I2C einf. MASTER SLAVE Beispiel(Assembler) ATmega8
TWSR) - dieses >Register hat sehr unterschiedliche Werte. Ich möchte gern wissen, wie >sich die einzelnen Werte zusammensetzen? Also der Wert im Register >addiert mit 0xF8 ergibt einmal 0x08 oder 0x18 oder 0x40 usw. Der Wert des Registers wird nicht mit 0xF8 addiert, sondern die untersten 3Bit auf
ATMega8 mit Leds am PORTB usw. Das einzige was ich geändert habe ist, das ich vom Master aus nur 1 Bit sende und der Slave es empfangen soll. Außerdem habe ich das ganze in C gemacht. Trotzdem ist vom Aufbau alles gleich. Mein Problem: Adresse wird gesendet und Master erhält ACK. Danach sendet er
-
Thread
mit Bascom über rs232 Frequenz aus einen Frequenzzählermodul auslesen.
einzusteigen. Ich habe zwar eine ältere Version vor vielen Jahren gekauft aber nie was damit gemacht weil mir C einfach lieber ist. Dann kommt noch dazu dass ich in der Firma mit verschiedenen uC Familien/Produkten arbeiten muss. Da ist C günstiger weil ich oft modulare Teile auf andere uC portiere. OK. Mittagspause
habe > zwar eine ältere Version vor vielen Jahren gekauft aber nie was damit > gemacht weil mir C einfach lieber ist. Hallo Gerhard wenn du C beherrschst, dann bleibe bei C da es ohnehin die bessere Sprache zu sein scheint. Ich habe zwar mal versucht in C was zu machen. Dabei bin ich aber
-
Thread
Z80 Projekt für Hauptwerk Orgel
und das mindestens 8 Bit parallel ein- oder ausgeben kann. Diese Sorte Käfer könnte man dann schön gemütlich hintereinander- bzw. parallelschalten. Damit keine Mißverständnisse entstehen: die Abfrage der Klaviaturen und des
Fehler. Solche Dinge löst man anders, z.B. über einen seriellen Bus mit verteilten IOs. Selbst mit [[I2C]] ist man da deutlich besser dran. >Es werden also >mehrere einzelne Platinen mit I/O Bausteinen, Entprellschaltungen, >Flipflops und LED-Treibern >am Datenbus und paar Steuerleitungen I/O-Adressdekodierung
-
Thread
Zugriff auf Ports über einen Pointer od Ähnlichem für PIC18F (nicht Bit Addressierbar)
Wenn man sich den Funktionsaufruf bei jeder Abfrage sparen will, falls es so viele sind dass sie bei der Laufzeit ins Gewicht fallen, könnte man die getInput() auch inlinen lassen oder man versucht es so: [c] // Untested #define INPUT_PIN (*
port_ptr = &PORTD; bitmask = 1 << 5; } if(port_ptr == NULL) return; //... // Abfrage dann mit if(INPUT_PIN) //... [/c]
-
Thread
Atxmega128B1 If abfrage
nämlich nicht. andi schrieb im Beitrag #2891153: > Hallo Matthias auf, > wie würde dann eine Pin-Abfrage auf Pin E0 denn aussehen... Jo, bin jetzt auf... Sieht z.B. so aus, der Taster geht auf Masse, wenn gedrückt. Deswegen aktiviere ich noch den Pullup des Pins: [c] #define BUTTON0 PIN0_bm #define
Auszug. In diesem Fall passt das schon. Beim Xmega sind die Register DIRCLR bzw. DIRSET dafür da, einzelne Bits mit einer Anweisung zu setzen/löschen. @Andi: Poste am besten mal dein komplettes Programm, wie es aktuell ist und sage genau, was es machen soll und was stattdessen es macht. Der Code von
-
Thread
Include Datei "richtig" benutzen
_INT (TIMSK0 &= ~(1<<OCIE0A)) #endif /* TIMER_H_ */ [/c] timer.c [c] #include <avr/io.h> #include <avr/interrupt.h> #include "timer.h" void timer0_init(void) { // 1ms - 8bit uint8_t sreg = SREG; // Save SREG because we have to restore the
, an denen du den aktuellen time_coutn abfrägst. [c] uint8_t getTimerEvent(timer_event* timerEvent) { int16_t timeDiff = 0; uint8_t tmp_result = 0; timeDiff = timerEvent->timeExpired - getTimeCount(); ... [/c] auf die Art hast
-
Thread
MENÜ-STEUERUNG
Deine eigenen Routinen schreibst. Denn für Deinen Zweck taugt das Programm nix, da muss man die einzelnen "Bausteine" anders zusammenfügen. Analysiere doch erstmal, was DEIN Programm tun soll... Es soll: - 8 PWMs erzeugen - ein LCD ansteuern - Taster abfragen - die PWM-Grundwerte verändern
. - Taste betätigt abfragen - Zähler erhöhen - Zähler sperren, bis Taste losgelassen Otto
-
Thread
ADC to UART Problem C/C++
and Transmitter UCSR0B = (1<<TXEN0); //Einstellen des Frame-Formates auf 8data-, 1stop-bits UCSR0C = (0<<USBS0) | (1<<UCSZ00) | (1<<UCSZ01); } //Übergeben einzelner Zeichen des Strings void usart_sput(char *string) { while(*string) { usart_send(*string); string++
average; ++i ) result += ADC_Read( channel ); return (uint16_t)( result / average ); } [/c] Danke für eure Zeit. MfG Max
-
Thread
bitweise vergleichen
Erfüllt die obige Schreibweise diesen Zweck? Ja. Ich würde etwas mehr Übersicht reinbringen: [c] #define TESTBIT 0 ... if (Variable_16Bit & ( 1 << TESTBIT)) ... [/c]
Bitschieben Dass du auf dieses Bit testest, hat ja sicher einen Grund. 'Diesem Grund' gibt man einfach einen Namen. z.B.: [c] #define BIT_LED1 0 #define BIT_LED2 1 #define BIT_SONSTNOCHWAS 2 [/c] Selbstverständlich
-
Thread
VHDL Eingang einen Wert zuweisen
--startbit tx_bit <='0'; elsif c = 10416 then --00000001 tx_bit <='1'; elsif c = 15624 then --00000010 tx_bit <='1'; elsif c = 20832 then --00000100 tx_bit <='1'; elsif c = 26040 then --00001000 tx_bit <='0'; elsif c = 31248 then --00010000 tx_bit <='0'; elsif c = 36456 then --00100000 tx_bit <='0'; elsif c = 41664
-
Thread
Automarer Zugriff auf 32-Bit Variable die in einer ISR verändert wird
= iieks; L = Ticks; if (iieks!=gieks) L = iTicks; return L; } [/c] Das sieht zumindest sparsamer aus auf einer 8 Bit Maschine als ein nachträglicher Vergleich von zwei 32 Bit Zahlen. Und es kommt ohne Interrupt-Beeinflussung aus. W.S.
Was ich mit dem Ganzen sagen will - ob Abfrage eines Flags oder Kopiervorgang einer 32-bit-Variable. Wir kommen von den Takten her auf (beinah) das Gleiche. P.S.: Der PCINT-Fall war nicht auf den ATmega8 bezogen, da er keine Interruptvektoren
-
Thread
Pins und Bits verknüpfen
Hallo, ich fange gerade mit C an und versuche einzelne Pins meines Atmega8 einem Bit der Ausgabevariable zuzuordnen. der folgende Code macht komische Sachen, wo ist mein Denkfehler? [code] DDRC = (1 << DDRC1) |(0 << DDRC2) |
PIND >> pPin) & 1) ^ vVar) & (1 << vBit)) #define mapB(vVar, pPin, vBit) { vVar ^= chkB(vVar, pPin, vBit); } #define mapC(vVar, pPin, vBit) { vVar ^= chkC(vVar, pPin, vBit); } #define mapD(vVar, pPin, vBit) { vVar ^= chkD(vVar, pPin,
-
Thread
Bit's sind vertauscht
1; // Bit 4 unsigned Bit5:1; // Bit 5 unsigned Bit6:1; // Bit 6 unsigned Bit7:1; // Bit 7 }; unsigned char Byte; }; [/c] Ich hasse diese Unions besonders, wenns auf die
Bits kannst du so abfragen: [c] if((byteval & 1<<[Bit-Nummer]) != 0) { } [/c] also eine UND-Verknüpfung.
-
Thread
LM75 über PIC mit C abfragen
Hallo! Für meine Facharbeit entwickle ich zur Zeit ein Steuerteil, mit dem Temperaturen erfasst und ausgewertet werden sollen. Hierfür benutze ich einen PIC16F873A als Controller und einen LM75 als Temperatursensor. Dieser wird über den I2C-Bus abgefragt. Programmiert werden soll der PIC in C (CCS-Compiler). Jetzt habe ich folgendes Problem: Es werden aus dem LM75 2 mal 8 bit ausgelesen. Das MSB aus dem ersten Byte gibt an, ob die Temperatur positiv (0) oder negativ (1) ist. Die nächsten 7 Bit enthalten den eigentlichen Temperaturwert als Binärzahl. Bei negativer Temperatur (MSB = 1) liegt der Temperaturwert
-
Thread
broadcast auf RS485 bus(Abfrage alle Slave adresse)
das gern einsetzen , wenn ich nur wustte wie es gehen kann. >alternative : >alle adressen einzeln durchlaufen >wenn dein gewählter bereich durch is weißste auch welche geräte da sind >und welche nicht Es ist auch eine Möglichkeit diese kann ich nur begrenzt einsetzen, da die Adresse 7Bits
unnötigen kram mitziehen > wenn was aufm bus passiert erfahren es doch eh alle teilnehmer > weil dort bits wackeln Also mir wäre es die eine weitere Leitung wert, wenn ich dadurch viele zeilen code sparen kann. So brauche ich nur eine If abfrage und das wars. Gruß Tobi
-
Thread
Temperaturmessung mit dem LM75
(); lsb = i2c_readNak(); i2c_stop(); [/c] Mehr braucht man praktisch nicht. Die Kodierung der Temperatur ist in allen drei Temperaturregistern gleich (untere 7 Bits unbenutzt, dann 9 Bits mit 0,5°C Auflösung
]]! [c] int16_t t_hy; // VORZEICHENBEHAFTET! t_hy = 54; // als Beispiel, 27°C, 0,5Grad Schritte! lsb = t_hy << 7; // untere 7 Bit sind leer msb = t_hy >> 1; [/c] >- Abfrage ob LM75 vorhanden
-
Thread
AVR-ChipBasic2 - BASIC-Computer mit ATMega 644
@Heiko EEPROMS gehen eigentlich alle 24xx mit zwei Adressbytes, also 24C32 bis 24C512. Beim 24C16 gibt es verschiedene Varianten, manche adressieren mit 3 Bits im ersten Byte und 8 Bits im zweiten, diese funktionieren nicht. @Roger freut mich, dass es so geklappt hat
PS: Bezüglich den Configbits: Ja, es sind alle Bits soweit beschrieben, bis auf Bit 5 für den seriellen Pin Input! In der libmio/library.asm finde ich alle Config Bits und deren Abfrage. Jedoch nicht das 5. Bit für den Input Pin. Außer für die Konfiguration
-
Thread
Hilfe bei PWM
abfragst. Aber mit Verlaub, 27 Kanäle, 10 Bit bei 200 Hz wird "knapp". Vor allem, wenn du dann auch noch was nebenher machen willst (Tastverhältnisse über einen Zeitraum ändern, Kommunikation...). Ich hab
Wieviel RAM steht denn zur Verfügung? Wenn genug RAM vorhanden ist, z. B. 4000 Byte (1000 x 32 bit), zerfällt die 27-fache Abfrage in einen einzigen RAM-Zugriff. Allerdings müssen dafür im Gegenzug bei Verstellung eines einzelnen Wertes mindestens soviele Bytes in der Tabelle neu beschrieben werden
-
Thread
10 Bit ADC Wer über SPI an zweiten Controller senden
Einfach die Register ADCH für die oberen 2bit und ADCL für die unteren 8bit abfragen und versenden.
>Einfach die Register ADCH für die oberen 2bit und ADCL für die unteren >8bit abfragen und versenden. das geht? in BASCOM? Registerpaare auch einzeln auslesen? BASCOM wird mir immer sympathischer!
-
Thread
Unlösbares Problem - Serielle Schnittstelle LPC2138
Wenn ich nun die Abfragen maskiere. if((status&0x04)==0x04) // Empfang - RDA { rx_buffer1=U1RBR; rx_counter1=1; } if((status&0x0C)==0x0C) // CTI- Character Time-Out { .. } Wenn nun im obigen Beispiel
Es ist Zufall, dass der Code jetzt funktioniert. Du darfst nicht ein einzelnes Bit abfragen, sondern musst die drei Bits zusammen abfragen. Das war richtig von dir gedacht. status &= 0b00001110; // Bits 3:1 gelten status >>= 1; // um Bit 0 wegzubekommen ;-) if
-
Thread
interrupt LowPowerMode MSP430F449
Soll das wirklich so sein? [c] void port1_isr(void) { if (get_bit(P1IFG, BIT3)) { if (get_bit(P1IES, BIT3)) { // Interrupt wurde durch eine negative Flanke ausgelöst LPM3_EXIT; if (flow_counter
} clr_bit(P1IFG, BIT3); } } [/c]
-
Thread
VB - msComm.ocx Bringt Fehler - Objekt erforderlich
verarschen. Habe ich so in einen VB Forum gefunden. Link:https://www.vbarchiv.net/tipps/tipp_1276-abfragen-setzen-und-loeschen-von-bits.html VB verfügt über bitweise arbeitende Operatoren (AND, EQV, IMP, OR). In Kombination mit dem NOT-Operator lassen sich die Bitmuster von zwei Variablen auf alle denkbaren
Negation der EQV-Verknüpfung.) Was es in VB aber nicht gibt, sind Funktionen, durch die man direkt einzelne Bits in einer Variable abfragen, setzen oder löschen kann. Zum letzten Absatz. Genau das wollte ich erreichen. und dann hier diese Erklärung. Ich habe dies nun folgendermaßen gelöst. Es ist hier
-
Thread
LCD 4bit mit 4 tasten 1port
das LCD-Display 7 Bits benötigt. Die Tastatur fragst du mit dem letzten 8 Bit ab, die Tastaturleitungen einfach mit einem 74244 auf die Datenleitungen D4-7 schalten. So kannst du ein LCD-Display und 4 Tasten abfragen
Nur bitte für den 4 Bit Modus am LCD die Pins D4-D7 nehmen.. Sorry...