-
Thread
AVR: Endlosschleife erkennen
(PSTR("ardy assert fehler: "),false); uart_putw_dec(err); } } while ( true ); } [/c] "err" wird vom Hauptprogramm mitgegeben und gibt mir einen Hinweis auf die Codestelle im Hauptprogramm. Noch ein uint8_t geht nicht. JTAG-Debugging geht nicht (hab ich auch noch nie gemacht). Wie
ich früher, bei OBD-Testern, es hat immer funktioniert. EDIT Und hab es immer noch - bei I2C.
-
Thread
Griffheizung mit Arduino Nano
[c] float temperature; [/c]
>= zyx)) [/c] Wobei xyz dein oberer Grenzwert und zyx der untere ist bei dem der Teil der If-Abfrage Abgearbeitet werden soll. z.B. zwischen 10 und 5 °C. Tu dir selber einen Gefallen und google die Befehle
-
Thread
AVR/C: Bits in Register in einem Schritt löschen und andere setzen
Hallo, ich möchte gerne auf einem ATmega 328p im Register TCCR2B die Bits CS22 und CS20 setzen und die Bits CS21 und WGM22 löschen. Ich kann das in zwei Schritten mittels [c] TCCR2B |= ((1<<CS22|(1<<CS20)); TCCR2B &= ~((1<<WGM22)|(1<<CS21)); [/c] bewerkstelligen. Der
wobei der Schreiber hier eine Fehler gemacht hat. > Löschen immer noch mit dem > <reg> &= <reg> ~<bit-mask> Naja eigentlich [c]<reg> &= ~<bit-mask>[/c], das was du schreibst ist ja aufgelöst [c]<reg> = <reg> & <reg> ~<bit-mask>[/c].
-
Thread
STM32F0 Discovery welche Library wird genutzt (HAL oder SPL)?
Datenblatt zu lesen und (wenn nötig) den Artikel [[Bitmanipulation]] und dann direkt mit den Registern des µC und den Bits darin zu arbeiten. Eine HAL im eigentlichen Sinn sind ja weder SPL noch das was ST neuerdings /HAL/ nennt. Denn abstrahiert wird da gar nichts [1]. Es ist auch nicht wirklich einfacher
Natürlich bekomme ich als ehem. ASM-Coder Krätze, wenn ich mir überlege, dass ich z.B. zum Setzen oder Abfragen eines Bits ein Unterprogramm aufrufe, welches teilweise auch noch relativ sinnfreie IF-Abfragen enthält. Neutral: - Keine echte HW-Abstraktion, man muss die Beschreibung der Funktionen und
-
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
PORT-Zustand abfrgen und zurück schreiben
[c] #define writeBit(port,bit,value) { if ((value)>0) (port) |= (1<<bit); else (port) &= ~(1<<bit); } #define readBit(port,bit) (((port) >> (bit)) & 1) uint8_t backup=readBit(PORTA,4); writeBit(PORTA
einzelne oder mehrere IOs atomar setzen, löschen >> oder umschalten kann, >Nicht nur das, auch gibt auch noch für jedes Bit n eigenes Register --> >Bit-Banding Die 32 Bit Dekadenz ;-) Naja, mit
-
Thread
BLE für Datenübertragung, Bluetooth
Werbung für sich, das IOS Gerät findet es in einem Scan automatisch. Dann kann man die Services abfragen, das sind quasi "Dienste", für diese kannst du nach den Characteristics abfragen. Jeder Service und jede Characteristics können eine beliebige 128-bit ID haben, die kannst du dir selbst erzeugen.
Lass dir den Service als String ausgeben. Die Services sind 128 bit, 16 bit ist nur die Abkürzung für bekannte Services.
-
Thread
GCC Compiler + ATXMEGA E = Schrott?
, 0x00 ; 0 1bc: f6 e0 ldi r31, 0x06 ; 6 1be: 91 e0 ldi r25, 0x01 ; 1 1c0: 81 11 cpse r24, r1 1c2: 01 c0 rjmp .+2 ; 0x1c6 <main+0x1c> 1c4: ff cf rjmp .-2 ; 0x1c4 <main+0x1a> 1c6: 97 83 std Z+7, r25 ; 0x07 1c8:
alles in der Welt soll das ganze unnötige asm da? Warum schreibst Du es nicht kürzer und lesbarer in C hin? Und warum werden dort die Register und die Bits nicht beim Namen genannt sondern die nackten Zahlen in hex hingeschrieben? Willst Du einen Obfuscation-Contest gewinnen? Und warum ist dieses
-
Thread
Hilfe zu AD Wandler 3fache Messung
C-Quelltext hat die Endung .c, nicht .txt. Du brauchst eine Schleife, die periodisch ADC-Werte aufnimmt und immer schaut ob der interessante Wert überschritten wurde. Sowas wie Interrupts für bestimmte
ADCH is read. Consequently, if the result is left adjusted and no more than 8-bit precision is required, >it is sufficient to read ADCH. Otherwise, ADCL must be read first, then ADCH" Ich weiß jetzt nicht, wie das dein ADCW macht, aber versuch mal die Register einzeln hintereinander
-
Thread
goto verpönt - was dann nehmen?
Peter II schrieb im Beitrag #4498950: > goto bei C (nicht C++) zur Fehlerbehandlung ist üblich und sinnvoll. Definitiv, hab ich auch gestern erst so für eine I2C Routine so genutzt. Da wurde zu erst ein Konfigurationsbyte ausgelesen, ein paar Bits
MCUA schrieb im Beitrag #4545622: >> Und wenn ich die Schritte der Sequenz in einzelne Funktionen aufteile.. > einzelne Funktionen kosten in der Regel jedoch viel mehr CPU-Rechenzeit Das mag vielleicht noch zutreffen, wenn man einen kleinen 8-Bit Mikrocontroller mit wenigen Registern
-
Thread
Microcontroller-Sicherheit in MIL-Systemen durch FPGAs erhöhen
solcher registriert wird. Man kann natürlich alles mit CRC-Checks zukleistern, aber da irgendwo eine Abfrage in SW gemacht wird, ist sie teils für die Katz, wenn ein gekipptes Bit ein "true" suggeriert. Auch bei NIOS bin ich von der Komplexität her skeptisch. Bei einem 8051-Core sieht's schon anders aus
liegen, dann wird die Wahrscheinlichkeit sehr schnell sehr klein, dass genau gleichzeitig mehrere Bits (der selben Funktion) kippen, da ein einzelner Event nur lokal begrenzt aktiv ist. Ist natürlich ein aktiv diskutiertes Thema bei den kleiner werdenden Strukturgrössen. (Es gibt eigene Konferenzen
-
Thread
Besitz Arduino einen RTC?
nichts über das Format aus. - Wenn man Zeiten in µCs häufiger braucht, dann braucht man sie als 32-/64-Bit Variablen. - Atmel nennt I²C auch TWI. Abweichung von normalen Namen, sind ihnen wohl egal (bei I²C waren es auch noch Lizenzkosten). Aber wenn man einmal abweicht...
im Beitrag #4493895: > Wenn man Zeiten in µCs häufiger braucht, dann braucht man sie als > 32-/64-Bit Variablen. Das ist nicht bei jedem so. Ich könnte mir vorstellen, dass nicht jeder auf einem 8-bitter das ganze in einer 64-bit Unixzeit umrechnet (32-bit ist ja nicht besonders zukunftssicher).
-
Artikel
NRF24L01 Tutorial
dankenswerter Weise zur allgemeinen Verwendung zur Verfügung gestellt hat. siehe Tinkerer.eu spi.h spi.c Der SPI Befehlssatz. Command name Command word (binary) # Data bytes Operation R_REGISTER 000A AAAA 1 to 5 LSByte first Read command and STATUS registers. AAAAA = 5 bit Register Map Address W_REGISTER
. Das ist die ziemlich kurze main-Routine zum Abfragen der Daten die im Empfänger angekommen sind. Geübten Augen wird sofort auffallen, daß die Abfrage über Polling in diesem Beispiel den µC solange in einer while-Schleife fest hält bis neue Daten angekommen
-
Thread
Was soll ich nur wählen: DSC/DSP/MCU?
der ein AD-Wandler (120 kS/s Abtastrate) automatisiert via SPI ausgelesen wird und die Werte (4 x 24 Bit) über eine recht komplexe Schaltung in einem FIFO Speicher gepuffert werden. Die Abfrage erfolgt schließlich alle 200 us über einen seriellen 2-Draht Bus mit einer Taktrate von >100 Mhz. DAS ZIEL
Daten mit FPGA: > 100 Mhz - SPI Slave als zusätzl. Kommunikationskanal mit FPGA: ab 100 kHz CLK - I2C Slave als zusätzl. Kommunikationskanal mit FPGA MEINE RECHERCHE: - Eignung Micro-Controller: Die meisten Controller 16/32 Bit werden wohl Probleme mit der Abbildung der hohen Taktfrequenzen haben
-
Thread
SPI Interrupt auf MEGA32U4
warten sicherlich die "while(bedingung" Abfrage. Habe es im spi_receive(); rausgenommen [c] uint8_t spi_receive(void) { /* Wait for reception complete */ //while(!(SPSR & (1<<SPIF))); /* return data register */ return SPDR; } [/c]
-
Thread
AVR Debugger zeigt falsche Werte
. In den defines habe ich stehen: [Code] #define Ein 1 /* Definition für Bit-Variablen */ #define Aus 0 /* Definition für Bit-Variablen */ [/Code] Die Variable Meldung wird gesetzt [Code] char Meldung, Meldung2; Meldung = Aus; Meldung2 = Aus
Die einzelne Funktion umfasst knapp 600 Zeilen Code. Soll ich das mal probieren?
-
Thread
ATmega644PA empfängt auf USART1 nur 0-Bytes nach 2 Min
ist zu überprüfen, ob man senden über Uart0 darf. UCSR0A – USART Control and Status Register A Bits: RXC0 TXC0 UDRE0 FE0 DOR0 UPE0 U2X0 MPCM0 while ( (UCSR0A & (1<<UDRE0)) == 0 ) { } Das zeigt dieses Codestück nicht. [c]uint8_t data, stat; stat = UCSR1A; data = UDR1; UDR0 = data;[/c]
Wunsch und trotz meines besseren Wissens habe ich nun den Code wie folgt "sauber" abgeändert: [c] uint8_t data, stat; stat = UCSR1A; data = UDR1; loop_until_bit_is_set(UCSR0A, UDRE0); UDR0 = data; [/c] Ergebnis: Bringt nix, gleiches Ergebnis - immernoch Nullen
-
Thread
Arduino Display ohne fertige Funktion ansteuern
es zum Laufen bekommt. Top beispiel! Schau mal auf Seite 34. >Dort werden immer nur die Bits für > die einzelnen Funktionen (Löschen, Cursor bewegen, usw.) und die Bits > für die Zeichen angegeben. ja, die Kommandos auch. Dafúr denkst du dir dann ein System aus, wie du die funktionen
kann, ob da nur 2x 4 Bit oder 1x 8 Bit ankommen. Ansonsten ist eigentlich alles gleich. mompf schrieb im Beitrag #4488363: > digitalWrite (RS, HIGH) Laß doch bloß solches Zeugs bleiben. Du hast einen µC, der µC hat Pins
-
Thread
IAR (8051) immer noch mit Bug
des C-Flags provisorisch ganz abzuschalten.
Den vorgesehenen Nachfolger 8096 kennt hingegen kein Schwein. AVR ist schon aufgrund der aus 16-Bit Worten bestehenden Codierung bei solchen Programmen weniger kompakt. Die Kehrseiten liegen in der bei AVR einfacheren Umsetzbarkeit von C Code (lies: der Aufwand im Compiler ist geringer) und dem einfacheren
-
Thread
Softwareentprellung Routine von Peter Danneger
com tz0 ;L-Bit zählen 0,2,->1, 1,3,->0 eor tz1,tz0 ;H-Bit zählen 0,2,->tz1 toggeln and tmp,tz0 ;Änderungen nur dann erhalten, wenn im Prellzähler and tmp,tz1 ;beide Bits gesetzt sind (Zählerstand
aktuell gültigen Tastenstatus der bis zu 8 Tasten "tz0" ist ein (unteres) Register und enthält das Bit 0 der 8 separaten 2-Bit-Prellzähler "tz1" ist ein (unteres) Register und enthält das Bit 1 der 8 separaten 2-Bit-Prellzähler. Zusammen mit "tz0" ergeben sich 8 separate Zähler mit dem Zählumfang von
-
Thread
USB MIDI Gerät
andere Möglichkeit ist mir auch eingefallen: Ein HIDUINO geflashtes Board als Master und die einzelnen Midicontroller mit einen normalen Pro Mini. Das Ganze als I2c Verbund. Da kannst du so viele Controller anbauen, wie du möchtest. Hatte so etwas mal bei einem Synthesizer, da war jeder Pro Micro eine Stimme als I2c slave und wurden in einem 328er als I2C Master zusammengefasst - quasi als Schaltzentrale. Damit hättest du dein modulares Prinzip mit Vierpolsteckern (GND/VCC/SCK/SCL)
-
Thread
Funktionsweise der seriellen Schnittstelle
Jim M. schrieb im Beitrag #4456086: > Auf einem kleinen µC ist eventuell nur das zuletzt gesendete Byte > verfügbar, USB2Serial ICs für PC haben üblicherweise FIFOs, die > 100e Byte groß sein können. Auf kleinen µC kommt es zuweilen sogar vor, dass man sich auf der Empfängerseite um jedes einzelne Bit kümmt, z.B. bei Soft-SPI.
-
Thread
Massive IO Porterweiterung - Stabilität des IO - mehrfaches SPI
verschaltet. Trotzdem "sieht" der Tastaturcontroller die Tasten logisch als einen langen Vektor von Bits. Auf der Programmseite wird sowas typischerweise dadurch gelöst, daß man die logischen Zustände in geeignete Datenstrukturen stopft (z.B. C structs) und Ein- und Ausgabe in Funktionen packt. Der
Grundgefühl sagt mir: Ich kaskadiere einfach mit SPI durch mehrere Bausteine, halt zum Beispiel 4 16bit Input-Platinen... oder was ist nun der Vorteil von I2C? Danke und sorry nochmal!
-
Thread
Arduino oder Mikrocontroller - Was ist besser?
Schlimmeres, als die Arroganz der Fortgeschrittenen. > Also eine LED blinke lassen und ein Pin abfragen geht auch OHNE Lib! Grossartig, nur wurde behauptet, der Anfaenger solle sich mal schnell I2C-Kommunikation zum Einstieg antun.
Bruchteil nachvollziehen kann bzw. will. Zu Hause würde ich am liebsten die Bedeutung von jedem einzelnen Bit kennen. Daher auch mein Interesse an den Assembler-Listings, die der Compiler nebenbei generieren kann.
-
Thread
Serielle Visualisierung mit Comvisu
fast vergessen: 32Bit
gerne mit ComVisu realisieren, finde aber keine adäquate Lösung: Mehrere Relais (32) an einem µC sollen einzeln und/oder in Gruppen von Hand geschaltet werden können. Gleichzeitig möchte ich aber auch die Relais durch Parameter, die von einer Schnittstelle kommen, schalten. Die Schalter in ComVisu
-
Thread
Wer von euch nutz Linux und warum
wehren könntest in Kauf zu nehmen, wo weiss ich das im Vorwege wenn ich Produkte nicht kenne [c] .dBBBBb. dBBP YBBb .dBBP .dBBP" BBB" BBB BBB [/c] der Kunde ist der Tester
Information/IndexerVolumeGuid erstellt wurde, mit folgendem UTF-16 formatierten inhalt: [pre]{23E6E12C-555F-4C7B-87BE-2157C0492895}[/pre] Unter Linux sind keine Dateien auf der Partition. Wenn ich Zeit finde werde ich das noch weiter Untersuchen. -------------------------------- Und jetzt noch
-
Thread
Startbit und USB-RS485/RS232 Adapter
Bussystem vorkommen. Habe mir diesen Adapter zugelegt: http://shop.in-circuit.de/product_info.php?cPath=38&products_id=81 der hat 390Ohm gegen GND oder VCC und 220 Ohm A gegen B. Die Widerstände lassen sich einzeln über DIP-Schalter aktivieren. sobald ich einen der 390Ohm widerstände einschalte
bereits Senderegister leer gemeldet wenn das Stopbit erst halb > raus war. Dann hast Du das falsche Bit abgefragt. Du sollst nicht "Senderegister-Leer" abfragen sondern "Transmission-Complete"
-
Thread
µC für n00bs
mit dem PC verbinde, brauche ich ein Interface, das ich Low-Level programmieren kann. Wo ich jedes Bit einzeln setzen und abfragen kann. Dazu schließe ich einen µC an den USB Bus an und den programmiere ich dann wieder auf Registerebene. Ich Maße mir allerdings nicht an, den einen oder anderen Weg
der völlig kranken Syntax. Immer wieder diese Fragen zur Bytemanupilation. Wenn ich in Bascom ein Bit in einem Register setzen will, dann schreibe ich "Register.Bit = 1". Bascom macht daraus genau das Gleiche wie das kryptische Kauderwelsch in C. Wenn gewünscht, kann man dann immer noch auf C umsteigen
-
Thread
while( ) >>> mit Bedingungen
nur das Bit von PB5 übrig: PINB a b c d e f g h 1<<PB5 0 0 1 0 0 0 0 0 ----------------------- Result 0 0 c 0 0 0 0 0 Falls du aber wissen willst, ob keines der Bits von PINB ohne PB5 gesetzt ist,
Was spricht eigentlich gegen die Verwendung der Makros "bit_is_set" bzw. "bit_is_clear"? [c]bit_is_set(PINB, PB5)[/c] Könnte doch einige Verwirrung vermeiden. Und wenn man partout den Programmablauf unterbrechen will gibt es "loop_until_bit_is_set" bzw
-
Thread
Atmega32, Poti, ADC, Poti-am LCD ausgeben
schrieb im Beitrag #4434056: > PA1 und PA0 - potis (ADC1 und ADC0) Dann stimmt das hier nicht: [c]ADMUX |= cAD_Channel;[/c] bzw. das: [c] ADC_Value_CH1 = ucGetADValue_8Bit (1); ADC_Value_CH2 = ucGetADValue_8Bit (2); // nicht sicher ob der 2er richtig ist [/c] Du fragst ADC1 und ADC2 ab, Datenblatt
AVR-GCC-Tutorial#16-Bit_Register_.28ADC.2C_ICR1.2C_OCR1x.2C_TCNT1.2C_UBRR.29 [c] uint16_t t = ADC; return (unsigned char)(t >> 2); [/c] Alternative: ADLAR = 1 setzen und dann stattdessen nur: [c]return(ADCH);[/c]
-
Thread
Chinakracher als Basis für Studiouhr, Frage von "Nicht-Programmierer"
8550 Industrietransistoren). Sind alle 12 eingeschaltet also 12 * 40mA = 480mA: Die liefert kein uC Ausgang, der bgernzt irgendwo zwischen 20mA und 40mA. Eine LED ist also genau so hell wie alle 12 zusammen, weil jede einzelne dann mit einem Bruchteil des Stroms auskommen muss. 1.6mA, und die auch
Chinesen Multiplexanzeigen nicht verstanden haben. Baut die Schaltung wenigstes so um, daß der uC an den Ausgängen bit0 bis bit11 erst MOSFETs schaltet wie IRLML5203 (dazu muss das Ausgangssignal invertiert werden) bevor diese dann die LED-Leitungen gegen Masse schalten, und verkleinert die Basiswiderstände
-
Thread
STM32F4: Hilfe bei der Timer Konfiguration
TIM2, TIM_IT_Update, ENABLE); /* enable timer module */ TIM_Cmd(TIM2, ENABLE); [/c] Dann noch die Interrupt-Routine: [c] void TIM2_IRQHandler() { if (TIM_GetITStatus(TIM2, TIM_IT_Update) ) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); } pinToggle(); } [/c] In deinem Fall, wenn du wirklich nur eine einzige Art von Interrupt bekommst (Update-Interrupt), kannst du dir die Abfrage des TIM_GetITStatus() auch sparen.
-
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
AVR + WIFI + Webserver
Karte. Das ist aber auch umständlich, da so beide auf die SD schreiben müssten. Der ESP8266 würde einzeln aber denke ich nicht ausreichen... Insgesamt benötige ich 32x Taster, 4x ADC, 1x UART Midi + mehrere LCD Displays in 8 bit Ansteuerung (über die enable Leitung ausgewählt) + kommunikation zwischen
stellt. >Insgesamt benötige ich 32x Taster, 4x ADC, 1x UART Midi + mehrere LCD >Displays in 8 bit Ansteuerung (über die enable Leitung ausgewählt) + >kommunikation zwischen ggf. zwei uC + Anbindung Speicher. Das ist für mich ein System, das irgendwie mit einem Webserver nicht viel zu zu hat
-
Thread
geschachtelte if Abfrage auf AVR Pins
be s. schrieb im Beitrag #4418155: > Das kann man z.B. für folgendes Verwenden: > [c]if((x != NULL) && (*x == 123)) {}[/c] > So ist sichergestellt, dass, falls x gleich NULL ist, der Zeiger nicht > dereferenziert wird. Das stimmt! Die "Einzelbit-Abfrage" sollte wegen den volatilen
} [/c] das wird so für den gewünschten Zweck nicht funktionieren, denn das Ergebnis der UND-Verknüpfung zwichen PINx und Maske ist immer dann ungleich Null wenn *eines* der Bits in der Maske HIGH ist. Es
-
Thread
Geschwindigkeit Arduino > C
Die libraries sind nicht überall so viel langsamer. Das setzen einzelner Bits ist schon so etwas wie ein worst case Beispiel. Bei vielen einfachen Rechenfragen gibt es gar keinen Unteschied zu normalem C Code. Bei so etwas wie UART / I2C kann man es von Hand auch
@ Michael U. (amiga) >Ich quäle auch keine µC, allerdings ist Multitasking z.B. auch keine >µC-Domäne, zumindest nicht in der 8Bit-Klasse. Quark. Jedes halbwegs komplexere Programm macht [[Multitasking]]. Das geht auch ohne Linux und Win10!
-
Thread
automatischer Vorschub für Drehbank
kleines 20x4 hier. Das werde ich dieses WE mal testen. > Ansonsten ist das Ansprechen mit dem 16Bit > breiten Port ein Traum. Das sowieso - und noch wichtiger ist hier die 32-Bit-Arithmetik :-)
hättest Du effektiv 9 Bit, und kannst bis zu 255 Schritte registrieren).
-
Thread
char Array erhält zufällige Werte
} else { senden[sendezahl] = 0; laufvar=1; sendezahl++; } }[/c] Der Kommentar ist falsch. laufvar zählt von 1-256, wobei 256 abgefangen und die Null manuell zugewiesen wird. So wäre es übersichtlicher (funktioniert nur, wenn ein unsigned char 8 Bit hat): [c]static
FIFO-Sendebuffer geschoben. (dieser ist maximal 4Byte lang, weshalb ich einfach jedes Byte extra rein packe.) [c]if(!IFS0bits.U1TXIF) //Wenn Interrupt Flag nicht gesetzt [/c] Durch diese Abfrage prüfe ich, ob das Sendemodul bereit ist, Daten zu senden. Die Interrupt Flag muss ich dann manuell wieder rücksetzen
-
Thread
mal wieder: china meßschieber - 2x24bit-Protokoll mit PIC auslesen
mir der Platz. Also muss ich es entweder: a) sequenziell oder b) mit mehreren PICs oder c) mit externem OSC und hoeherem Takt lesen Mit "c" muesste es gehen - waere aber mit Softwareaufwand und -optimierung verbunden. (10 Eingaenge innerhalb vom 5 uSec abfragen und die Ergebnisse verwertbar
, also von uC zu uC reichen bis zum uC der das USB bedient. Und du wolltest gar keine Anzeige, so wie ich dich verstand.
-
Thread
Bits auslesen
gibt es für die Inline Variante zum schreiben in ein Register auch die passende Gegenseite, wo ich einzelne Bits abfragen kann? https://www.mikrocontroller.net/articles/Bitmanipulation#Hilfsfunktionen_als_Inline-Methoden
){ return (*target & (1<<bit))!=0; }; [/c]
-
Thread
WordClock mit WS2812
dachte ich bei Deiner Frage: > Reichen hier auch die 24C01 (1k) ? dass Du mit 1k ein ganzes Kilobyte meintest. Ich habe mir daher mal ein Datenblatt geschnappt und nachgeschaut: Die 24C01 haben nur 1kBit und damit sind das gerade mal 128 Bytes. Das reicht
adc_value; } //*brightness_p = (adc_value >> 8) & 0x0F; // adc_value has 12 bits, but we need only 4 bits (16 values) for brightness *brightness_p = (15*adc_value/max_adc_value) & 0x0F; } return rtc; } [/c] mfg Ralf
-
Thread
CARRY schnell invertieren Assembler ATmega8 ?
>Und warum musst du es bitweise umdrehen? Nach 8 Bits ist einfacher. So einfach ist das nicht: Weil der MASTER vom 1WIRE Datenbus mur einzelne Bits sendet bzw. empfängt, speziell im Search-Modus, 2 Bits empfangen, danach ein Bit senden
#4409298: > So einfach ist das alles nicht, zumal der MASTER sehr schnell > hintereinander die Bits abrufen kann. Was ich beschrieb sorgt vor allem dafür, den zeitkritischen Teil der ISR zu entlasten. Im verlinkten Code hat an genau dieser Stelle die zeitraubende Abfrage einer Statemachine drin
-
Thread
PIC32MZ Ports mit Pull up spinnt
>> 1) & 1); PLIB_PORTS_PinWrite (PORTS_ID_0, PORT_CHANNEL_E, PORTS_BIT_POS_5, (devIndex >> 0) & 1); PLIB_PORTS_PinWrite (PORTS_ID_0, PORT_CHANNEL_E, PORTS_BIT_POS_4, 0); } } [/c]
Input mit Pull-up konfiguriert, und zwar sofort nach Programmbeginn, also gleich am Anfang von main.c. Was vor main.c läuft weiß ich nicht, danach sind jedenfalls alle Bits in den IO-Registern wie "befohlen". Nach dieser IO-Konfiguration läuft der µC in einer Schleife auf der Stelle. Es gibt bei diesem
-
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
100k knacken - realistisch?
Jahren > aber die 100k die 50k von heute. Geldentwertung kann man nicht isoliert anhand eines einzelnen Guts betrachten. Bei vielen anderen Dingen ist die Preisentwicklung in den letzten Jahren sehr moderat (Lebensmittel) oder sogar rückläufig (Erdöl).
Tja, der Friedhof ist voll von solchen Leuten, nur die Firmen überleben das komischerweise jedes einzelne Mal.
-
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
OSD programm mit einem ATmega32u4
PORTB |= (1 << SCLK); PORTB &= ~(1 << SCLK); Teiler >>= 1; } return Result; } [/c] Mit dieser Hilfsfunktion setzt du dann die 16 Bit Übertragung zusammen [c] uint8_t Transfer( uint8_t regAdresse, uint8_t regDaten ) { uint8_t Result; PORTB &= ~(1 << CS); Transfer8Bit
Heinz hat weiter oben schon einen Beispiel-Code gepostet und auch beschrieben. Seine Funktion [c] uint8_t Transfer8Bit( uint8_t Byte ) [/c] sendet ein einzelnes Byte über MOSI und liefert gleichzeitig ein ggf. empfangenes Byte über MISO zurück... Da der MAX7456 mit CS Low erst ein Adress-Byte