-
Thread
4x4 Matrix Tastatur am FPGA
pattern verundet, welches a) die jeweilige Frequenz detektiert, wenn es passt und b) die hochfrequenten bits per exor zurückbiegt, damit das nächste pattern ein tieffrequentes Signal "sieht". Beispiel: Eingangsfrequenzen für z.B. 4 Schalter, mit Schalter 2 auf "aus" Bit 0: 1010101010101010 Bit 1:
geringere Frequenz). Die anschließende Dezimation erzeugt wieder das gelesene Wort, diesmal ohne das Bit 0, da aus dem Strom absichtlich entfernt. Stufe1: 0011001111001100 Das erspart eine Filterung mit z.B. Integerwerten, um das hochfrequente Bit 0 zu überlesen. Der Bit-Strom 0 wird quasi abgezogen
-
Thread
IDE mit Fokus auf Assembler für Umsteiger AVR -> STM32
und ich sehe es immer noch mehr als Hobby denn als Broterwerb. Bei mir ist es einfach umgekehrt - C macht mir keinen Spaß. C ist Abstraktion - und ich mache gerne das Gegenteil: alles aufdröseln bis ins kleinste Detail. Es macht mir Spaß das letzte Bit auszureizen. Klar - das ist ein Extrem - produktiv
Christian K. schrieb im Beitrag #5455144: > Bei mir ist es einfach umgekehrt - C macht mir keinen Spaß. C ist > Abstraktion - und ich mache gerne das Gegenteil: alles aufdröseln bis > ins kleinste Detail. Es macht mir Spaß das letzte Bit auszureizen. > Die System Workbench
-
Thread
VU-Meter mit XMEGA
Kanäle - 44.1kHz oder 48kHz Samplingfrequenz (höhere Frequenzen kann man wohl vergessen) - 8...32bit Wortbreite (1...4Byte) Meine Rechnung für den worst case geht wie folgt: Der Soundcatcher der Zeitschrift c't liefert z.B. 32bit Daten. SPI triggert nach jedem empfangenen Byte einen Interrupt.
sogar 14, also 2 IC. Du hast aber 13 20 polige ICs, Typennummer unlesbar, sieht aber aus wie 8 bit paralleles Latch. Damit hast du 104 Ausgänge und jede LED einzeln verbunden. Multiplexing ist dabei weder nötig noch möglich, die andere Seite der LED ist nämlich dauerhaft angeschlossen, sei es an
-
Thread
Wie ein Byte über den UART ausgeben?
Hier noch die Interrupt.c Es geht um die Timer2 ISR und die UART ISR. Sorry für den schlechten Stil. Grüße
auch außer true (1) oder false (0) vielleicht > auch mal eine 3 enthalten. Nö, das ist ein einzelnes Bit - nur 0 und 1 sind möglich. Wir sind hier auf einem 8051, da gibt es bit-adressierbaren Speicher.
-
Thread
Code unleserlich schreiben um Zeilen zu sparen.
Übersichtlich wird es, wenn man solche Monster-Abfragen in eine Funktion wegräumt und die 150 Zeilen durch eine ersetzt: [c] calc_ou(output_mv, &o, &u); [/c] Wenn in dieser Funktion, die nur eine Sache erledigt, 150 ähnliche Zeilen stehen, stört das
o = (output_mv / 100) * 2 + 2; > u =o + 1.; > } Militanter Deleygenerator. Auf nem µC dauern die div 100 deutlich länger als die paar if-Abfragen.
-
Thread
USART Polling
nicht an > jeder Ecke auf das Leerwerden eines Sendepuffers warten mußt? Ich warte halt nicht, [c] if (USART_GetFlagStatus(USART3, USART_FLAG_RXNE) == SET){ [/c] ich frage es zyklisch ab. Übrigens ist es der Empfangspuffer... Dirk B. schrieb im Beitrag #5433185: > wenn im 10kHz Interrupt 'sauber
Noise_Detect abzufragen bei defensiver Programmierung müsstest du die Voraussetzung für Parity_Error (Parity-Bit im _verwendeten_ Protokoll) vorher prüfen und zusätzlich einen 'Framing Error' beim Empfang nacheinander folgender Zeichen abfragen: wenn nach bspw. 1sek kein Zeichen empfangen wurde, dann dürfte sicher
-
Thread
AVR-C Anweisungsreihenfolge NICHT dem Compiler überlassen..
stärken von C/C++. > Ist wohl eher das Gegenteil.. C und C++ geben dir scharfe Waffen. Wenn du dafür nicht stark, schlau oder willens genug bist, gibt es genug Alternativen, mit denen du deine Probleme ebenfalls
bestimmten ram, sonder nur den ges. 'memory' clobbern? Und kann ich statt "r15" auch "Das Register dieser C-Variablen" clobbern? >Mit einem Timer-IRQ kannst du in regelmäßigen Abständen eine Leitung >abfragen und darauf reagieren. >Willst du in möglichst wenigen (einstellig) Takten auf ein Ereignis
-
Thread
Parameter einer mathematischen Funktion verschlüsseln
3 und oder auch 2,3,1 - es kommt dasselbe raus. Die Vorschrift sieht dann so aus: Y = F (a,b,c,d , k(a), k(b), k(c), k(d) ) k(a) ist die Korrekturfunktion für die Werteliste a. Sie funktioniert für alle Messwerte, für die a definiert ist, also z.B. die Menge in Millilitern. Konkret wird hier
Aufgelöst wird es intern in der Rechung, in dem zunächst gerechnet wird: a* = k*(a), b*= k*(c) ... d.h. auf die übergebenden Parameter a,b,c,d werden 4 Entzerrfunktionen losgelassen, die neue a*, b*, c*, d* erzeugen. Diese fliessen dann in die Formel. Die Formel selber ist in C verbacken
-
Thread
switch(Funktion()) möglich?
{ c = getchar (); if (c != EOF) { putchar (c); } } while (c != EOF); [/c] Hier wäre die Abfrage doppelt. Zurück zum Thema: Du fragtest oben nach Vorteilen
Elemente in einem Container (hat in diesem o.g. Beispiel allerdings keine Bedeutung). iv) ... Als C++-Programm könnte das obige Beispiel etwa so aussehen, z.B. für 7-Bit Ascii-Zeichen oder unspezifische Bytes: [c] int main(){ while(auto c = get<AsciiChar>()) { if (!put(*c)) {
-
Thread
Interrupt weckt PIC nicht aus Idle auf
Kastanie schrieb im Beitrag #5413168: > [c] > __builtin_disi(0x3FFF); > IFS3bits.CRYDNIF = 0; > CRYCONLbits.CRYGO = 1; // Berechnung starten > Idle(); > __builtin_disi(0); > [/c] In diesem Fall sehe ich nicht wofür man die _
um Dinge wie "if(!Interrupt) Sleep();" atomar zu machen. Sonst könnte der Interrupt zwischen der Abfrage und dem Sleep-Befehl kommen. Diese Methode ist auf jedem uC anders. Soweit ich weiß nutzt man beim AVR aus, dass der SEI-Befehl Interrupts erst nach der darauf folgenden Anweisung freigibt. Dadurch
-
Thread
NRF24L01 (SPI Problem) sendet nur Status
0. Das Statusregister war beim ersten Kommando 0x0E. Bei jedem weiteren dann wieder immer 0x1C. 1C bedeutet, dass MAX_RT gesetzt ist. "Maximum number of TX Transmit interrupt". Muss dieses Bit gelöscht werden?
Kommando einleite mit CS = Low und erneut 0A auslesen möchte, so sehe ich, dass der Status nun 0x1C ist und ich bekomme vom modul nur noch 0x00 zurück. Egal welches Register ich abfrage. Dieses Verhalten konnte ich auch mit den Logicanalyzer verifizieren. Es handelt sich also wohl kaum um ein
-
Thread
Mehrere vorhandene Funktionen für bis zu 4 UART's nutzen?
- 1); SET_BIT(uartbuf->uart->UCSR0B, UDRIE0); } [/c] Oft hat sich der Hersteller dafür schon was überlegt, denn er muss ja Beispielcode liefern.
pin; SET_BIT(UCSR0B, UDRIE0); } [/c] Um nun eine Zeichenkette einzuspielen nutze ich... [c] void uart_char(UART_P uart, char chrtx) { uart->put_char(chrtx); } void uart_str(UART_P uart, char *buftx
-
Thread
Verzweifelt wegen Drehencoder und Interrupt :/
statt [c]const char table[16] PROGMEM = {0,0,-1,0,0,0,0,1,1,0,0,0,0,-1,0,0};[/c] [c]const char table[16] PROGMEM = {0,0,-1,0,0,0,0,1,0,0,0,0,0,0,0,0};[/c] verwenden. [c]volatile signed char enc_delta;
/ Status-Register wieder herstellen return val; // counts since last call }[/c] [c]#define PHASE_A (beliebige PINPORT & (1<<beliebige_PIN)) #define PHASE_B (beliebige PINPORT & (1<<beliebige_PIN))[/c] Was kann noch einfacher sein?
-
Thread
n++ hier oder dort?
am gcc: Der warnt davor nicht in der Standarteinstellung. Das > braucht -Wall o.ä. $ gcc -O2 u.c -o u ; ./u -1 -1 3 -1 3 $ clang u.c -o u ; ./u -1 -1 2 -1 3 $ tcc u.c -o u ; ./u # https://bellard.org/tcc/ -1 -1 3 3 -1 (Visual Studio 2017): -1 -1 2 3 -1
Maschinerie trotz gedrücktem Not-Aus-Schalter in Gang setzen, wenn einmal ein a*b überläuft. "Aha, c=a*b läuft über. Das merke ich mir mal und - oh: hier diese if-Abfrage benutzt c, da setzte ich als Ergebnis mal - hmm, wie ist es günstiger - "true" ein. Und hier, diese Abfrage.. Oh oh, "c+10". Das
-
Thread
Buch für C-Einstieg
? Natürlich wird man nicht jede beliebige "fette" C++-Klassenbibliothek auf jeden 8-Bit-µC portieren können, dem sind natürlich Grenzen sowohl bei der Codegröße als auch dem verfügbaren RAM gesetzt. Obendrein wird nicht jedes C++-Sprachfeature von
C++-Features auf den Ressourcenverbrauch auswirkt? Wenn es ein gutes Buch mit dem Titel "C++-Programmierung auf 8-Bit-Mikrocontrollern für C++-Unkundige" gäbe, in dem alles Relevante (und nur
-
Thread
HDD Festplatte ATA IDE an AVR µC Mikrocontroller ATmega1284p Assembler - viele Fragen
Register schreiben 6. Den Command Code ins Command Register schreiben 7. Das Status-Register abfragen 8. Wenn BSY = 1, gehe zu 7 9. Das Daten-Register lesen (16 Bit!) 10.Das Status-Register lesen 11.Wenn DRQ = 1 ist, dann gehe zu 9 12.fertsch! Nun zu den ersten Fragen: - wie muss Sector
keinen Geschwindigkeitsverlust haben. So machst du dir nur das Leben schwer. Bit Bang geht auch in C gut und schnell. Ja dein "wait BUSHY" ist auch sehr lustig.
-
Thread
Delay-Funktion STM32: delay_ns()
ist soweit zeitunkritisch, daß man kein ASM und auch keine ASM-Macros braucht, dann bleibt man bei C und gut. Aber auf C-Ebene mit solchen Stunts taktgenaues ASM hinzubiegen ist Murks^3.
M4 bieten keine Out-of-Order-Execution - das heißt das Problem ist prinzipiell lösbar. Wenn eine einzelne Wartezeit mal einen oder zwei Takte länger dauert, ist das kein Weltuntergang. Die C-Funktion im Anhang erfüllt all diese Anforderungen, hat aber gewisse Nachteile. Ich bin sicher, dass es mit
-
Thread
STM32F411RE IDE?
M0+ werkelt, welcher ja die Daten der einzelnen Sensoren verarbeitet(Filter, Fusion usw.) und über die Schnittstellen anbietet, heißt es ja nicht, dass du auch als "konsumierenden" Mikrocontroller einen ARM nehmen musst. Darf man denn mal fragen
Was spricht denn gegen die Lösung: - Sensor mit BreakOut-Board - Abfrage der Daten über i2c - ESP32 (der hat Bluetooth, WLAN onboard für spätere Übertragung) - ArduinoIDE? Oder ist das ganze für eine Bachelorarbeit nicht professionell genug?
-
Thread
ESP8266, SD-Karte freien Speicher und Dateidatum
eindeutig was die Sommerzeit angeht. Wer NTP hat, hat auch die Unix-Zeit. Die funktioniert in 32 Bit mindestens bis 2037, als uint32_t auch bis 2106 mit 1 Sekunde Auflösung. 32 Bit in Hex-Schreibweise sind zufällig 8 Zeichen. Wenn eine Minute Auflösung wirklich ausreicht, kann man auch durch 60 teilen
@Stefan: die Abfrage bei der PTB ist auch ein interessanter Ansatz. Die Zeit ist um die halbe Ping-Zeit falsch, das kann man verschmerzen...
-
Thread
Kann man ATtinys in Reihe miteinander kommunizieren lassen?
> ... wenn du ein paar Vielkanal-ADC (wie zB. AD7490) Ein AD7490 mit seinen 1MSPS dürfte zum Abfragen von ein paar Potis allerdings mehr als großzügig dimensioniert sein. Insbesondere kostenmäßig liegen Analogmultiplexern vor dem µC aber wohl deutlich eher im Budget des TO.
Ich habe einen besseren Vorschlag: Eine UART ist unnötig. Man kann die Betrachtung auf das einzelne Bit richten. Der Algorithmus könnte ungefähr folgendermaßen aussehen: 1. Erkennen, ob ein 0 oder 1 Bit empfangen wurde. 2. Falls Bit erkannt, Bit weiter senden 3. Wenn der Bitstrom endet,
-
Thread
Art der if-Auswahl nur Geschmackssache?
ist bei c = 0x81 der Fall. Also richtig. Wenn du abfragen willst ob Bit7 und Bit0 gesetzt ist, geht das so: if ((c1 & 0x81)==0x81)... Deinen Mangel an Kenntnissen von Bitoperationen kannst du nicht
zu aufwändig um. Für a32 = b16 x c16 muss zwingend b und c auf 32 Bit erweitert werden und eine 32 Bit Multiplikation ausgeführt werden. Mit einer 16 Bit Multiplikation ist a auch nur 16 Bit. In Assembler kann ich aber b16 und c16
-
Thread
PIC32 TRIS Register setzen
einer Speicherposition nicht gibt. Er weiß nur, daß für einzelne Bits kein besonderer Name definiert ist. Man kann sie daher nicht mit Namen ansprechenn. MfG Klaus
Und in der Board.c : TRIS_D1=1; ANSEL_D1=0; D1 wird dann irgendwo in der main.c benutzt.. Ehm zur Performance: Weiß ich noch nicht, hab die config Bits noch nicht eingestellt. Wollte dies eventuell über den "
-
Thread
Ist es noch sinnvoll, mit Controllern zu arbeiten?
glaube ich, das sich die Beschäftigung mit den Controllern alleine (sicher sehr anspruchsvoll ab 32 Bit) zu wenig ist und einem Scheuklappen aufsetzt. Früher hatte ich Freude, wenn ein I2C/SPI/CAN/Display/GSM/BT/USB usw. Treiber richtig funktionierte ;-). Damit kann ich nun nur mehr ein müdes, mitleidiges
gehört jedoch auch zu betrachten was die eigenen Fähigkeiten & Ressourcen hergeben. Wer z.B. kein C oder Assembler mag ist ggf. mit einem MicroPython-fähigen µC besser aufgehoben (z.B. stm32, teensy, nRF51 16bit-PIC). Ein Video welches mir parallel zum lesen dieser Frage durch purzelte: https:/
-
Thread
Absoluter Anfänger
Compilers sind für Privatnutzer wenig problematisch. Debuggen kann man damit einfach, indem man in C einen Breakpoint auf die entsprechende Zeile setzt, der PIC bleibt dann stehen, und du kannst dir die einzelnen Variablen ansehen. Du kannst ein Programm dann schrittweise fortführen, wenn du willst.
Carlo S. schrieb im Beitrag #5358358: > Sollte man „alles“ in C machen ?? Ich würde auf jeden Fall erstmal in und mit C beginnen. Man kann nämlich ganz einfach mit wenigen Befehlen und Funktionen ganz einfach und durchschaubar in C programmieren. Natürlich
-
Thread
STM32F103: Problem mit ChanFat und SD karte
Chris J. schrieb im Beitrag #5357722: > Vermischt ist da nichts, alles auf SPL jetzt [C] void SPI_16Bit() { /* SPI abschalten */ SPI_Cmd(SPI1, DISABLE); /* Setze Bit für 16 Bit Worte */ SPI1->CR1 |= SPI_CR1_DFF; /* SPI wieder einschalten */ SPI_Cmd(SPI1,
Da stimmt was nicht..... [c] SPI_8Bit(); FCLK_SLOW(); CS_LOW(); xchg_spi(0x11); xchg_spi(0x22); xchg_spi(0x33); xchg_spi(0x44); CS_HIGH(); CS_HIGH(); [/c] ergibt
-
Thread
Funktion aufrufen, Wert nicht in anderen Funktionsaufruf verwenden
PORTSETTINGS DDRD = 0xFF; //Port D -> Ausgänge PORTD = 0xFF; //Port D -> Alle Bits auf LOW DDRC = 0x00; //Port C -> Eingänge PORTC = 0xFF; //Port C -> Pull-Ups aktivieren while(1) { if (Debounce(PINC,PINC0) == 1 && Modus > 1)
Stichwort: Objektorientiert programmieren. Geht grundsätzlich auch in C indem man der objekt-spezifischen Funktion einen Zeiger auf die Datenstruktur des Objektes übergibt. C++ und Java machen das unter der Haube ebenso.
-
Thread
Arm Compiler performance Linux vs. Windows
ja von selber > einfach unterlassen. Das "Herumgeschubse" dient dazu, dass nicht 1 Kern auf 150°C hoch geht während die anderen bei 25°C rumdümpeln, sondern damit die Hitze in etwa gleich verteilt ist. mfg
die Sache übrigens richtig übel, denn da bringt sogar die aktuellste Version 7.4 noch einen uralten C/C++-Compiler in Version 4.8 mit, der nicht einmal C++11 unterstützt, geschweige denn C++17. Immerhin bietet RedHat mit dem Developer Toolset DTS eine Möglichkeit, zusätzlich zum uralten Default-Compiler
-
Thread
Fehler zum nachbauen :-)
C Punkte!
In den Anfängen meiner C-Programmierung hatte ich mal aus Spass/Unwissen/Dummheit so einen Zufallswert in die Fuse-Bits geschrieben. Dummerweise reagierte er anschliessend auf keinen Programmierversuch mehr. Habe das Fuse-Bit
-
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
Programmierung: Bresenham f. Plotter/ohne Spiegelung
for 2D Primitives" evtl auch HAKMEM item 177, fuer ein low-level incremental path encoding(wegen uC).
int xpos = u8g2_GetStrWidth(p, text)/2; u8g2_DrawStr(p, POT_X0 - xpos, POT_Y0, text); } [/c]
-
Thread
ATmega Development Boards (Sind die OK?)
kann, sind die Unterschiede nicht so gravierend, wie man vielleicht denkt, wenn man an 8 versus 32bit denkt. Der Unterschied ist für den C Programmierer nicht viel mehr als eine kleine Randnotiz denn mit beiden Serien kann man 8bit bis 64 bit Berechnungen durchführen.
kümmern. Peter King schrieb im Beitrag #5343836: > Ich bin ein Microsoft .NET programmierer mit C# und früher Visual C++ > mit der MFC. > > Angefangen habe ich im Alter von 14 Jahren, als ich auf einem C64 mit Wenn Dir die Bits und Bytes schon vertraut sind und die Programmierung aktueller
-
Thread
Gibt es noch eine kaufbare EAGLE Version ohne Abo? Gesperrt
S T multi-circuit-boards.eu | E G I K S T pcb-center.de | C kein Gerber! ringler.de | 3 E K P S T wedirekt.de | C D E G T ------------------------------------------------
endlos kreisendes (nicht kreissendes) Problem: Man benennt das einfach um, Eagle-A, Eagle-B, Eagle-C, EagleC-1 und schon ist das Problem mit der wiederkehrenden kiCad Kritik gelöst. > > Johannes S. schrieb im Beitrag #5350941: >> Wird Zeit hier das Schloss dran zu machen, das dreht sich mal wieder
-
Thread
STM32F4 SPI Problem
(!(SPI1->SR & SPI_SR_TXE)); [/c] Nils N. schrieb im Beitrag #5325053: > Nach dem Schreiben von SPIx->DR = DATA; musst du warten, bis das RXNE > bit gesetzt ist, was bedeutet, dass Daten empfangen wurden (eben das > Byte bei 8bit
SPI_CR2_SSOE; > oSPI->CR1 |= SPI_CR1_SPE; > } > > uint8_t SPI_Send(SPI_TypeDef * oSPI, uint8_t cVal){ > oSPI->DR = cVal; > while(!(oSPI->SR & SPI_SR_RXNE)); > > return oSPI->DR; > } Konkret sieht es so aus, dass der Controller wieder bei der Abfrage hängen bleibt, ob das RXNE-Bit
-
Thread
LCD auf Steckbrett, Störungen
Idee? https://www.buydisplay.com/download/ic/SPLC780.pdf Hab mich vertan, zuerst muss man den 4 Bit modus aktivieren (Function Set), um mit einem weiteren Function Set (diesmal getrennt auf 2x 4-Bit gesendet) die Zeilenanzahl und den Fonttyp wieder richtigzustellen.
Beitrag #5323176: > Hab mich vertan Ja, hast Du. Es wäre ein klassischer Knieschuss, wenn man den 4-Bit-Modus deshalb nicht erreichen könnte, weil ein oder mehrere Bits gesetzt sind, die gar nicht zu den verwendeten 4 Bits gehören. Der allgemeine Tenor zu HD44780-Displays ist: Man lässt die ungenutzten
-
Thread
Gefahren bei Interrupts
@ me_and_my_µC (Gast) >ausgelöst wird und man beispielsweise gerade mitten in einer Aktion mit >z.B. 32-bit Integern ist (auf einem 8-bit µC), dass dann Fehler >auftreten können, weil die Register vermischt
Also verrennt euch da mal nicht zu weit in die falsche > Richtung. AVR ist Mutmaßung, aber "8-Bit-uC" steht im Eröffnungsposting. Und mir wäre kein 8Bitter bekannt, der 16- oder 32-bit-Werte atomar lesen könnte...
-
Thread
Laufschrift Denkanstöße
uint8_t x, uint8_t y) { glcdSetPageColumn(x/8,y); glcdSendData(0<<(x%8)); } [/C] Fonts die nur eine Page benutzen, schreibe Ich so [C] glcdGotoXY(x,y); for (index=0;index<font.fontPtr[2];index++) glcdSendData(swapBits(font.fontPtr[font.indexNum+index]));
glcdClearPixel(start_line + line, start_col + col); col++; } } } [/c] Jetzt bleibt mir nur noch [c] if (ticker_font[ch][line] & (1<<(TICKER_COLS - offset))) [/c] Was muss ich da abfragen? Das aktuelle Zeichen?
-
Thread
Anfänger bittet um Unterstützung (PIC 12F629)
eines STM32Fxxx (für diejenigen, die meinen, 8-Bit wäre tot und heute nimmt man für egal was einen ARM). Norbert S. schrieb im Beitrag #5317232: > Ich würde Ihnen einen modernen pic18f empfehlen. Dazu den Pickit 3 und > dann alles in C programmieren
Ohne Zweifel werden 8bit-Controller in 100 Jahren nicht tot sein! Ich habe gerade 2 Projekte (Toaster-Controller und Multi-Timer) in C am laufen mit 6pin pic10lf322 and attiny10 beide 0.5KWorte mit 64 bzw. 32 Byte RAM.
-
Thread
GCC: variable may be used unitialized
, bitmap, R.w * R.h, Color.bg, Color.fg); } return EXIT_SUCCESS; } [/c] Der Compiler mahnt in der markierten Zeile an: "warning: 'bits' may be used uninitialized in this function [-Wmaybe-uninitialized]" Meine naive Denkweise wäre: "Mit der Initialisierung bit=0 ist
Performance Ohne if macht das Programm nicht mehr dasselbe: Das if prüft nämlich, ob die unteren drei bits in der Variablen bit gesetzt sind. Die Zuweisung [c] bits = *bitmap++; [/c] wird durchgführt für bit = 0, 1, 2, 3, 4, 5, 6 und NICHT für 7, 15 usw. > 3. Am Schluss der Schleife ein bits =
-
Thread
ATmega32u4 - ADC wirklich nicht unter 2.56V Ref?
an der zu niedrigen Vref, dass der ADC nur 1023 >> liefert? > > Für 1024 braucht man schon 11 Bit. 10bit
Die einzelnen Module müssen dann erst wieder explizit aktiviert werden.]
-
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
HD44780+PIC18F25k22 Rise Time Probleme?
Nö, kein Missverständnis. Is ja auch nich mein erstes, wenn auch in C. Peter D. schrieb im Beitrag #5307087: > Kein > Zugriff darf ohne Wartezeit direkt auf den vorherigen folgen. > Insbesondere im 4Bit-Mode ist ein sauberes Init essentiell. Wie geschrieben, alle
Daher habe ich meine LCD-Lib so geschrieben, daß sie nur Bitbefehle benutzt. Viele MCs können einzelne Bits atomar setzen, d.h. ohne Seitenefekte auf andere Bits des selben Ports.
-
Thread
Wie funktioniert JTAG?
vom eingespeisten Wert im jeweiligen IR-Scheibchen des entsprechenden Core ab. Wenn dir die einzelnen Längen der IR schon aus dem BSDL-File kennst, gibt's ev. noch undokumentierte Befehle zu erraten. Wenn nicht, musst deine Detection per Einzelschrittigem Durchclocken von '1' bits die einzelnen
11 Bits Manufacturer Identity (JEDEC genormt) 1 Bit LSB (immer '1') Die Hersteller-Bits wären also: 110 1100 0000 (= 0x6C0). Jedec spezifiziert hier aber eigentlich nur 8 Bits (siehe https://www.mikrocontroller.net
-
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
SDCC & PIC16F
Sie die Suchverzeichnisse Normalen Compiler-Suche Verzeichnis "C:\Program Files\SDCC\include" PIC normalen Compiler-Suche Verzeichnis für SDCC 3.0 und höher von "C:\Program Files\SDCC\non-free\include" Normale Linker Suche Verzeichnis "C:\Program
18F2680 von Anfang parallel mit SDCC und Microchip Compiler. Durch Definition: #define MICROCHIP_C18 0 und dann Abfragen: #if MICROCHIP_C18 einzelne Teile werden angepasst auf beide Compiler. Das was mir sehr stört beim SDCC ist diese Begrenzung: #2589 Only 85 pointer possible in rom. This is
-
Thread
Hilfe bei Mikroprozessor Klausur
vectored interrupt“ in der Tabelle. -> In beigefügten Bild b) Wie viele Bytes sind zwischen den einzelnen Interrupt Adressen? -> 0x98 bis 0x9C vier Bits = 1/2 Byte?? c) Welche Art von Anweisung wird der Compiler an die Interrupt Adressen platzieren? -> Funktion, festlegen der Interrupt Service
die mit mehreren Quellen polled. Sieht richtig aus. > b) Wie viele Bytes sind zwischen den einzelnen Interrupt Adressen? > -> 0x98 bis 0x9C vier Bits = 1/2 Byte?? Unsinn. Der Vektor geht von 0x98 - 0x9B. Und das sind 4 Bytes. Das passt dann auch ins 4er Alignment für die Adrssierung. 0x9C
-
Thread
RFM69 OOK - ein Bit zuviel zwischen Transmissions
I/O für Debugging) Im speziellen kann man sehen: - scope07.png: Sieht so aus wie man sich [0x3C, 0xAA, 0x0C] vorstellt. - scope08.png: Hier sieht man das zusätzliche HIGH-Bit vor 0x3C (von Cursor markiert), Zusätzlich ist das letzte Bit von 0x0C zu lang, und zeigt, dass OOK so lange das letzte
nehm ich die gerne :D @fixxl: Ich hab meinen Testcase entsprechend geändert das unerwünschte Bit ist aber leider immer noch da. sieht jetzt in etwa so aus: [c] void sendFunc2(int debugPulses, byte byte1, byte byte2, byte byte3) { // send block of 3 bytes, pre-fill FIFO and change to TX