-
Thread
ATmega32 einzelne Pins setzen und abfragen
geeigneter Bitmanipulation (siehe https://www.mikrocontroller.net/articles/Bitmanipulation) problemlos einzelne Bits abfragen, setzen bzw. löschen. Colin v.H. schrieb im Beitrag #2731202: > Port-A ist als Eingang geschaltet. Nun läuft im µC eine Schleife ab, die > nur unterbrochen werden soll, wenn Pin
Bitmanipulation (siehe > https://www.mikrocontroller.net/articles/Bitmanipulation) problemlos > einzelne Bits abfragen, setzen bzw. löschen. ist das nicht ein wiederspruch in sich? der atmel kann sowohl einen Port als auch ein Bit eines Ports ändern.
-
Thread
24 serielle Schnittstellen am PC
2-3k€ und lass auf einem Port ein GPS timing modul laufen. Jedoch sollte das Timing Modul auch uC unterstützt sein, ansonsten wenn beim nächsten Terroranschlag das GPS abgeschaltet wird, gibt es keine Daten. Ev. findet sich ein DCF77 Modul mit uC was dafür geeignet ist.
ms Zeitdifferenz zustandekommen im worst case. Ich würde da je serielle Schnittstelle einen uC nehmen von HW RS232 auf spi und einen Master welcher dann den Zeitslot vorgibt sowie auch die Daten ausgibt mit 250Kbps sowie einen uC welcher mittels GPS/DCF77 einen Timestamp ausgibt. Da aber dann
-
Thread
[Cortex M3] Festkomma vs Fließkomma
Die üblichen DSPs haben dafür ne Menge Rundungs- und Shift-Modifier schon eingebaut, die Du in C teils recht mühsam implementieren musst. Das Shiften ist Pipifax, aber die Abfrage einzelner Bitsequenzen innerhalb einer dicken Schleife kann ganz schön Zeit verbraten (if-Abfragen sind fast immer schlecht
Die üblichen DSPs haben dafür ne Menge Rundungs- und Shift-Modifier > schon eingebaut, die Du in C teils recht mühsam implementieren musst. > Das Shiften ist Pipifax, aber die Abfrage einzelner Bitsequenzen > innerhalb einer dicken Schleife kann ganz schön Zeit verbraten > (if-Abfragen sind
-
Thread
Poti -> RGB Farbrad
eines Regenbogen-Farbpickers zu kommen. Vielleicht hat jemand Rat (insb zur Umsetzung auf einem 8 Bit uC )? LG, doppio
Variablen ab. Und nur dann, wenn der count 0 ist, kopierst du sie auf die PWM Vergleichsregister um. [C] cli(); if( count == 0 ) { //setzen der neuen Farbe color[0] = temp[n + 2]; color[1] = temp[n + 1]; color[2] = temp[n ]; } ... [/C]
-
Thread
Mehrere Sensoren über eine UART Leitung kommunizieren lassen
keine neue Platine entwerfen kann. Die weitere Option wäre in meinen Augen halt noch, einen weiteren µC zu verwenden der 6 verschiedene UART hat und dann die Daten sammelt und dann einzeln weitergibt. Ist das vielleicht besser? Mir ist klar, dass es Intelligentere Lösungen gibt (Bussysteme wie SPI und
nicht > schlecht. Ist aber vielleicht etwas umständlich wenn ich nur einen > bestimmten Sensor abfragen will. Für deinen PC ändert sich nichts. Der schickt weiter seine Abfragen raus. Jeder Sensorrechner empfängt auf der einen UART die Abfrage, sieht nach ob sie für ihn ist und wenn nicht, schickt
-
Thread
ARM ist die Zukunft?
sein. Insofern, ja, ARM ist als 32 Bit µC eine potentielle und vom aktuellen Status her sinnvolle Zukunft. Ob der AVR32 dagegen halten kann, würde ich bezweifeln, denn die ARM µC werden einfach von zu vielen Chipherstellern in Lizenz gefertigt
32 Bit bringen bei µC-Anwendungen nicht so große Vorteile wie auf dem PC. 4 GB Speicher muss man eher selten adressieren und man manipuliert häufig nur Bytes. Preislich kommen ARMs nicht an die Klasse
-
Thread
Debuggen mit XCP - gibt es XCP als OpenSource ?
schickt man über einer der vielen möglichen Schnittstellen (CAN/UART/ETHERNET) zu Beginn folgendes zum µC: Sende mir 16 Bit Wert von Adresse 0x00042 alle 100ms Sende mir 16 Bit Wert von Adresse 0x00044 alle 10ms Sende mir 8 Bit Wert von Adresse 0x00046 alle 10ms Der leg das in einem Array/Liste ab.
Weniger umständlich, aber erstmal ausreichend ist, der PC Software alle 100ms eine Variable abfragen zu lassen (=polling). Resultiert halt in mehr Overhead.
-
Thread
Btm-222 mit Nibobee verbinden
programmiert. Ich denke da liegt der Fehler, weil dies ist wirklich nicht meine Stärke... Hauptprogramm: [c] #include "nibolibbtm.c" #include "projekt.h" #include <avr/io.h> #include "uart.h" int main() { char c=getchar(); uart_init(); motoren_init(); // motoren initialisieren
uart_receive(void); void uart_gets(char* buffer, uint8_t maxlen); void uart_init(void); [/c] uart: [c] void uart_putc(unsigned char c) // einzelnen wert abfragen 1 byte { while(!(UCSRA & (1<<UDRE))) { } UDR = c; } void uart_puts(char* string
-
Thread
USART Übertragung innerhalb Byte abbrechen
µC1 das senden sofort > einstellen und nicht noch das restliche Byte raustakten. Falls die Hardware das erlaubt, könntest Du im Senderegister die restlichen Bits des teilweise ausgesendeten Bytes auf
versuchen. Für diesen Ansatz braucht der Pin-Change-Interrupt "nur" während des Sendens durch den µC aktiv zu sein, kann in dieser Zeit aber (bei 9600 Bit/s) mit max. 4800hz ausgelöst werden, was je nach Anwendung ggf. nicht tolerabel ist.
-
Thread
Gemeinsame Tastenabfrage mit Atmels XMega Serie?
Wie wäre es mit switch..case? [c] void button_interpreter(void) { switch(PORTD.IN) { case 0xFE : // Taste an Bit0 gedrückt // Tu was break; case 0xFD : // Taste auf Bit1 break; /
meinem Codefragment wird genau einmal PORTD.IN abgefragt. Wenns dir nur darum geht, irgendeine einzelne taste abzufragen: [c] void button_interpreter(void) { switch(PORTD.IN) { case 0xFE : // Taste an Bit0 gedrückt case 0xFD : // Taste auf Bit1 case 0xFB : case 0xF7 : case 0xEF :
-
Thread
STM32 USART Interrupt nur für RX
Oh man. Ja, vergesst das oben Geschriebene, man kann ja die Interrupts ja doch für einzelne Ereignisse konfigurieren.. [code] USART_ITConfig(USART_TypeDef* USARTx, uint16_t USART_IT, FunctionalState NewState) [/code] Dann mit USART_IT_RXNE nur RXNE anschalten. Sorry :/
[/c]
-
Thread
AVR Synthesizer mit ATxmega128A1
spezielle Funktion, die Word mit Byte Multipliziert hat, und als Ergebnis kam Word raus (die untersten 8Bit des 24Bit Ergebnisses werden ignoriert) Ich habe auch mit einem Filter experimentiert, der so auschaute: [code] v0 = R*C*v0 + C*in - C*v1; v1 = R*C*v1 + C*v0; output = v1; C = Cutoff (0.
temperature = (((uint32_t)358*result_)/calval_) - (273+temp_offset); return ( temperature); } [/C] Am Anfang wird der ADC initialisiert und die Calibration Bytes für den Temperatur Sensor gesetzt. Danach folgt die Abfrage der 12Bit breiten Sensor Daten im ADC Daten Register und die Um- rechnung
-
Thread
RFM12: SPI Unklarheiten
0x000D Anfrage: 0x0000 Antwort: 0x0000 Die ersten beiden sind keine gültigen Anfragen - das höchste Bit ist '0', also eine Status-Wort-Abfrage, aber der Reest des Kommandos enthält nicht-0-Bits - also doch keine Status-Wort-Abfrage, aber was dann?
Strickwettbewerbgewinner schrieb im Beitrag #2704649: > Stefan Helmert schrieb: >> Das kann es ja nur, wenn es die Bits mitzählt bzw. die >> einzelnen Bits im Eingangsregister nicht durchschiebt sondern >> durchadressiert. > Na und? Das hat eine Auswirkung auf das Verhalten, wenn man nicht genau 16 Bit überträgt
-
Thread
Switch Case verzweigung so Anwendbar auf ATmega 32?
A. K. schrieb im Beitrag #2701615: > Aber eben nur in GNU-C, nicht in Standard-C. Leider. In Standard-C muß man die 65536 Case alle untereinander schreiben. Und bei 32 oder 64 Bit: no way. Peter
) ; [/c] Die Gründe dafür: 1. Weniger Redundanz im Quelltext: Bei der Case-Methode tauchen die oberen Intervallgrenzen einer Case-Abfrage um 1 erhöht in der nächsten Case-Abfrage noch einmal auf
-
Thread
Drohne im eigenbau Gesperrt
schwer. Aber viel mehr als LED's scneller, langsamer blinken zu lassen habe ich noch nicht gemacht.(c-control) Das die Drohne mit einem 8-bit controller nicht fliegen wird auch. ich hätte an 32-bit gedacht... Es muss natürlich nicht unbedingt Atmel sein. ;) Mit real time OS meinst du eine live
ihr danach ein gutes Stück schlauer, so oder so. Vielleicht langsam rantasten. Zunächst einfache µC-Projekte nach dem Tutorial hier abarbeiten. Dann Servos ansteuern und einen Beschleunigungssensor abfragen. Mit dem erworbenen Wissen versuchen, eine einfache Lagestabilisierung für das Flugzeug zu bauen
-
Thread
SPI Kopplung von ATmega8 und ATtiny 2313
Adresse für dieses Register innerhalb der Adessen 0x01..0x1F liegt (nicht MEMORY MAPPED) kann man einzelne Bits ganz einfach mit *sbi* oder *cbi* verändern und die Skipbefehle *sbis* oder *sbic* verwenden. [avrasm] .equ SPI_ON = 2 [/avrasm] ..habe ich selber definiert. Damit kann man im Programm
Formulierung > ldi R16,0b00011000 ; (1<<USIWM0)|(1<<USICS1) > out USICR,R16 > Sollte bis auf Bit 6 identisch sein. Kannst Du das für mich prüfen? Ich > bin bei Adressierung von Bits und Masken immer unsicher. Das ist schon korrekt so. Ich setze ja nurnoch das Interrupt-Bit, um einen Interrupt
-
Thread
PIN Variable
mit dem Display hatte ich nur gefunden ..... Ich will den z.b Sbis pind ,0. Pin0 am portd abfragen ob er gesetz ist wenn ja dann ... Wenn Nein dann .. und das ganze mit jedem Bit von portd .... Es funktioniert ist aber halt ein wenig Text Ich wollte das ganze verkürzen in dem ich immer nur die Pin ZAHL ander und immer die selbe Abfrage nutze o schreib ich ja für jeden Pin eine einzelne Abfrage und die Aktion dahinter Mfg Bqube
-
Thread
ISE übersetzt irgend wie nur Mist
eine LED zum blinken gepracht ledclock: process begin wait until rising_edge(clk); if (c<24999999) then c <= c+1; else c <= 0; x <= not x; end if; end process ledclock; --hier wird der Takt für das weiterschalten der Segment Stelle generiert segclock: process
funktioniert in der Simulation, aber in der Synthese nicht! Verwende if rising_edge(clk) then > if (c<24999999) then > c <= c+1; > else > c <= 0; > x <= not x; > end if; end if; > end process ledclock; In diesem Prozess ein ganz böses Faul indem du hier den clock "segclk" verwendest
-
Thread
struct vorbelegen
Hallo, ich möchte in einem Struct einzelne Bits abfragen, die mir für eine if-Bedingungen dienen sollen. Um nicht immer einen ganzen char zu verschwenden, sollte ich das mit einem struct machen: [c] struct { unsigned
unsigned SB_2:1; unsigned SB_3:1; . . . } StatusBit; [/c] Wie belege ich aber die einzelnen Bits mit 0 und 1 vor? StatusBit.SB_1 = 1; funktioniert nicht, da meckert der Compiler... Danke.
-
Thread
Programmieren einer UART-Befehlseingabe
//Normal mode, Force RTS and DTR to 1 }[/c]
du weißt noch nicht wie du die UART im µC abfragst, ob sie etwas empfangen hat. Diese Verwirrung hattest du schon mal in einem vorhergehenden Post. Ich habs damals einem Postingfehler zugeschrieben. Da derselbe Begriffsdreher hier nochmal
-
Thread
Virtuelle Karte - Polygon oder Quadrat?
und Mag. Der Daten werden mit 8kHz (Gyro), und 3,2kHz (Acc) fusioniert. Beide AHRS Boards werden einzeln fusioniert und später nmoch weiter verrechnet. Bekommt das Stm32f4 auch noch hin, mit I2C als Schnittstelle? Hinzukommen werden dann noch PID Regler und eine sehr umfangreiche Kommunikation über
>Bekommt das Stm32f4 auch noch hin, mit I2C als Schnittstelle? Der Radio und Fernseher Bus wird das ganze ordentlich ausbremsen. Besorg dir mal Sensoren die per SPI arbeiten. I2C macht auf solchen CPUs einfach keinen Spass und keinen Sinn
-
Thread
Problem mit setmode() und fwrite()
. Irgendwo gibt es dann immer wieder mal eine Beschränkung, weil irgendwer vergessen hat, einen 16-Bit int als unsigned zu machen, von 16 Bit auf 32 Bit hochzugehen, etc. [C] size = 200000; chunk_size = min( size, 4096 ); // nicht mehr als 4K auf einmal total = 0;
+= fwrite( &fbuf[total], chunk_size, 1, stdout) ) { } while( total < size ); [/C] Sicherheitshalber noch eine Abfrage auf einen Returnwert von fwrite von 0 einbauen, der weißt immer auf einen Fehler hin. Die maximale Chunk Size konfigurierbar machen. Das ist nichts weswegen man
-
Thread
ADC Channelauswahl
liegt hier der Fehler? Ähm. Wenn du nur den Kommentar änderst, wird das den Compiler bzw. den µC nicht sehr beeindrucken. Ausserdem: Im ADMUX Register sind auch noch andere Bits. Unter anderem auch die Auswahl der Referenzspannung. Es wäre daher sehr günstig, wenn du beim Setzen der Kanalselektion
> while (!(ADCSRA & (1<<ADIF))) Das ADIF Bit abzufragen ist nicht so toll. Denn: Du musst dieses Bit auch wieder löschen, wenn du keinen Interrupt verwendest. Von alleine setzt es sich sonst nicht zurück. Besser ist es, das ADSC Bit abzufragen
-
Thread
Globales struct; Änderung der Daten innerhalb einer ISR manchmal nicht wirksam
: 1. Datenwort aus dem RAM in ein Register lesen 2. Das Register manipulieren (Bit setzen oder löschen) 3. Register zurück ins Datenwort schreiben. In Deinem Fall besteht also die Zeile [c] tgl_daten.Flag_SQW_Rising = 0; [/c] aus drei mind. Assemblerbefehlen. Wie Stefan Ernst
Struktur habe ich wie Dosmo geschrieben hat nur noch als ganzes volatile gesetzt. Nicht mehr alle einzelnen Bits intern.
-
Thread
Auswerten von Zahlen
Pierre Gnauck schrieb im Beitrag #2673585: > oder gibt es da einen leichteren weg ? C nehmen, dann nimmt einem der Compiler genau so etwas ab. Oder einen Controller mit 16 oder 32 Bit.
Für sowas kann man Definitionen verwenden. #define sbi(PORT,BIT) PORT |= (1 << BIT)
-
Thread
Float Initialisierung scheitert MSP430F5438
mit dem umsetzt was der MSP430 kann. Wenn du willst dann gibt es sicher auch eine Möglichkeit mit 128Bit oder 256Bit Gleitkomma zu rechnen... War jetzt zwar keine Hilfreiche Antwort aber musste trotzdem sein ;)
Probier doch mal [c] float fTest = 78643200.0f; [/c] Wenn ich mich recht entsinne, hatten einige C Compiler Bugs beim Konvertieren von Double nach Float. Dann half es, das "f" ranzuhängen, nur dann sind die Konstanten
-
Thread
ATMega 64, ALL AVR, Anfänger Problem
[c] void PWM_T1(void) { TCCR1A = (1 << WGM10)|(1 << COM1A1)|(1 << COM1A0); // Bit WGM10 des Registers TCCR1A High setzen TCCR1B = (1 << CS11) | (1 << CS10); // Bit CS11 und
Ok wenn es nicht stört zurück zum Problem. Ich verstehe nicht welche Adressen die einzelnen Portbits haben. Im Datenblatt steht PROTC 0x35 aber für DDRC 0x34. Moemntan scheitert es daran das ich die PortBITS nicht einzeln setzen kann [c] PORTC0 = V1_1; PORTC1 = V1_2; PORTC2 = V2
-
Thread
[AVR][ATMega328] UART Receive und Echo mit Fleury Lib
willkürlich gewählt). Ich sehe nirgens eine 33 im Echo, siehe Screenshot. Setze ich direkt, ohne if Abfrage alles auf 33 sieht es aus, wie im zweiten Screenshot. [c] /************************************************************************* Function: uart_putc() Purpose: write byte to ringbuffer
uart_getc(); } // Setze Flag "Neue Daten verfügbar" flagNewData = 1; } } [/c] Ich habe also - nachdem ich nochmal Peters Beispielprogramm durchforstet habe - den 16Bit Output aus uart_getc() verwendet, so konnte ich dann wieder prüfen, ob es sich um valide Daten handelt und
-
Thread
Probleme mit Temperatursensor DS18B20
Wertigkeiten 8 4 2 1 1/2 1/4 1/8 1/16 enthält. Das obere Byte mit den Wertigkeiten <5 gleiche Sign Bits> 64 32 16 lässt Du dann entfallen. 20° -16 = 4 => LSB = 64 (1/16°) 64 / 2 = 32 Da meine DS18B20 gerne 1 bis 2°C mehr anzeigen, haut 40 - 50 hin.
dazu, dass der nachfolgende Befehl von allen ICs im Bus ausgeführt werden soll. Will man einen einzelnen IC ansprechen, so sagt das Datenblatt sende &H55 und danach die 64-Bit Adresse des ICs. In BASCOM würde das so aussehen: [code] Dim DS18B20-ID(8) As Byte 1wreset 1wwrite &H55 1wwrite DS18B20
-
Thread
Bascom ist gut
Abfragen gleich- artig formuliert, dann wäre sie trotz der Gotos gut lesbar: [c] if( register_chardev(...) failed ) goto out; if( request_region(...) failed ) goto out_region; if
> > klar, kein Vergleich mit C Eben. Niemand weiß mehr für was jetzt die einzelnen Bytes stehen. Aber wenn in C dasteht: [c] Config_t cfg; cfg.maxTemp=23.5; cfg.text="Hallo"; cfg.rpm=500; [/c] Das ist schon ne andere
-
Thread
CCD Zeile NEC µPD8872CY
nächster Zeit wie folgt verbessert: 1. Ersatz des ATMega168 durch einen ATXMega 256A3, A/D Auflösung 12 bit (jetzt 8 bit) mit schnellerer Wandlung und Abfrage ALLER Pixel. Ich hoffe dass der XMega die 12 Bit auch bringt; es soll da Probleme geben. 2. Normierung und Linearisierung der Spektralempfindlichkeit
Pixel unempfindlich. Weiss jemand, woran es liegen könnte? Oder liegt es evtl. an dem Arduino? Mit uC haben wir bis jetzt nur wenig Erfahrung gemacht...
-
Thread
Präemptives Multitasking mit einem Hardwaretimer
ja, wie Karl Heinz Buchegger eben geschrieben hat, musst Du natürlich auch aufpassen, dass die einzelnen Stacks nicht zu groß werden. Gruß Jonathan
Ich verwende also völlig normale Interrupts. Weiters nehmen wir an, das Hauptprogramm (eines 8-bit Controllers) führt gerade eine komplexe Berechnung mit 4 Byte großen Datentypen durch. Der C-Compiler wird wahrscheinlich den Code so aufbrechen, dass diverse Register für die Berechnung verwendet werden
-
Thread
Can-Bus mehrere Bytes hintereinander senden
CanClearMOB(); // Alle MOb's löschen // Einstellung der Baudrate 20kBit/s CANBT1 = 0x62; // Teiler = 49 CANBT2 = 0x0C; // PRS = 7 TQs, PHS1= 7 TQs, PHS2= 7 TQs CANBT3 = 0x36; // ==> Sample
CanClearMOB(); // Alle MOb's löschen // Einstellung der Baudrate 20kBit/s CANBT1 = 0x62; // Teiler = 49 CANBT2 = 0x0C; // PRS = 7 TQs, PHS1= 7 TQs, PHS2= 7 TQs CANBT3 = 0x36; // ==> Sample
-
Thread
Was ist ein Festplattensektor?
vielleicht mal anders gedacht war. Will man partout solche Haare spalten, dann muss man jede Track einzeln betrachten und sektorieren. Damit ist dann ein Sektor der Bereich, in dem ein Block nebst Header und Füller Platz findet. Also die Pizza in konzentrische Ringe zerschneiden und diese einzeln sektorieren
Vielen Dank! ich fasse nochmal zusammen: - alle Blöcke haben die gleiche Anzahl Bits - alle Blöcke haben die gleiche Bitdichte - deshalb passen auf die innere Spur weniger Blöcke als auf die Äußeren - und somit sind pro Grad Rotation innen weniger Bits zu schreiben/lesen als Außen
-
Thread
STM32F407 und das SPI Modul
read from the SPI bus */ // there is a 500ns pause between transfers. return SPI2->DR; } [/c] Funktioniert auch, ABER zwischen den einzelnen Bytes ist eine ziemlich grosse Pause von 250ns beim SPI1 und 500ns beim SPI2 zu sehen. Wo kommt die denn her? Die Pause ist unabhängig von der eingestellten
, was wohl der Grund für die Pause ist, nicht mehr abfragen wenn man nur senden möchte. Am Ende dann auf das Busy Flag warten. Ich weiss das das im Datenblatt nicht empfohlen wird. Beim DMA Transfer allerdings schon. Dazu komme ich später. [c] void SPI2
-
Thread
GPIB-RS232-Schnittstelle
Steuerleitungen SC und DC unabhängig zu steuern. Wogegen beim x161 dies nur mit DC geschieht. In gpib.c setzt du immer [c] _DC = 0; _SC = 1; [/c] bzw [c] _DC = 1; _SC = 0; [/c] zusammen, somit verstehe ich nicht, weshalb dies nicht mit dem x161 und nur dem DC Signal alleine möglich
Grundsatzdiskussion erzeugen, nur meine Meinung ;o) Will man mehr als ein Messgerät steuern/abfragen, so stellt sich die Frage, ob man sich wirklich den Aufwand PC-seitig in SW antun will, einen GPIB-Controller zu emulieren, oder ob man nicht lieber zwei einzelne Interfaces wie oben baut und betreibt
-
Thread
Linux UDEV und rules + FTTI
ATTRS{subsystem_vendor}=="0x15ad" ATTRS{subsystem_device}=="0x0770" ATTRS{class}=="0x0c0320" ATTRS{irq}=="16" ATTRS{local_cpus}=="ffffffff" ATTRS{local_cpulist}=="0-31" ATTRS{dma_mask_bits}=="32" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{enable}=="1"
irq}=="0" ATTRS{local_cpus}=="ffffffff" ATTRS{local_cpulist}=="0-31" ATTRS{dma_mask_bits}=="32" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{enable}=="1" ATTRS{broken_parity_status}=="0" ATTRS{msi_bus}=="1" looking at parent device '/devices/pci0000:00': KERNELS
-
Thread
If Abfrage mit unterschiedlichen Zeiten
[c] if(!(PINC&(1<<PC5))) // Abfrage PC5 LED 5 Grün [/c] willst du hier wirklich den Eingangszustand abfragen, oder den Ausgangszustand wissen und damit dann die LED togglen? Was soll dein
delay mit 0,5s oder 1s >ist. Als Lösung wurde vorgeschalgen, delay auf 1ms zu nehmen und die >einzelnen Ansteuerungen oder Abfragen mehrmals zu machen. Im Text heisst Meinst du das hier? http://www.mikrocontroller.net/articles/Multitasking#Ein_einfaches_Beispiel_f.C3.BCr_den_AVR MfG Falk
-
Thread
mehrere ADC und UART
[c]void ADC_Init(void) { ... ADMUX = (1<<REFS0);[/c] [c]int Read_ADC1() { ... ADMUX = (1<<MUX0);[/c] x = 1; x = 2; Welchen Wert hat x nach diesen beiden Zeilen?
Ausgabe]] genau so an: [C] /* ADC Einzelmessung */ uint16_t ADC_Read( uint8_t channel ) { // Kanal waehlen, ohne andere Bits zu beeinflußen ADMUX = (ADMUX & ~(0x1F)) | (channel & 0x1F); ... [/C] und weist nicht
-
Thread
Warum ist das AVR-GCC Tutorial so bescheiden?
Programmiersprache C. Ich beherrsche C grundlegend insofern, als dass ich Bits manipulieren, Funktionen schreiben, if-else und for-Schleifen implementieren kann. Ich habe Erfahrungen im Programmieren in C# und Matlab, das
immer nur auf einzelne Aspekte und nicht auf den µC oder die C-Programmierung als Ganzes beziehen, kann es keinen vom Anfang bis zum Ende durchgehenden roten Faden geben. Man sollte die einzelnen Kapitel eher als eine
-
Thread
PIC18F1220 (C-Code) Port (einzelnen Pin) abfragen
Hi! Seit etwa einer Woche beschäftige ich mich mit PICs, z.Z. eigentlich nur mit dem 18F1220 (weil ich lieber in C schreiben möchte). Ich benutze MPLAB X und PICkit3. Soweit so gut! Bis jetzt habe ich es geschafft Ports ein und auzuschalten (LED blinken lassen), den Wert eines Potis mit ADC zu bestimmen und ein LCD zu initialisieren (mehr oder weniger gut). Nun wollte ich wegen dem LCD die Busy-Flag abfragen können und da viel mir auf, dass ich bis dahin noch nie ein High-Low Signal an einem Pin abgefragt habe. Doch genau das bekomm ich einfach nicht gebacken und weiß nun einfach nicht mehr weiter
-
Thread
Atmega88 am STK500 ADC will einfach nicht
danke für die schnelle Antwort wenn ich das [c] ADCSRA |= (1<<ADSC); [/c] einfüge (zB am Ende des if konstrukt), ändert sich leider nichts. Ich will natürlich den free-running-mode. Ich denke, ich habe ihn durch [c] ADCSRB = 0; [/c] schon
alternativer Namen ADCW eingeführt, wobei im Assemblermodus nur ADCW zur Verfügung steht, während unter C sowohl ADC als auch ADCW äquivalent nutzbar sind. Der Vorteil der 16-bit-Pseudoregister ist, dass bei den Registern, bei denen für das Lesen oder Schreiben der Teilregister eine bestimmte Reihenfolge
-
Thread
Wittig(welec) DSO W20xxA Hardware (Teil 2)
interessant buggy, auch abhängig vom FPGA-Bitstream. Mir sind 2 Versionen bekannt. Mein Scope kam mit 8C7, seit ich es umprogrammieren kann habe ich mit 1C9 rumgespielt. So wie die Abfragen in der alten Firmware programmiert sind ist 8C7 die neuere FPGA-Version. In Osoz habe ich einen Testbutton eingebaut
auch 0 oder auch 1 sein müßte. In den Raw ADC Werten dieses gestörten ADCs müßte es daher ein Bit (D5 oder D6 ...) geben, das sich nie ändert. Eine Maintenance Funktion, die die Datenübertragung überprüft, indem sie den DAC Wert verändert und dabei überprüft, ob die einzelnen Bits der Raw ADC
-
Thread
Wie zerstöre ich Festplatten richtig?
dabei handelte es sich allerdings um einen riesigen Aufwand und die Datenmenge betrug nur einige einzelne Bit's. Ein einmaliges Überschreiben z.B. mit DBAN reicht also auch für sehr heikle Daten völlig aus. Ist man paranoid, dann bohrt man danach noch mit einem stumpfen 10er Bohrer dreimal durch den
eben überall. Wer weiß schon, ob in der Festplatte nicht ein kleiner Sender eingebaut ist, der jedes Bit sendet, welches rein- und rausgeht?
-
Thread
Struct ins EEPROM schreiben
dem Verständnis der Funktion "eeprom_write_block" Folgendes - ich möchte eine Struktur welche 14bit groß ist (2 Byte) ins EEPROM schreiben in dieser Struktur stehen Zustandsmeldungen. Einzelne Bytes ins EEPROM schreiben hat bei mir funktioniert, aber ich glaube ich habe den Syntax noch nicht ganz
) ) // beide gleich 0? wenn dir das zu geschwätzig ist, dann mach dir eine Funktion dafür [C] uint8_t EqualBitValues( uint8_t Bit1, uint8_t Bit2 ) { return ( Bit1 && Bit2 ) || ( !Bit1 && !Bit2 ); } .... if( EqualBitValues( state.V_2, PORT_OUT & (1<<V2) ) ) .... [/C] Das
-
Thread
myAVR PORT Expander
sollte wenigstens in etwa wissen, wo es lang geht. Man kann z.B. die jeweils 2 Ports auch als 16-Bit-Port benutzen; Je nach Anwendung kann das günstiger sein. um die Ports einzeln ansprechen zu können, würde ich twiInitPCA() z.B. so ersetzen (ich kann mangels Chip nichts testen): [c] #define
myavr workpad plus gibt es codebeispiele und auch die der TWI. aber zunächst zu deinem code: [c] #define ADDRESSMASK 0b00001110 // ??? #define PORTMASK 0b00000001 // ??? // DDR einzeln setzte, port=0..15; je 2 auf einem PCA9555 void twiInitPCA_DDR(uint8_t port