-
Thread
Drehgeber auf Atmega 88 wandeln
Höner schrieb im Beitrag #2013439: > Gibt es irgendwo eine detailierte Doku, was die Befehle im einzelnen > bedeuten, gerade die C-Befehle? Z.B. "+=", "^=" oder "&". > [[AVR-GCC-Tutorial]] > Mein Ziel ist es den Code soweit zu verändern, dass ich zwei Drehgeber > anschliesse und die Ausgabe
Höner schrieb im Beitrag #2013439: > Gibt es irgendwo eine detailierte Doku, was die Befehle im einzelnen > bedeuten, gerade die C-Befehle? Z.B. "+=", "^=" oder "&". Das steht in jedem C-Buch. Das AVR-GCC-Tutorial ist da weniger hilfreich, da es bereits von gewissen Grundkenntnissen in C ausgeht
-
Thread
Verständnisfrage ==
Mikrocontroller. > > Folgende if()-Abfrage funktioniert: > > [c] > if( ( A & B ) == 0x00) > { > mach_was(); > } > [/c] > > Wenn ich aber schreibe: > > [c] > if( A & B == 0x00) > { > mach_was(); > } > [/c] > > Wird
logischen. > > Doch, & und | sind arithmetische Operatoren, denn sie rechnen mit > Zahlenwerten. C spricht hier nicht von arithmetischen, sondern von bitweisen Operatoren. Sie arbeiten ja auch nicht mit den Zahlenwerten, sondern nur mit den einzelnen Bits. Ich würde & und | nicht als arithmetische
-
Thread
formell korrekte Summation von Einzelbits
Vektor ist der Platzhalter für die Länge - das "downto" habe ich einsetzen müssen, weil er ein einzelnes Bit nicht nimmt. Obwohl es Phasen gibt, in denen bis zu 16 bits High sind, zählt die Summe nur bis 8 hoch. Es scheint einen versteckten ÜBerlauf zu geben, den ich mir nicht erklären kann, weil
Generell summiert man die Bits einer seriellen Schnittstelle am Besten dann auf, wenn man jedes einzelne empfängt. Nicht erst danach, wenn alle empfangen sind. Wenn das Kind aber schon im Brunnen liegt, dann sieh dir das an:
-
Thread
Interruptroutine funktioniert nicht richtig
0 = 300us/300us Puls/Pause [c] void Empfang_Bit(void) { zaehler=0; status=1; do { zaehler++; if (zaehler > 10005) { status=0; break; } } while (bit_is_set(PIND,PD2
<7;bitcnt++) { Empfang_Pause(); if (status==0) {rxbyte=0;return;} Empfang_Bit(); if (status==0) {rxbyte=0;return;} } } [/c] Gruß Günter
-
Thread
woher nehmt ihr boolean?
Macro zu definieren? > und zum anderen kann man dann auch mal die Variable > schnell auf FALSE abfragen. Konsequenterweise müsstest du dann aber auch folgendes schreiben: [c]Boolean flag = TRUE; if( (flag == FALSE) == TRUE ) ...[/c] Ein boolean typ is sicher hilfreich, aber *nicht* für Vergleiche
Namen gibt. Boolesche Funktionen haben oft den Präfix "is", wie bspw. in isPrime oder is_convex. Die Abfrage [c] if (isPrime(number)) ... [/c] liest sich dann fast schon wie Prosa, und ein zusätzliches ==true wäre doppelt gemoppelt und würde die Sache eher unübersichtlicher machen.
-
Thread
Pausen in c
40ms...) verwende. Dieses System dient bei mir als Betriebssystem des Controllers. Innerhalb der einzelnen Zeitscheiben werden die Funktionsaufrufe eingebaut. Zum Beispiel: Abfrage eines Temperatursensors wird in der 1280 ms - Zeitscheibe aufgerufen. Zeitkritischere Anwendungen werden dann in der
Mal eine Frage: Wie macht ihr denn die Pausen bei der I2C-Kommunikation z.B. Auch über Timer?
-
Thread
Reverse Engineering eines LIN Bus
mit im Frame drin steckt, dann können das unter der Annahme dass Spannung passt nur die ersten 10 Bits sein. Da die negativ werden kann ist es wohl ein Signed Int. Die nächsten 14 Bits sind dann Spannung, und die letzten 8 Bits Temperatur. Kannst Du das mal testen? [code] 00D#0020C84E: 4E C8 20 00
Kannst Du das mal testen? Sollte rauskommen 14 Bit Strom -7,9A (Auflösung 1mA), 10 Bit Spannung 14V, 8 Bit Temperatur 2,5°C [c] // Powered by ChatGPT void decode(const char* frame, float &Ubatt, float &Ibatt, float &Btemp) { // "00D#2C20E055
-
Thread
Frage zur Durchlaufzeit und Speicher von 15 If-Schleife
ich hab mal wieder eine Frage. Wenn ich mit einer oder mehreren If-Schleife/n 15 Variablen abfragen möchte, es kann immer nur eine Abfrage von 15 wahr sein, kann ich ja eine If-Schleife schreiben in der alle 15 Variablen mit ODER Verknüpft sind und ich kann 15 einzelne Schleifen schreiben in der
nichts wiederholt, dort wird eine Auswahl getroffen. Darum ist ein if keine Schleife, sondern eine Abfrage oder Auswahl. > möchte, es kann immer nur eine Abfrage von 15 wahr sein, kann ich ja > eine If-Schleife schreiben in der alle 15 Variablen mit ODER Verknüpft > sind und ich kann 15 einzelne
-
Thread
SPI-Bus mit sieben ATMEL 8515
es da 2 Möglichkeiten für dein Vorhaben. 1. Das ist die SPI SPEC Variante Verbinde bei allen µC die Signale MISO, MOSI, CLOCK und zusätzlich vom Master ein einzelnes Signal zu jedem µC um ihn anzusprechen(Chipselect). Somit kann immer nur EIN µC angesprochen werden. Skalierbar ist das nur soweit
verfügbar sind. 2. Variante Die SPI ist nichts anderes als ein Schieberegister. Schalte die µC in Reihe hintereinander. Dann legts du im Ram 2 Stukturen an, die die Größe hat von "Anzahl der µC" * "Registergröße" also zb 8µC mal 8 Bit(1 Byte) = 8 byte. Stuktur 1 ==> TX ; Stuktur 2 ==> RX .
-
Thread
Wie geht man ein Assemblerprojekt an ?
Bastler schrieb im Beitrag #2524160: > In Bits und Bytes zu denken tut kein bisschen weh Das kannst du in C genauso gut wie in Assembler. Aber geh dein nächstes Projekt mal mit einer Zeitvorgabe an. Und überwache mal die Zeit die du wirklich
nicht Jedem wurde es an der Uni als "Allgemeinwissen" eingetrichtert. Und wer mit irgendeinem dieser 8-Bit-Homecomputer aufgewachsen ist, der ist auch nicht mit C konfrontiert worden, sondern mit Basic und ggf. ASM. Tja, wer weder C noch Basic, noch ASM kann, und nur hobbymäßig kleine AVRs programmieren
-
Thread
ADC Vergleichen und Variable ändern
das ist es Lb1 = Adcl 'Abfrage des Lowbits Hb1 = Adch 'Abfrage des Highbits Hb1 = Hb1 And &B00000011 'Highbit mit 3 und verknüpfen um eventuele Störsignale ich ein zu Beziehen Hb1 = Hb1 * 256 'High bit * 256 um 1023 bit zu bekommen A = Lb1 + Hb1 'Variable A = Gesamt bit High- und Lowbit D = A * 100 'Umwandlung von A für die Berechnung der Temperatur Y = D - C X
-
Thread
Benötige Hilfe beim programmieren eines Microkontrollers!
verwirklichen, die eben bitweise arbeiten, oder man hat vordefinierte Bitfelder, die den zugriff auf einzelne Bits erlauben. Soll also PORTE2 als Eingang genutzt werden setzt man dem nach nur Bit 2 von DDR2 auf den entsprechenden Wert und lässt die anderen erst mal so, wie die Entwickler des Controllers
Im AVR GCC Tutorial sind die Ports für mich wunderbar erklärt. Man schaut sich die C Bsp. Codes an und weiß Bescheid was man machen muss. PDIP Gehäusepin 9 wäre PB.6 [c] DDRB |= (1<<DDB6); // PB6 Ausgang, Bit setzen PORTB |= (1<<PB6); // PB6 einschalten, Bit setzen PORTB &
-
Thread
DS18B20 Verkabelungs od Software Problem
temperatures...DONE Temperature for device: 0 Temp C: 23.00 Temp F: 73.40 Temperature for device: 1 Temp C: -127.00 Temp F: -196.60 Temperature for device: 2 Temp C: 24.31 Temp F: 75.76 Temperature for device: 3 Temp C: 23.69 Temp F: 74.64 Requesting
// method 2 - faster float tempC = sensors.getTempC(deviceAddress); Serial.print("Temp C: "); Serial.print(tempC); Serial.print(" Temp F: "); Serial.println(DallasTemperature::toFahrenheit(tempC)); // Converts tempC to Fahrenheit
-
Thread
8051 7 Seg. Zähler Multiplex
Segmente zu steuern... -> ??? > Wat denn nu? :) also der Schaltplan stimmt schon, nur habe ich eine µC-Platine und eine 7-Segment-Platine auf der µC-Platine habe ich 4 Ports, die ich frei belegen kann. auf der 7-Segment-Platine habe ich Port1 (Daten) und Port2 (Ansteuern des einzelnen Segmentes)
Zeitschleife mov A, #0d Zeit1: dec A cjne A, #0d, Zeit1 mov A, #0d ret end [/c] Mit den Tastern fange ich jetzt an, habe schonmal den Startbefehl hinbekommen. Die Stopp Abfrage soll den Timer anhalten bzw. wieder starten. Die Zwischenzeit Abfrage soll die Ausgabe anhalten
-
Thread
Programmierung einer Laufschrift
können, wenn du µC programmieren willst. Ist eh immer das gleiche Prinzip: mit einem UND und geeigneter Maske erzwingt man Bits auf 0. Mit einem ODER und geeigneter Maske erzwingt man Bits auf 1 zb [c] leds[0]
musst du schon sehen können. > Warum werden die Bits im MSB so plötzlich gelöscht? weil du bei [c] i = j; [/c] alle Bits von i zugewiesen haben willst! ist i ein long Wert und j ein int, dann willst du den kompletten i überschrieben haben.
-
Thread
74HC573 als Eingangserweiterung
Beitrag #5553238: > Ich würde auch Schieberegister verwenden, diese allerdings per Software > mit Bit-Banging abfragen. Dabei kann man mühelos auf ziemlich hohe > Übertragungsraten kommen - auf jeden Fall wesentlich mehr als per > USART+Interrupt. Das möchte ich mal sehen, wie Du mit Bit-Banging
Zumindest in Assembler ist es bequem zu schaffen. Selbst F_CPU/4 ist immer noch deutlich schneller als Bit-Banging. F_CPU/4 sind 64 Zyklen alle 2 Bytes, das reicht bequem für nen Interrupthandler in C.
-
Thread
MSP430F2012 LED Blinken lassen
machen soll. Ich danke dir schon jetzt für deine antwort. Nun, das ist lediglich das Setzen der einzelnen Bits im Register TACTL. Das ist aber alles genau im User Guide beschrieben! Das einzig "ungewöhliche" ist die am Anfang vielleicht etwas verwirrende Schreibweise TASSEL_2 im Unterschied zu TASSEL1 Das eine sind die einzelnen Bits (TASSEL0 und TASSEL1), während TASSEL_x die Kombination beider Bits repräsentiert: [c] TASSEL_0 = 0 TASSEL_1 = 0 + TASSEL0 TASSEL_2 = TASSEL1 + 0 TASSEL_3 = TASSEL1 + TASSEL0
-
Thread
Frage zum ADC Modus
Würde das so klappen? [c] //ADMUX beschreiben, also Channel 0 und Referenz Auswahl //AVCC with external capacitor at AREF pin //ADLAR auf 1 -> Ergebnis is rechtbündig, da ich nur 8 bit brauche ADMUX &= ~(1<<REFS1) & ~
warte bis ADCS = 0 -> Converison fertig gelesener_wert = ADCH; //Nur ADCH Register kopieren, nur 8bit auflösung nötig } [/c]
-
Thread
AVR Einstieg / Probleme mit Programm Interrupt
Port komplett beschreibst. D.h. dein nächster Punkt lautet: Einzelbitoperationen an einem Port Bit setzen (am Beispiel Pin 3) PORTB |= ( 1 << PB3 ); Bit löschen PORTB &= ~( 1 << PB3 ); Abfragen, ob Bit gesetzt ist if( PIND & ( 1 << PD4 ) )
setzen (am Beispiel Pin 3) > > PORTB |= ( 1 << PB3 ); > > Bit löschen > > PORTB &= ~( 1 << PB3 ); > > Abfragen, ob Bit gesetzt ist > > if( PIND & ( 1 << PD4 ) ) Das habe ich natürlich auch schon umgesetzt. Macht das schreiben schon deutlich einfacher
-
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
Aus Zeichen die Hex-Kombinationen bestimmen
Licht in die Sache. Du hast ganz einfach 2 Hex-Digits vorliegen. Beide zusammen ergeben einen 8-Bit Wert und in diesem 8 Bit Wert hat jedes Bit eine spezielle Bedeutung. > Wie kann ich das nun programmiertechnisch so umsetzen, dass wenn bspw. > das B über den UART flitzt, mein C-Programm erkennt
uint8_t toBin( char c ) { if( c >= '0' && c <= '9' ) return c - '0' return c - 'A' + 10; } Damit kannst du von jeder der einzelnen Stellen die binäre Version bekommen, die zum jeweiligen Hex-Digit gehört.
-
Thread
Optimierung bei if-Abfrage mit kurzem Rumpf
// toggle clock SCL_PORT &= ~(1<<SCL_PIN); SCL_PORT |= (1<<SCL_PIN); // next bit temp <<= 1; } } [/c] Wird soweit mit -Os ganz nett übersetzt in sbi, cbi etc. Nur die if-else-Abfrage mit den extrem kurzen Schleifenrümpfen (1 Assembler-Befehl) würde ich in Assembler
von avr-gcc besser geworden (aktuell hier 4.3.3)? Oder gibt es eine geschicktere Variante, das in C zu schreiben? Zwei getrennte if-Abfragen (einmal auf gesetzt, einmal auf gelöscht) habe ich ausprobiert, kompiliert zu dem gleichen Code wie die Variante mit if-else - obwohl eine einzelne if-Abfrage
-
Thread
Warum ist das so? (USART)
auch der Sache nachgehen. @GoZu Du kannst ja, um das Problem einzugrenzen, versuchhalber die [c] uint8_t USART_check(void) [/c] so abändern: [c] uint8_t USART_check(void) { return 1; } [/c] Wenn dann noch immer ein Unterschied ist, dann liegt es wohl nicht an der Abfrage des USART
Wahrheitswert interpretiert. Vielleicht ist Dir die Funktionsweise nicht ganz klar. Wenn man eine if-Abfrage macht, z.B. [c] if(Bedingung) Anweisung; [/c] Dann wird /Anweisung/ genau dann ausgeführt, wenn /Bedingung/ wahr (also nach C-Standard nicht Null) ist. Wenn Du für /Bedingung/ jetzt Dein
-
Thread
"Universelle Tastenabfrage" auf Attiny2313
Okay, leider durchsteige ich schon diese Zeile nicht: [c]TCCR0 = 1<<CS02^1<<CS00; // divide by 1024[/c] Ich verstehe, dass Bits in dem Timerregister TCCR0 gesetzt werden, aber was bedeutet CS02 und CS00 ?
mehr, mal ins Datenblatt zu schauen.. Im Datenblatt sieht es so aus, als wären die Clock Select Bits beim Atmega16 und Attiny2313 die gleichen. Ich habe jetzt [c]TCCR0 = 1<<CS02^1<<CS00; // divide by 1024[/c] gegen [c]TCCR0A = 1<<CS02^1<<CS00; // divide by 1024[/c] getauscht. Da kommt
-
Thread
Assembler und NOP
jo, allerdings habe ich ein Abfrage beim Einlesen der Pins: z.B. [c]if (c_Pina1) uint_Rohwert12bit_Druck |= (1<<13);[/c] wenn c_Pina1 = 0, dann würde sich die Laufzeit unterscheiden , da uint_Rohwert12bit_Druck |= (1
noch ne Alternative ein: Soll ich lieber für jeden Taktzyklus eine Variable spendieren, und die einzelnen Bits erst nach der kompletten I2C-Kommunikation zusammenbasteln, dann würde ich mir die NOPs im else-Zweig sparen...?!
-
Thread
24 Bit über Pin auslesen Takt/Daten ohne Interrupt
Laut Diagramm sind das 15 Bit je 100µs. Das sind bei 8MHz 53 Zyklen je Bit, das ist in C zu schaffen. Peter
Peter Dannegger schrieb im Beitrag #1730168: > Laut Diagramm sind das 15 Bit je 100µs. Das sind bei 8MHz 53 Zyklen je > Bit, das ist in C zu schaffen. > > > Peter Nein, sind schon 24 Takte pro Sequenz. Das Bild ist sehr Breit vielleicht musst du das Bild nur vergrössert
-
Thread
Atmega8 C Relais ansteuern
Ausgangsportpin unabhängig von den anderen Portpins auf wahlweise 0 oder 1 schalten kann. Denn so etwas [C] PORTB = (1<<0); [/C] artet ganz schnell in einen Albtraum aus, wenn man ständig über alle möglichen Schaltzustände an diesem Port Buch führen muss. Bit auf 1 setzen [code] PORTB |= (
Erlenen von C nicht herum. Dabei geht’s dann aber nicht mehr um dünne Heftchen und einzelne (einfache) Operationen.
-
Thread
bit_test Funktion
Moin Ich habe bemerkt, dass in manchen Compilern eine bit_test und bit_set Funktion verfügbar ist, in C18 leider nicht. Hat jemand die entsprechende grad bei der Hand? result=bit_test(byte,bit); bit_set(byte,bit); vieln Dank..
Aus Kompatibilitätsgründen würd ichs immer so machen: Bit setzen: b |= (1<<n); Bit löschen: b &= ~(1<<n); Bit abfragen: if ( b & (1<<n) ) {...} Ist leicht lesbar und 100% kompatibel, da Standard-C. Also keine Bibliotheken nötig!
-
Thread
I2C Slave mit dem Attiny 841
geschaut und gesehen das es nur Slave erlaubt. Bin gerade dabei die Register anzuschauen und die einzelnen Funktionen durchzugehen und hoffentlich auch zu verstehen c-hater schrieb im Beitrag #5877099: >> Bei anderen Beispielen mit Code wird I2C Master oder TWIslave mit c und >> verwendet. Das hast
halt anders als die anderen Attiny. Mir geht es eigentlich um das das ADC und die übertragung mit I2C. Habe schon einiges dazu programmiert. Leider klappt die übertgaung nicht so wie sie soll. Im Master habe ich eine Abfrage drin die die Adresse des Slave überprüft ob sie vorhanden ist. Dies Abfrage
-
Thread
Brötje ISR Plus Kommunikation / LPB
> Bytes 10+11 von HEX in Dezimal umwandeln ("01FF"=>511) und durch 64 > teilen (511/64=>7,984375°C). Ebenso ist hier noch offen, wie die > negativen Zahlen dargestellt werden. Negative Temperaturen: Könnte ein ganz normaler "signed Integer(16bit)" sein. Wenn das höherwertigste Bit gesetzt
sofort auf mit dem Senden und fange oben wieder an. Danach folgen nach gleichem Muster die folgenden Bits, Bit 7..0, Parity und Stop Bit. Ich habe das auf einem AVR mit Software-Uart gemacht. Damit kann eine Kollision sofort erkannt werden, da ja jedes einzelne Bit überwacht wird. Wenn man den Hardware-Uart
-
Thread
[C] Böse Falle: Datentyp korrekt angegeben, falscher verwendet
implizites > printf("%u\n", (unsigned)x); > drin steckt. unsigned habe ich jetzt weggelasen. [c] int32_t x = (int16_t)30000*(int16_t)2; printf("%d\n", x); [/c] Und wieder kommt das richtige Ergebnis raus. Falk B. schrieb im Beitrag #5764043: > Nö. 16 Bit * 16 Bit sind 32 Bit. [c]
diese Warnung weg hätte, ohne die Variablen von 8 auf 16 Bit aufzublasen. Das hat überhaupt nichts damit zu tun, ob C das besser kann. Und wenn Du mal in das Kompilat schaust, wirst Du merken, dass C hier einfach die if-Abfrage wegoptimiert, weil unreachable
-
Thread
I2C per Interrupt auf Atmega32
einzeln setzen und zuletzt das TWINT Bit setzen (um die Interrupt-Flag zu "clearen"). Problem an der Sache: Es funktioniert nicht. Wenn ich allerdings das TWCR explizit mit dem gesamten Bitmuster setze
Also das TWEN-Bit muss ja auch jedesmal mit gesetzt werden. Ich habe auch die Erfahrung gemacht, daß das einzelne setzen und löschen des Bits im Kontrollregister nicht funktioniert sondern das ganze Register auf einen
-
Thread
8 Bit in Struct als Byte ansprechen
@ Josef: >Du machst das sehr umständlich. Der Zugriff auf Bits mittels >Structuren kostet einiges an Rechenzeit. Bei uC ohne Bitfunktionen mag dass sein, aber beim M16C wird aus Settings.Wert1=1 bset 0, 543h (bedeutet: setze Bit 0 an Adresse 543h) @OldBug
): 136:buskoppler.c **** led_ddr |= _BV(led_bit); 414 .LM18: 415 004e 8F9A sbi 49-0x20,7 137:buskoppler.c **** led_port |= _BV(led_bit); 417 .LM19: 418
-
Thread
CP/M auf ATmega88
@Joe: 256k x 4bit Part number V53C104P-70 Description HIGH Performance, LOW Power 256K X 4 BIT FAST PAGE MODE CMOS Dynamic RAM; DIL-20 Davon habe ich ca. 34 Stück hier liegen. Dann habe ich noch GM71C4256,
hab ich die Schaltungen Stück für Stück in Betrieb genommen. Dabei wurden kleine Testprogramme (in C) für die einzelnen Funktionen geschrieben oder genutzt: Was bisher getestet wurde: * ATmega128 (16 MHz Takt) --> funktioniert * UART mit FTDI und 115200 kBit/s --> funktioniert * SD-Karte (nachdem
-
Thread
2bit array[ ] ?
jetzt vor jedes Bit/Bitpaar noch "unsigned char stehen" ? Wenn ich [C] struct { unsigned char bStatus_1:1; // 1 Bit für bStatus_1 } x;[/C] definiere, ist dann sizeof(x) == 1 ? Sprich 8 Bit groß, nur 7 Bits
@tronic Dafür gibts nichts in C. Es gibt kein 1-Bit-Array. @Simon > Warum muss denn jetzt vor jedes Bit/Bitpaar noch "unsigned char > stehen" ? Bei einem einzelnen Bit macht das zugegebenermassen nicht wirklich Sinn. Aber
-
Thread
Welche Programmiersprache für Windows-Oberfläche?
Strings äußerst ineffizient. Deswegen legt man die Zeichengöße auf einen festen Wert von 8, 16 oder 32 Bit fest. Die 8- und 16-Bit-Darstellungen sind ein Kompromiss zwischen der Anzahl darstellbarer Unicode-Zeichen und dem Speicherplatzverbrauch. In C++ stehen beide Alternativen zur Verfügung, in C# die
effizienteren Datentyp /Text/, der Strings wie C++ und C# als 16-Bit-Array speichert.
-
Thread
Hunderte Messungen mit ADC: Eigenen ADC oder integrierten ADC im µC?
nicht ausreichend ist. -Bei externen Wandlern kommen zu den Umschaltverzögerungen auch noch Abfragen nach: "Are you ready" hinzu. -Darüberhinaus wollen die Daten auch noch in die CPU geschaufelt werden. Meist seriell, aber für beliebig viele I²C Schnittstellen reicht's auch nicht. Also ein Eigenbauprotokoll
getrennte ADC Peripherien hat. Wenn nicht, kannst du auch immer nur auf einem Kanal messen. Den uC würde ich an deiner Stelle nach der externen Beschaltung auswählen. Wenn du noch funken willst, dann kann es bei so einer 70er 8Bit Krücke schnell an Rechenleistung fehlen. Dann solltest du auch über
-
Thread
schwierigkeiten passenden Bus zu finden
ergibt alleine an Daten für 100 Slaves x 3Byte(RGB)= 300Byte, macht bei 30Hz x 300Byte = 9kByte/s => 56kBit/s hinzu würde noch die Abfrage bzw. das Senden des Sensorwertes kommen. Die erste Idee kam mir mit I2C. Leider hab ich nur theoretisch Erfahrung mit diesem Bus und bevor ich unnötig in Bauteile
dagegen. Nur die fertigen Streifen sind etwas unhandlich. Man könnte aber die neu verfügbaren einzelnen 8mm LEDs nehmen http://www.mikrocontroller.net/topic/325107#new (Da ist ein ws2811 drin) und davon 2-3 Stück pro Feld, dann könnte man auch mit 3x255 dimmen, also etwas mehr wie 9 Bit, statt
-
Thread
Schaltuhr 6 Kanal
nur 12 Alarmzeiten maximal sein können. Wobei man es in Tage Stunden und Minuten nacheinander abfragen kann und immer den nächsten rausnimmt. Dann müssten 6 Abfragen immer reichen. Der Aufwand in einer Abfrage dauert keinen Bruchteil einer Sekunde und die Sortierung würde nur dazu führen, dass nach
ich hätte eben die Zahlen direkt in BCD gespeichert. Daher wären die 1 und 10 er ja eben jeweils 4 Bit. Daher ein Byte für die Zahlen der Minuten usw... könnte ich mir aber auch umstricken. Wobei 32 Bit auch 4 Byte sind... aber ich brauche ja das Jahr nicht... wer schaltet schon einmal im Jahr!?
-
Thread
EEPROM 24C04
Ich habe mal das Datenblatt zum MSSP-Modul im PIC (für I2C zuständig) durchgesehen. Auf der Homepage von sprut haben sich zwei Fehler eingeschlichen. Zum einen war das Modul gar nicht eingeschaltet und zum anderen war beim lesen ins EEPROM nach der 7-Bit-Adresse
der anderen Seite dachte ich, das man hier die "Speicherbank" im Chip umschaltet und nicht für die I2C-Adresse verwendet wird. So richtig steht das aber auch nicht da. Ich hatte den Pin auf Masse liegen, aber selbst 2 KByte kann ich doch mit nur einer 8Bit Adresse nicht ansprechen!?. Ich übersehe doch
-
Thread
RFM12 - Funkmodul
Fehler, diesmal im Datenblatt: Beim Receiver Control Command steht als Standardwert 0x9080 Die Bits sind aber als 1100.... beschrieben. Dier ergibt aber 0xC... Vermutlich sind die Bits falsch. 0xC wäre nämlich ein anderes Register.
Daten als Byte Paket über SPI an das Modul. Dieses sendet dann mit der eingestellten Baudrate die einzelnen Bits nacheinander.
-
Thread
ADC - Wie schnell aktualisiert der? Ist ein Oszi möglich?
.Ideal wäre ein 8-16 bit Ausgang) -Andere Sache: mehrere AD's (egal woher) nacheinander messen lassen, damit würde man die abfrage-frequenz erhöhen.Könnte sowas gehen? @Hauke Radtki : USB-SERIELL-Wandler: meinst du, dass
ohne µC aus. Wenn man einen parallelen 8 Bit ADC direkt an den LPT anschließt und den PC die restliche Arbeit machen lässt.
-
Thread
mehrere Taster gleichzeitig abfragen (ATTINY 85)
Hallo Leute, ich beschäftige mich seit einigen Tagen mit folgendem Problem: ein uC (tiny85), eine LED, zwei Taster. Wenn TASTER1 gedrückt -> LED soll langsam blinken Wenn TASTER2 gedrückt -> LED soll schnell blinken funktioniert soweit, aber: Wenn TASTER1 und TASTER2 gedrückt -> LED soll abwechselnd kurz und lang aufleuchten. Das habe ich noch nicht hinbekommen. Weiterhin: Ich drücke TASTER1, LED leuchtet lang. Währendessen drücke ich TASTER2 und möchte dass die LED, nachdem sie eine lange Periode geleuchtet hat, nochmal kurz aufleuchtet. meine Abfrageroutine sieht so aus: [c] void request
-
Thread
char Buffer[7] Resetten, löschen.
RXCIE0)|(1<<RXEN0)|(1<<TXEN0); /* Set frame format: asynchronous, 8data, no parity, 1stop bit */ #ifdef URSEL0 UCSR0C = (1<<URSEL0)|(3<<UCSZ00); #else UCSR0C = (3<<UCSZ00); #endif #elif defined ( ATMEGA_UART ) /* set baud rate */ if ( baudrate & 0x8000
mit Pointermanipulation. Dann muss man keineen Datentyp für die Indexvariable festlegen. Reichen 8 Bit, oder sollen es doch 16 Bit sein. Mit Pointern stellt sich die Frage nicht. Da die Funktion allerdings sowieso noch ausgebaut werden müsste [C] void uart_gets( char * Buffer, int BufferSize )
-
Thread
lcd routines umgeschrieben -fehler
Datenbyte (bei 8 bit LCD Ansteuerung) direkt auf den Port zu legen. Bei 4bit Ansteuerung erst die eine hälft dann die andere. ich habe dafür auf einen ATmega8 die DB4-7 den PortC genommen, für die Restlichen Leitungen
muß leider die bits einzeln abfragen bzw. zerlegen dazugehörige platine ist leider schon fertig bestückt (viel bauteile) (einen platinenfehler kann ich mit ziemlicher sicherheit ausschließen) alles ausgemessen display
-
Thread
Möchte IoT-Erfahrung aufbauen
Hallo allerseits, kurz zu mir: Einige Erfahrung in uC sind vorhanden, Board Design und Routing ebenfalls, einigermaßen zielführende C-Kenntnisse ebenso. Was ich aber noch NIE gemacht habe: 1.) Webprogrammierung in jedweder Facette 2.) IoT Letztenendes
/schlechte Fehlerbehandlung, ...). Es gibt einen Compiler, der normalen Brainfuck-Code in einen C-Formatstring umsetzt. Wenn also der Code irgendwo ein schlecht ausgewürfeltes printf() macht, hast du direkt Remote Code Execution. > Wenn ich User/Passwort abfrage, ... ... landest du ganz schnell
-
Thread
Zuweisungen überschreiben in VHDL
welche "Adresse" anliegt, werden verschiedene Daten ausgegeben. Oft ist bei dem Datenwort nur ein Bit oder einzelne Bits belegt. Früher wurden in jedem Fall alle nicht verwendeten Bits mit '0' beschrieben. Jetzt schreibe ich einmal vor der Case-Verzweigung [vhdl] Datenwort<=(Others=>'0'); [/vhdl
folgende Befehl verarbeitet werden kann oder im Buffer / FIFO Platz ist. Kann man natürlich auch abfragen. Wenn sich das zwischen abfragen und und Befehl senden zum schlechten ändert ist die abfrage vorher natürlich zwecklos. Was meinst du mit synchronem C++-Programm? >> Nach meinem Verständnis