-
Thread
LON Bus Windhager mitlesen/steuern
Yeah one tick is a bit low. Thats the reason why it signals a corrupted packet. Ich hab mittlerweile die C# sourcen überarbeitet und eine GUI gebastelt. Leider erst mal hardcoded auf 192.168.1.255 als Adresse. (bis ich
dissecting the payload. The APDU really just starts with 1 or 2 bytes (depending on the first bits, see Figure 10.2) followed by the payload of that specific NV. I have a list of NVs for: WVF V 3.51 InfoWIN FW V 2.60 FireWin V 3.10 PMX v2.7 UML C1 V 3.51 VarioWin (?)
-
Thread
[C++] Code-Optimierung auf AVR
? das bit kann doch nur 0 oder 1 sein, damit reicht das else [c] ISR(PCINT1_vect) { static bool update[7]; static uint16_t timer[7]; uint8_t tmp = PINJ; for (uint8_t i = 0; i < 7; i++) {
eventuell noch die 16bit-rechnung rausziehen aus der ISR zum kürzen der maximalen Takte innerhalb der ISR. Ungprüft: [c] ISR(..) { static uint8_t prev =0; uint8_t pin ; uint8_t i,mask,changed ; Pin
-
Thread
ATmega8: Das Buch
gesetzt. Das passt nicht zusammen. Am besten diesen Abschnitt komplett löschen. "Man kann in C auch einzelne Bits manipulieren, nur wer braucht so etwas schon in halbwegs normalen Programmen? Schlicht niemand! Wer hat das Problem, dass er aus seinem PC auch noch das letzte bisschen Geschwindigkeit
Helmut S. schrieb im Beitrag #3938862: > "Man kann in C auch einzelne Bits manipulieren, nur wer braucht so etwas > schon in halbwegs normalen Programmen? Schlicht niemand! Wer hat das > Problem, dass er aus seinem PC auch noch das letzte bisschen > Geschwindigkeit
-
Thread
Conways Game of Live zu langsam auf Z80
vermeiden. Die Z80 CPU ist nicht optimal für C, denn C wurde für CPUs mit mindestens 16 Bits definiert. AVR hat übrigens ähnliche Probleme, das sieht da auch nicht so arg viel anders aus. Entweder man kennt die Regeln und passt sich an, oder man
4B55 EE 80 [ 7] 247 xor a, #0x80 4B57 248 00157$: 4B57 F2 5C 4B [10] 249 jp P,00105$ 4B5A 2E 00 [ 7] 251 ld l,#0x00 4B5C 252 00105$: 4B5C CB 7A [ 8] 254 bit 7, d 4B5E 28 04 [12] 255
-
Thread
MIDI-Protokoll
verarbeiten und an einem Raspberry weiterschicken. > > Datenprotokoll: MIDI > Anwenderprotokoll: I2C Aha, wieder jemand, dem man alles einzeln aus der Nase ziehen muss. Also, der Sensor sendet MIDI? Der Raspberry empfängt MIDI? Nu sag doch mal bitte, wie die Kette aufgebaut ist, und wo da C++ ins
www.ucapps.de hier findet man alles über Midi. Nebst einem MIDI-Betriebssystem fur 8 bit oder 32 bit Prozessoren MIOS8 /32. Geschrieben ist alles in C oder asm. http://ucapps.de/mios8_c.html
-
Thread
2 Tasten Codeschloss
nicht was du da mit dem switch vor hast. Da du nur zwei Taster hast macht es Sinn dafür auch nur einzelne Bits zu verwenden. Bei einem Tastendruck shiftest du alle Bits eins weiter und fügst das gerade gedrückte hinzu. Wenn die ersten 4 Bits dann mit dem richtigen Code übereinstimmen hat jemand die richtige
gefragt habe ob mir jemand helfen kann. Ich suche > hier Hilfe weil ich gerade erst angefangen habe in C zu programmieren. > ich kann nur HTML, CSS, PHP, C++, ST. Dann erwarte ich (besonders, wenn du C++ *kannst*), dass du selbstständig die grundsätzlichen Dinge löst. Eingänge abfragen und Ausgänge
-
Thread
Schieberegister Zustand merken bei Spannungsausfall
nimm nen µC mit EEPROM
PCF8574 geben nach 8 x 8 auf mit A nochmal 8 x 8 = 128 Taster MCP gibts mit 16 Ports auf SPI oder I2C Basis, aber wieviele man ranhängt? Latches par in ser out kenne ich nur mit 8-bit also 40 Latches a 8 Bit immer seriell auslesen um den Tastendruck (evtl. noch mit Entprellung) zu registrieren, ist
-
Thread
Displayanzeige für verschiedene Zustände
define Z0 0 #define Z1 1 #define Z2 2 usw. Dann definiere eine Bytevariable (z.B. uint8_t beim µC) "gesamtzustand". Jetzt kannst du unabhängig jeden einzelnen Zustand setzen mit gesamtzustand |= (1 << Z0) für Zustand 0 oder gesamtzustand |= (1 << Z2) für Zustand 2 bzw.. löschen von Bit 3
invertieren von Z2 gesamtzustand ^= (1 << Z2) Du kannst dann an anderer Stelle wieder jedes einzelne Bit abfragen, z.B. mit if ( gesamtzustand & (1 << Z2) ) { // wird ausgeführt wenn der Zustand 2 auf HIGH ist } Meintest du so was oder vielleicht doch nicht?
-
Thread
Anfänger in C und welcher PIC (evtl. uno32) ist geeignet ?
deswegen ist deine Bekanntheit mit PIC16x auch kein Argument dafür, bei Microchip zu bleiben. C ist überall C. Außerdem haben PIC24 (16 Bit) außer dem Namensbestandteil PIC genau gar nichts mit den 8-Bit PICs zu tun. Und die 32-Bit PIC sind in Wirklichkeit MIPS Cores. > Das Kurzzeit-Ziel: Dem
Beitrag #3922524: > Be Ti schrieb im Beitrag #3922415: > >> Das Langzeit-Ziel ist PIC24 mit 16 bit, weil die 16 >> bit-Berechnungen da am besten aufgehoben sein werden ... >> Das Ganze dann in C > > Mit Verlaub, aber das ist Unsinn. Wenn du in C programmierst, dann macht > der C-Compiler die
-
Thread
Verbindung mit Component von Grafikentwurf zum VHDL
LPM_Counter und ein LPM_Compare sein, die so zurecht gebogen werden, dass die Busbreite stimmt (17 Bit für 100000) und beim Comparator das 17-Bit Eingangssignal mit einer Konstanten verglichen wird, siehe der 3. Screenshot (die ersten beiden sind aus Versehen angehängt, das konnte ich nicht rückgängig
schrieb im Beitrag #4021565: > Die If-Schleife ... gibt es nicht. Es gibt bestenfalls eine if-Abfrage.
-
Thread
stm32 harte nuß !
GPIO_Init(BUTTON_PORT, &gpio); } int button_pressed (void) { if (GPIO_ReadInputDataBit(BUTTON_PORT, BUTTON_PIN) == Bit_RESET) { return 0; } return 1; } [/c] und ersetze Deine Abfrage durch: if (button_pressed ()) .... P.S. Auch für die LED kann
GPIO_Speed_50MHz; GPIO_Init(LED_PORT, &gpio); } void led_on (uint16_t led) { GPIO_WriteBit(LED_PORT, led, SET); } void led_off (uint16_t led) { GPIO_WriteBit(LED_PORT, led, RESET); } [/c] Dann reduziert sich Deine main() auf: [c] button_init(); led_init();
-
Thread
STMF4 ADC 5 Kanäle mit Regular Channel Group auslesen
Blauer Knopf schaltet blaue LED while(1) { if (ADCRead.channel0 > 0x0080) { GPIO_SetBits(GPIOD, GPIO_Pin_15); } else { GPIO_ResetBits(GPIOD, GPIO_Pin_15); } } [/c] Beachte, das du dir nicht beliebig DMA Stream und Kanal aussuchen kannst, sondern an die Tabelle im Reference
Aktuelle Einstellungen sind wie folgt: [c] #define configCHECK_FOR_STACK_OVERFLOW 2 // Variante wie der Stack Overflow überprüft wird --> Methode 2 (siehe freertos.org API) [/c] [c] #define configMINIMAL_STACK_SIZE ( ( unsigned short
-
Thread
ATMega32 und das STK500
einfach nicht mehr weiter! Ich habe mir das STK500 gekauft und dazu den ATMega32, da dies auch der uC ist den wir in der Uni zum „lernen“ benutzen. Ich benutze AVR Studio 6.2 (aktuellste Version) Diamex –AVR ISP Programmer Das Problem: Die Fuse-bits habe ich einfach mal so übernommen von denen aus dem Uni-Labor (Da funktioniert alles) Allerding arbeitet mein uC mit dem STK500 Board Takt in der Uni ist ein Quarz mit 16MHz drin. Ich kann mein uC Flashen und Programmieren, das ist kein Problem! ABER sobald es um Bedingungen geht wie z.B. eine IF abfrage oder
-
Thread
AVR-Mikrocontrollertechnik-Kursus in Assembler besprechung Gesperrt
xyz auftauchen damit der entsprechende Port auch > was ausgeben kann. > Der Befehl *SBI* ( Set Bit im I/0-Register ) macht dies für ein einzelnes Bit. Bernd_Stein
arbeiten musste. Auch das half leider nichts : http://rn-wissen.de/wiki/index.php/Assembler_Einf%C3%BChrung_f%C3%BCr_Bascom-User#.22S.22_und_.22V.22_Bit Immerhin scheine ich ja jetzt wenigstens das mit dem H-Flag begriffen zu haben. F. Fo schrieb im Beitrag #3947196: > Die Bücher von Schwabl-Schmidt
-
Thread
ALU VHDL ohne Process
heutige Jahr ist... > > Mit diesem Befehl hier wackelst du nämlich am "hintersten, rechtesten" > Bit: > c(6) <= '1' when unsigned(a) > unsigned(b) else '0' when "000", möchte ich auch, da ich nach Aufgabenstellung das Ergebnis von boolschen Abfragen in das niederwertigste Bit schreiben möchte
äusserst unüblich. >> Mit diesem Befehl hier wackelst du nämlich am "hintersten, rechtesten" >> Bit: >> c(6) <= '1' when unsigned(a) > unsigned(b) else '0' when "000", > möchte ich auch, da ich nach Aufgabenstellung das Ergebnis von boolschen > Abfragen in das niederwertigste Bit schreiben möchte
-
Thread
C++ auf einem MC, wie geht das?
entsprechende > Code der Klasse ausgeführt. > Damit sollte exakt der gleiche Code entstehen, wie in plain C, also kein > Mehrverbrauch. das macht man auch so. Etwas Mehrverbrauch entsteht je nach Compiler. (schon alleine, da jedes Bit jeder LED einzeln initialisiert wird) In C++ würde ich das mit Templates
3Bits für CS0n [/c]
-
Thread
Lange Rechenzeit von kurzem C-Code
miso[18] = {0}; bcm2835_spi_transfernb(mosi, miso, 18); // Zusammensetzen der 18bit-Daten aus den einzelnen Empfangenen Bytes long AD1_Ch1 = ( miso[0] << 10) + (miso[1] << 2) + (miso[2] >> 6); long AD1_Ch2 = ((miso[2] & 63) << 12) + (miso[3] << 4) + (miso[4] >> 4);
!= 'Z') [/c] es gibt wirklich keinen Grund, hier den ASCII Code von 'Z' selber hinschreiben zu müssen. Dann kannst du dir auch den Kommentar sparen. Denn was eine Abfrage des File Handles auf NULL bedeutet,
-
Thread
Richtiges C++ hardwarenah
Hochsprachen arbeitet Für alle die hier nur das, was die rausgegoogelt haben, wiederholen: C++ ist weder für Mikrocontroller gedacht, noch geschrieben worden. Wenn es um Hardware geht, ist die Frage: plain C oder C++ *absolut* *irrelevant*. Einzelne bits setzen, Register mit irgendwelchen
Marc Vesely schrieb im Beitrag #3895049: > C++ ist weder für Mikrocontroller gedacht, noch geschrieben worden. > Wenn es um Hardware geht, ist die Frage: plain C oder C++ absolut > irrelevant. Einzelne bits setzen, Register mit irgendwelchen
-
Thread
ca. 100 PT1000 Messwiderstände messen
Ulrich H. schrieb im Beitrag #3917035: > µC C8051F350 sogar einen AD mit hoher Auflösung (16-24 Bit) Kann der wirklich 24Bit Auflösung? Die Dinger gibts ab 3€. Wie kann man die programmieren? Bei Eingabe von Arduino+ADC findet man http:
begrenzt und man auch nur bei eher geringer Samplingrate die maximale Auflösung erreicht. Für 16-20 Bit bei 50 Hz kann es aber schon reichen. Der ADC in dem µC ist durchaus vergleichbar mit dem einzelnen ADS1115. Damit ist der µC sogar ein recht gute Wahl für die Sensoren, auch wenn man ganz so viel
-
Thread
Funktion zum vergleich von Variablen
zwischen den Zeilen ändert. Hmm. Das ist aber schon mal der perfekte Ansatz für eine for-Schleife [c] for( BitNr = 0; BitNr < 8; ++BitNr ) { if( ( input & ( 1 << BitNr ) ) != ( output & ( 1 << BitNr ) ) ) { sprintf( buffer, "Fehler im Bit %d", (int)BitNr ); lcd_puts( buffer
Kabelbruch verhindert, >dass die 1 überhaupt auf der richtigen Leitung durchkommt. Das prüft diese Abfrage: [c] if (inputport != outputport) [/c] Gruß Jonas
-
Thread
Leds mit gleichen Taster durchschalten
Logische Operationen mit einem Leerzeichen trennen. Erst einmal eine Variable deklarieren: [c] uint8t TasterCnt = 3; [/c] Der Else Teil deiner if Abfrage ist auch unnötig, also: [c] while(1) { if (!(PINB & (1<<PB0))) // Taster Abfrage high oder low?
um Erfahrungen auszutauschen > und jemanden Helfen, der nicht weiter weist. Also, nochmal: [c] volatile uint8t TasterCnt = PB3; // Falls du das mal in der ISR abfragen willst while(1) { if (!(PINB & (1<<PB0))) // Taster Abfrage high oder low? {
-
Thread
Suche einen passenden IC oder sonstige Lösung
Werte und möchte, dass wenn mehr als einer der > Werte 1 ist, der Ausgang der Schaltung 1 wird. µC mit 13 GPIO's oder einen 4k PROM.
). 2mal Port lesen, checken ob min. 1 bit unerwartet in 2mal if-Abfrage**. das ganze weitere 11 mal für andere Pins (12 mal hard coden oder 1 clevere Schleife). -> eigentlich recht überschaubares Programm mit im ersten Schritt einer Auswertung
-
Thread
Attiny im Dauerbetrieb
So, hier ist das nächste Update: Abhängig vom verwendeten Regler sind C1 und C2. Welche Werte eignen sich für C4 und wieso? Wieso brauche ich einen Vorwiderstand R7? Die Diode ist ja in Sperrrichtung schon ein Widerstand. Fließt trotzdem zu viel Strom? Der Attiny
> Wobei sich > mir nicht erschließt, warum man für eine derartige Pillepalle-Schaltung > einen µC ver(sch)wenden wöllte. nun ja, man lernt µC weniger Teile könnten es auch bei anderem Design sein, aber du hast Recht, bei dem unnötigen Bauteile Aufwand wirkt ein µC etwas komisch. Warum 5V zu
-
Thread
Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?
"TARGET_STATE" und "CURRENT_STATE" dann jeweils eigene RGB-Werte wären und keine einzelnen Bits mehr.
[/c] Ohne BitSets sähe das anders aus. Ich will hier niemanden bekehren! Das ist nur mal zum Nachdenken.
-
Thread
Signale aus Sensor verarbeiten / filtern
meinem Projekt einen Beschleunigungssensor eingesetzt (AIS328DQ von STM). Dieser sendet mir über I2C-Bus Daten, die ich im Programm abfrage. Wie kann ich diese Daten filtern? Aktuell mache ich es "zu Fuß", d.h. ich lese die Daten ein, addiere sie 16 x und bilde beim 16ten mal den Mittelwert.
übliche Methode für Werte, die nicht normalverteilt sind, ist z.B. die Berechnung des Medians. Einzelne Ausreißer gehen dann gar nicht in den Wert ein. c-hater schrieb im Beitrag #3874327: > Das ist schonmal eine extrem ungünstige Sensorwahl. Du misst die > Beschleunigung, dich interessiert aber
-
Thread
strtol Problem (Ergebnis ist immer MAX_LONG)
die Antwort. Natürlich kann ich dir auch ein einfaches, komplettes Beispielprogramm anbieten: [c] #include "stdlib.h" int main(void) { char *temp = "000A"; long test = (long)strtol(temp, NULL, 16); if (test == 0) { test++; } return 0; } [/c] Die IF-Abfrage dient
} else { test++; } while(test == 0) { P10OUT ^= BIT7; } while(test != 0) { P10OUT ^= BIT6; } return 0; } [/c] Gleiches Verhalten. Falscher Wert in test. Erste While-Schleife wird nicht angegangen. Die zweite
-
Thread
PIC: Problem mit state-maschine und Reihenfolge der Portabfrage
abgesehen verstehe ich nicht, warum es einen Unterschied macht, an welcher Stelle im key-handler() die einzelnen Bits der Eingänge abgefragt werden. Ich drücke die Taste am RB7. Steht die if-Anweisung if(PORTBbits.RB7==1) ganz oben, funktioniert alles (wie von mir zu diesem Zeitpunkt gewünscht) wunderbar. Setze
Karl Heinz schrieb im Beitrag #3869723: > Dann musst du dir ansehen, wo der µC die Zeit vertödelt. Scheinbar hing der µC in einer while-schleife fest, die auf das ACK von einem I2C-Slave wartete. Jetzt funktioniert es wie gewünscht. Danke. Nun noch eine Frage: Ich möchte jetzt
-
Thread
low-cost WiFi Chip ESP8266 Projekte mit dem Internet der Dinge (IoT)
habe ich auch schon nachgedacht. Das Problem besteht allerdings weniger darin, das Timing der einzelnen Bits richtig hinzubekommen (das geht schon irgendwie), sondern dass die Übertragung zu beliebigen Zeiten durch Interrupts unterbrochen werden kann. Unterstützt der SOC DMA? Habe ich noch nichts
habe ich auch schon nachgedacht. Das Problem besteht allerdings > weniger darin, das Timing der einzelnen Bits richtig hinzubekommen (das > geht schon irgendwie), sondern dass die Übertragung zu beliebigen Zeiten > durch Interrupts unterbrochen werden kann. Meine Annahme war, dass das in der von
-
Thread
Suche Helfende Hand bei vb Überwachungsprogramm,
Daten über eine RS232-Schnittstelle senden und/oder empfangen möchtest, sondern nur den Zustand einzelner Signalleitungen setzen und abfragen möchtest. Das ist nicht die Schnittstellen-Nutzung, für die es oft fertige Programmbeispiele oder Libraries gibt; für deine Nutzung wirst du eher den direkten
Daten über eine RS232-Schnittstelle senden und/oder empfangen möchtest, > sondern nur den Zustand einzelner Signalleitungen setzen und abfragen > möchtest. 100% getroffen genau das will / möchte ich erreichen. Und die 4 Ports sind bereits onborad also kost mich nix :-)
-
Thread
Benötigte CPU-Leistung ermittel
1920*1080*3 = 6,22 Millionen Additionen plus die Datenzugriffe auf die Pixel plus Schleifen und Abfragen. Dazu kommt dann die Hardwareausstattung des Chips. Mal nur die Additionen genommen (als 32 Bit Integer) wäre hier ein ATMega bei 20 MHz Takt theoretisch auch in 1,3(Addieren) Sekunden + 0,6 (aus
" um den Kompfort zu liefern, den sie mit sich bringen. Ich hatte vor Jahren mal VisualBasic gegen C verglichen und kam bei einfachen Befehlen wie Abfragen, Schleifen und Additionen auf eine Faktor von über 1000. Sprich, C läuft 1 Sekunde, VB für das gleiche fast 17 Minuten. Aber auch die Art, wie der
-
Thread
IF-Abfrage mit AND und Resultat?
Peter Bierbach schrieb im Beitrag #3865440: > Nein, es geht darum ein bestimmtes Bit im Byte auf gleichheit mit AND > abzufragen. Was ist das eigentliche Problem? Im ersten Post steht schon wieder so halbgarer C-Code. Woher kommen die beiden Bits, die da verglichen werden sollen? Wenn ich in einem Vektor gezielt ein Bit abfragen will, dann mache ich das über den Index: if a(3) = b(3) then...
-
Thread
Übertragung von High- und Low-Signalen zwischen zwei AVR
Das ist doch C++ Code in einer Umgebung verpackt. Oder irre ich mich? Denn in C++ ist das hier [c] if ((pinD.bit2 == 0) & (pinD.bit3 == 0) & (pinD.bit4 == 0)){ [/c] an dieser Stelle nicht richtig. Ein
selten, weil man da tatsächlich eher wenig mit einzelnen Bits rummacht. Aber auf einem µC ist das anders: Da sind die Bitoperationen dein Lebenselexier, weil sich 80% der ganze Programmierung nur mit der Manipulation von einzelnen Bits bzw. Bitfolgen beschäftigt
-
Thread
ARM und Assembler Programmierung?
das Gefühl gegeben wird, dass 8 Bit eigentlich eine aussterbende Art sei. Hoffe mal das sich das nicht bewahrheitet. Oder unsere Nachfahren schalten im Jahre 2250 vielleicht einzelne LEDs mit 512 Bit Mikrocontrollern und mit so viel
EinUserWasSonst schrieb im Beitrag #3860802: > Nun beschäftige ich mich mit ARM 32 Bit Mikrocontrollern und frage mich > ob irgendwer auf der Welt ernsthaft Assembler dabei nutzt. Der Hauptteil wird tatsächlich in C geschrieben. Es gibt aber Teile die in Assembler sinnvoll sind: Bit-Banging
-
Thread
Variable zwischen zwei Uhrzeiten auf 1 setzen, sonst 0
. Also in der Art: [c] private int testeEinenWert(int zahl, int limit) { if (zahl > limit) { return 0; } return 1; } [/c] Warum? Ganz einfach: Du schreibst ein paar Tests, nach dem Motto: [c]
> Balou Baer schrieb: >> Daher ist das Testen sonst sehr zeit aufwendig ^^. > > 4 Vergleiche 8Bit sind überhaupt nicht zeitaufwendig. > Das vorher multiplizieren ist deutlich aufwendiger. Das nicht, aber das Warten bis 22:30 und danach bis nach 5:30, um zu sehen, ob die Abfrage auch das gewünschte
-
Thread
FTDI zerstört Fake Chips durch Windows-Update
Ist jemanden schon ein Fake untergekommen, der nicht > lief? gleich drei Stück 1 x FTDI 1313-C CN 480661 FT232RL 2 x FTDI 1402-C CN 480661 FT232RL
Statt künstliches Ohr mit B&K Vorverstärker, gedrechseltes Holzteil + MIC Vorverstärker vom blauen C
-
Thread
AVR-ASM Knobelei : Bitmanipulation am LCD im 4-Bit Mode
hatte, müßte ich Port einlesen, AND Steuerleitungen, OR Dataleitungen - am Ende war es mit einzelnen bits viel übersichtlicher.
Johann L. schrieb im Beitrag #3853104: > P = __builtin_avr_insert_bits (0xff4567ff, D, P); Mit welchem Compiler soll das denn gehen? [pre] D:\AVR-C\Test1/main.c:12: undefined reference to `__builtin_avr_insert_bits' [/pre]
-
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
mit CAN Bus Fensterkontakte abfragen.
Hallo, Ich plane in unserem Haus alle Fensterkontakte (offen/geschlossen/gekippt, verriegelt/entriegelt) abzufragen und einer zentralen Hausautomatisation weiterzugeben. Erster Gedanke das Alles über KNX/EIB zu lösen erscheint mir letztlich zu teuer (Anzahl der Binäreingänge ist doch beachtlich). Ausserdem ist da zu wenig Bastelei dabei und Zeit hab ich ja noch ein wenig. ;) Mein Plan würde nun so aussehen: - ein Kabel (Cat6 oder EIB) ausgehend vom Schaltkasten von Fenster zu Fenster; Über das Kabel erfolgt Stromversorgung (12V ggf. wenn am Ende genug Spannung rauskommt auch etwas weniger
-
Thread
Kombination zwischen zwei Programmen
Flag-Zustand an. > > Ja genau so wollte ich das machen! > aber ich wusste nicht wie ich die Taster Abfrage machen soll, deswegen > dachte ich an den externen Interrupt... > Also wie soll ich die Abfrage machen? Einfach den µC-Pin, wo der Taster dran hängt, abfragen. Taster vom Pin gegen GND, internen
Tastenabfrage sogar ganz gut funktionieren, weil die Anzeige relativ lange dauert. Das Problem bei dieser Abfrage besteht ja im Grunde darin, dass der µC (im Tutorialsbeispiel) zu schnell ist. Wodurch das Tastenprellen durchschlägt (und genau das ist auch das Problem bei einer Lösung mit externem Interrupt)
-
Thread
Protokoll entschlüsseln
00 FA FF 00 03 01 01 02 01 00 00 00 43 79 4D 8C 59 19 08 22 05 00 FA FF 00 04 01 01 01 00 00 00 00 EF 6D 94 79 59 19 08 22 05 00 FA FF 00 05 01 01 02 01 00 00 00 C4 70 22 4A 59 19 08 22 05 00 FA FF 00 06 01 01 02 01 00 00 00 27 77 AD C4 59 19
03 97 0F 00 00 F8 77 00 00 00 00 45 00 00 00 00 00 00 00 00 00 03 00 03 00 00 08 00 00 00 00 DF 00 9C DF BE 77 Adresse 3: 59 19 08 22 05 00 FA FF 00 03 01 01 02 01 00 00 00 43 79 4D 8C 59 19 08 22 30 00 CF FF 03 00 08 01 00 00 00 00 16 00 0F 00 1F 00 2C 00 35 00 C0 03 97 0F 00 00 F8 77 00 00 00
-
Thread
AtMega Usart Abfrage
Wo steht was von USART 2? Er will 2 bestimmte Tasten abfragen. Versuch es mal so: [c]if (strcmp(receive_a, "q") == 0)[/c] Vergess nicht #include <string.h>
Einzelne Zeichen sind manchmal trügerisch. [c] unsigned char nInd = 0; char foxtext[] = {"the quick brown fox jumps over the lazy dog\r\n"}; while(1) { Uart0_Write(foxtext[nInd++]);
-
Thread
eBus USB Adapter
Aktuelle Raumtemperatur Heizkreis 2: [code]ff15b52406020003010f00 / 0801030f00cd4ccc41 = 25.5000°C ff15b52406020003010f00 / 0801030f00cd4ccc41 = 25.5625°C[/code] Hier scheint "cd_c____" immer statisch zu sein und das 2. Byte ist immer entweder 4c oder cc, es zählt nur das höchste Bit zur Temperatur
negativ einstellen kann: "AT Durchheizen" [code] ff15b52406020000000200 / 08030002000000a040 -> 5°C ff15b52406020000000200 / 0803000200000080bf -> -1°C ff15b52406020000000200 / 08030002000000c8c1 -> -25°C[/code] Somit stimmt es - das höchste Bit gibt das Vorzeichen an, alles andere bleibt:
-
Thread
Heizungssteuerung Trovis 5575 auslesen
das alles "Eingangsregister"? (Also keine Holding Register?) - Wo finde ich das Datenformat der einzelnen Register (also z.B. "Unsigned 16 bit (Big Endian)" oder "Signed 16 bit (Little Endian)" etc.? Z.B. die Adresse 9 "AussentempAF1": Da ist als Umrechnungsfaktor in der oben genannten Datei (5576-
Einstellungen der Trovis (5573-0003 FW 2.48) PA6: 247 (Stationsadresse) CO6-F01: 1 (Modbus aktiv) C06-F02: 0 (8 Bit Adressierung) (Habe aber auch schon mit "1" 16-Bt Adressierung probiert) C06-F03: 0 (Modemfunktion) (Habe auch schon 1 probiert) C06-F04: 0 (Auto. Modemkonfig) (Habe auch schon 0 probiert