-
Thread
STM32F4 lässt sich nicht mehr programmieren
ap 0 reg 18 PSP 0x00000000 10:26:04:844 : run ap 0 10:26:04:848 : w ap 0 @0x20001770 0x00000B70 bytes Data 0x431369BA 10:26:04:848 : W B2 in RAM @0x20008400 size 0x00000B70: 0011ms 10:26:04:861 : r ap 0 reg 0 R0 0x00000001 10:26:04:861 : Wait W B1 in Flash @0x08000000 size 0x00000B70: 0009ms 10:26:04:861 : w ap 0 reg 0 R0 0x08000B70 10:26:04:861 : w ap 0 reg 1 R1 0x00000B70 10:26:04:861 : w ap 0 reg 2 R2 0x20001770 10:26:04:861 : w ap 0 reg 3 R3 0x00000002 10:26:04:861 : w ap 0 reg 4 R4 0x00000000 10:26:
-
Thread
Fehler durch Signalabgreifen
_35<='0'; -- LO_22<='0'; -- LO_35<='0'; -- RX_TR_22<='0'; -- RX_TR_35<='0'; -- ADC_Trigger<='1'; -- else -- case set_mode is -- when "001" => -- copolar -- TX_22<=event_1 and not(event_2)
Die Simulation funktioniert ja einwandfrei. Ich benutze ModelSim 6.4b. Das ganze läuft auf einem XC2C512-PQ208.
-
Thread
NRF24L01 (SPI Problem) sendet nur Status
: [code] -Received: AUT NRF SPI TX: 0x0A --- SPI_Transfer --- NRF SPI RX: 0xE Now send 5 times 0xFF --- SPI_Transfer --- NRF SPI RX: 0xE7 --- SPI_Transfer --- NRF SPI RX: 0xE7 --- SPI_Transfer --- NRF SPI RX: 0xE7 --- SPI_Transfer --- NRF SPI RX: 0xE7 --- SPI_Transfer --- NRF SPI RX: 0xE7 -Next Command... -Received: AUT NRF SPI TX: 0x0A --- SPI_Transfer --- NRF SPI RX: 0x1C Now send 5 times 0xFF --- SPI_Transfer --- NRF SPI RX: 0x0 --- SPI_Transfer --- NRF SPI RX:
-
Thread
Oldi Oszi mit min. 500Mhz empfehlenswert?
sich dann nur für repetive Signale, was aber nicht unbedingt ein großer Nachteil sein muss. 54600 2Kanal 100MHz 54601 4Kanal 100MHz 54602 4 Kanal 150MHz 54603 2 Kanal 60MHz Unbedingt auf ddie B-Variante achten. alle 20Msamples und 2 K Speicher 54645 sowohl A als auch D hat Megazoom 200Msamples
Hinweise. Ist denn eine differential Probe unbedingt notwendig? Kann man denn nicht beide Leiter (z.B. RX+ u. RX-) jeweils einzeln Messen gegen GND des Senders (z.B. Switch). Die P6247 kostet in der Tat eine Stange. Ich habe mich aktuell nach den P6243 u. P6245 umgeschaut. Diese sind noch recht günstig
-
Thread
elektronischer Schalter
Hi, wie kann ich mein Problem lösen? Ich habe eine USB-Interface mit den 2 Ausgängen für RX und TX. Möchte mit dieser 2x2 verschiedene Eingänge schalten. Einmal RX1/TX1 und per Schalter wechseln auf RX2/TX2. RX1/TX1 ist ein Chip und RX2/TX2 ist ein anderer Chip. Ich hoffe,
>>Ich habe eine USB-Interface mit den 2 Ausgängen für RX und TX Lies dir diesen Satz mal durch. A)Was für ein USB Interface ist das denn? USB <-> RS232 ? B)2 Ausgänge für RX und TX? RX ist ein Eingang Hast du nun 2x TX oder 2RX
-
Thread
STM32-SPI-Code Feedback
. [c] void transmit_receiveData(uint64_t tx_data, uint64_t* rx_data) { uint8_t tx_count = 0; uint8_t rx_count = 0; uint8_t rx_byte[5]; uint8_t tx_byte[5]; tx_byte[0] = tx_data >> 32; tx_byte[1] = tx_data >> 24; tx_byte[2] = tx_data >>
Lesekommando. Der 2. Transfer kann irgendwas enthalten zB Schreibkommando + Daten und liefert SPI Status und die Daten zum Lesekommando des 1. Transfers. Noch was, das BSRR Register verodert man eigentlich nicht. Pins
-
Thread
DVBT mit 2MHz Bandbreite
Zollprobleme? )was mich ein wenig wundert. Es gab wohl mal noch einen anderen Anbieter, der aber nur B2B anbietet, und sich glaube ich aus diesem Segment zurückgezogen hat. Mich wundert es allerdings das in den Einzugsgebieten von ATV Relais, mit einen Zugang zu DVBT 70cm 2MHz, noch keiner zu finden
Ralph B. schrieb im Beitrag #6004787: > Ich habe nie von DVBT2 gesprochen, sondern von DVBT mit 2MHz Bandbreite. > Natürlich ist das nicht Konform mit EN300744, welche nur 5-8MHz > vorsehen. Du scheinst
-
Thread
UART parallel schalten
aussehen mit dem Decoder? Hab einen rausgesucht, aber wie es scheint braucht der 6 Leitungen A, B, C und G1, /G2A, /G2B. http://www.ti.com/lit/ds/symlink/74ac11138.pdf
aussehen mit dem Decoder? > > Hab einen rausgesucht, aber wie es scheint braucht der 6 Leitungen A, B, > C und G1, /G2A, /G2B. Die "restlichen" Pins kommen auf statische Pegel wie GND oder VCC. Sollte man nach kurzem Studium des Datenblatts aber selber drauf kommen.
-
Thread
Gibt es mehrere Varianten der ZDF-Mediathek?
mp4 480x270 325k , avc1.66.30, mp4a.40.2 hls-325-1 mp4 480x270 325k , avc1.66.30, mp4a.40.2 hls-611-0 mp4 512x288 611k , avc1.77.30, mp4a.40.2 hls-611-1 mp4 512x288 611k , avc1.77.30, mp4a.40.2 hls-1217-0 mp4 640x360 1217k , avc1.77.30, mp4a.40.2 hls-1217-1 mp4 640x360 1217k , avc1.77.30, mp4a.40.2 hls-1979-0 mp4 960x540 1979k , avc1.77.30, mp4a.40.2 hls-1979-1 mp4 960x540 1979k , avc1.77.30, mp4a.40.2
-
Thread
Arduino Sketch-Upload via USB nicht möglich wenn MAX232 verbunden
getsync() attempt 6 of 10: not in sync: resp=0x69" Erst als ich den MAX232 vom Arduino getrennt habe (RX, TX Pin) hat der Upload funktioniert. Wer kann mir sagen warum sich der Arduino so verhält und warum Rx, Tx Pins nicht mit dem MAX232 verbunden sein dürfen, damit der Sketch-Upload via USB funktioniert
Falk B. schrieb im Beitrag #7403767: > Tobias schrieb: > >> Erst als ich den MAX232 vom Arduino getrennt habe (RX, TX Pin) hat der >> Upload funktioniert. > > Logisch, denn der Bootloader nutzt den
-
Thread
Uart empfängt immer das selbe
int b = rx >> 2; int d = (rx & 3) << 6; PORTB = b; PORTD = d; } int main(void) { // Enable 8 Outputs connected to LEDs. DDRB = (1 << PB0) | (1 << PB1) |(1 << PB2) |(1 << PB3)
Loris I. schrieb im Beitrag #4133895: > void rx_to_led(int rx){ > // Maps the parameter to the 8 output-LEDs > int b = rx >> 2; > int d = (rx & 3) << 6; > > PORTB = b; > PORTD = d; > } Stimmt diese Funktion? Hast du
-
Thread
Maschinendaten auslesen
Dirk B. schrieb im Beitrag #5763316: > Versuch eine Verbindung nur mit 1,2 und 5. Versuch nur mit Pin 1,2 und 5 hat leider nicht funktioniert. Keine Daten kommen am PC an. Dirk B. schrieb im Beitrag
Dirk B. schrieb im Beitrag #5763355: > Es gibt Geräte, die haben die Pin-Bezeichnung vom PC genommen. > Da musst du TX mit TX und Rx mit Rx verbinden. > Bei anderen mustt du die Leitung kreuzen. Habe
-
Thread
DCF-Signal richtig auswerten
// Berechnung des Tages in DEC day = lookupRotate[rxBuffer->Day >> 2] + 10*(lookupRotate[rxBuffer->Day & 0x03]); // Berechnung des Monats in DEC month = lookupRotate[rxBuffer->Month >> 2] + 10*(lookupRotate[rxBuffer->Month &
stehen. Für die Zehner-Minuten nehme ich den ermittelten wert mal 10. [code] mm = lookupRotate[rxBuffer->Min >> 3] + 10*(lookupRotate[rxBuffer->Min & 0x07]);[/code] [code]const uint8_t lookupRotate[16] = {0b0000, 0b1000, 0b0100, 0b1100, 0b0010, 0b1010, 0b0110, 0b1110, 0b0001, 0b1001, 0b0101, 0b1101
-
Thread
Datenstrom auf Zeichenkette untersuchen
ZHE_counter=2; } if(rx_data==69 && ZHE_counter==2) { ZHE_counter=3; } if(ZHE_counter == 3) { usart1_buffer[usart1_rx_index++]=rx_data; //
dann via HAL noch den Interrupt mit der HAL_UART_Receive_IT() aktivieren: [c] static void MX_USART2_UART_Init(void) { /* USER CODE BEGIN USART2_Init 0 */ /* USER CODE END USART2_Init 0 */ /* USER CODE BEGIN USART2_Init 1 */ /* USER CODE END USART2_Init 1 */ huart2.Instance = USART2
-
Thread
Steckerbelegung Rx<>Tx
Normalerweise verdrahtet man TX Quelle auf TX Buchse, sodaß das die Leitung ist, die Scharf ist. RX entsprechend gegenteilig. Im Gegensatz zu UART gibt es in der Netzwerktechnik 2 helfende Umstände: wenn's nicht passt kannst du gekreuzte Kabel verwenden (Muss man z.B. machen, wenn man 2 pc's direkt
PCs gab. Spätestens wenn man nicht ein VT100-Terminal mit einem Post-Modem verbinden wollte, sondern 2 V24-Anschlüsse miteinander. Meine V24-Kabel hatten daher immer an beiden Enden Stecker und Buchse. Und zum Test hatte ich ein Kästchen mit Umschaltern zwischen direkt und gekreuzt für Rx/Tx, RTS/CTS
-
Thread
Architektur für "background" Uart-Transmission
Falk B. schrieb im Beitrag #4282410: > Noch ein Tip. Wenn man 115k2 Baud hat sind das 11,5 kB/s. Wenn man > sowieso einen 10 kHz/100uS Timerinterrupt hat, kann man dort ohne > Prüfung ein Byte auf die Reise
Falk B. schrieb im Beitrag #4282410: > Noch ein Tip. Wenn man 115k2 Baud hat sind das 11,5 kB/s. Wenn man > sowieso einen 10 kHz/100uS Timerinterrupt hat, Das ist Oberpfusch. Das Problem ist, daß der
-
Thread
zu wenig LED's/Anzeigen auf dem Altera-/Intel-Board?
: in std_ulogic; rx_data : out character; -- received data rx_ready : out std_ulogic; -- received data valid rx_data_req : in std_ulogic
Ja der FT(2)232H kann volles USB 2, aber wenn man den nur als UART verwendet, dann kann er 12MBit/s.
-
Thread
8bit Datentransfer von int16-Werten
Byteweise packen typedef struct { char h; char l; } tbytes union { int16 i; tbytes b; } wert; #pragma pack() // Packweise zurückstellen //Empfänger: wert.b.h=owx_rx_buffer[pos]; wert.b.l= owx_rx_buffer[pos+1]; //Sender: owx_tx_buffer[pos]=wert.b.h;owx_tx_buffer[pos+1]=wert.b.l
,pos) buf[pos]=wert>>8;buf[pos+1]=wert int main(void) { int16_t a =-800,b; uint8_t buf[2]; set_tx16(a,0); //buf[0]=a>>8; printf (": %d \n", a); printf (": %d \n",buf[0]); printf (": %d \n",buf[1]); b=get_rx16(0); printf ("b: %d \n",b); return 0;
-
Thread
Erstes "richtiges" Projekt
bewegt man Gewehr unweigerlich und damit erhöht sich die Gefahr das das Messgerät bricht. Bilder 1 und 2 lassen m.M.n. erahnen: A. wie spröde das Material ist und B. wie "filigran" die Befestigungsmöglichkeit ist. Auch wenn man das geschmeidigste Silikonkabel verwendet besteht dann immer noch die Gefahr
erwarteten mindestens 3V. Versuche mal einen niedrigeren Pull-Up Widerstand, zum Beispiel 3,9kΩ oder 2,2kΩ.
-
Thread
Umwandlung von zwei uint8_t in uint16_t erzeugt falschen Code?
0x00 ; 0 a8: e9 01 movw r28, r18 aa: 90 e0 ldi r25, 0x00 ; 0 ac: 8c 2b or r24, r28 ae: 9d 2b or r25, r29 } static void foo(uint16_t value) { if (value > 1000) b0: 33 e0 ldi r19, 0x03 ; 3 b2: 89 3e cpi r24, 0xE9 ; 233 b4: 93 07 cpc r25, r19 b6: 10 f0 brcs .+4 ; 0xbc <main+0x28> { PORTA |= (1<<PA0); b8: 10 9a sbi 0x02, 0 ; 2 ba: f1 cf rjmp .-30 ;
-
Thread
Preamp / Vorverstärker für 0,3 - 150 MHz
Stufe 2: 8 dB großsignalfest Stufe 3: BGA612 mit 17dB, 2dB NF, IOP3 nur 17 dBm Glaubst du, Stufe 2 würde sich diskret lohnen? Kannst du da etwas zaubern :-) Den Sendemischer habe ich übriges gerade mal
BGA616 von Infineon. Die o. g. Anforderungen mit Ergebnis: - Frequenzbereich s. o. -> DC bis 2,7 GHz - Verstärkung ~0/15/30 dB schaltbar -> 0/20 dB mit Analogschalter - Rauschzahl < 2 dB -> 2,2 dB bei 100 MHz + Analogschalter - Impedanz beidseitig 50 Ohm -> Ok - IP3 > 25 dB -> 29 dBm
-
Thread
STM32 FreeRTOS Projekt (Makefile - GCC)
angepasst: [code] MEMORY { RAM (RWX) : ORIGIN = 0x20000000 , LENGTH = 64K FLASH (RX) : ORIGIN = 0x08000000 , LENGTH = 512K FLASHB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0 EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0 EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0 EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0 EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0 } /* higher address of the user mode stack */ _estack = ORIGIN(RAM)+LENGTH(RAM); [/code]
-
Thread
Kurzwellenantenne für Empfang am Weltempfänger
Drehkondensator mit 300...500pF verbinden. Zur Auskopplung Schleife durch einen Ringkern führen, z.B. T68-2. Ringkern mit ~10 Windungen Draht versehen, Draht an Empfänger anschließen. Empfangsbereich ist so 5...15MHz. Willst du mehr, mußt du die Geschichte Erweitern und Umschaltbar machen.
wurde getestet im Gerät und mit Messgerät. Er stammt aus dem Röhrenradio Philips Philietta de Luxe B2D94A, wurde aber auch bei vielen anderen Geräten verbaut. -------------------------------------------------------
-
Thread
RS232 Pegelkonverter
es sich um Open Kollektor oder Totem Pole oder was handelt. Also z.B. an RxD 0 und 30 V anlegen und den Eingangsstrom messen. Dann kann man davon ausgehen, dass der Ausgang TxD zum Eingang RxD kompatibel ist, aber was weiss man schon genau. Georg
Andi B. schrieb im Beitrag #4692043: > Du hingegen scheinst lieber selbst Dinge reinzuinterpretieren Ja genau, deswegen habe ich ja vorgeschlagen, z.B. den RxD-Eingang auszumessen - Lesen ist einfach nicht
-
Thread
C-Programmierung/DCF77
[30]+dcf77_rx[31]+dcf77_rx[32]+dcf77_rx[33]+dcf77_rx[34]+dcf77_rx[35]) % 2) == 0) && (((dcf77_rx[21]+dcf77_rx[22]+dcf77_rx[23]+dcf77_rx[24]+dcf77_rx[25]+dcf77_rx[26]+dcf77_rx[27]+dcf77_rx[28]) % 2) == 0) && (dcf77_rx[20] == 1)) { [/c] Oder um das Datum(BCD-Codiert) in Dezimalzahl umzuwandeln [c] date_day = dcf77_rx[36] + 2*dcf77_rx[37] + 4*dcf77_rx[38]+ 8*dcf77_rx[39] + 10*dcf77_rx[40] + 20*dcf77_rx[41
-
Thread
STM32 Receive via SPI immer um ein paar Bytes versetzt
Telegramm etwas nicht in Ordnung war. Natürlich können andere Werte auch andere Fehler bezeichnen. b) Ein Telegramm kann *niemals* mit 0xFF anfangen und kann *nicht* länger als z.B. 74 Bytes sein. Deswegen weiss der Slave wenn der Master sich z.B. beim 25-sten Byte resettet: 1) Nach weiteren
da etwas zu kollidieren, weil er immer wieder im SPI_Abort an dieser Stelle hängt: /* Change Rx and Tx Irq Handler to Disable TXEIE, RXNEIE and ERRIE interrupts */ if (HAL_IS_BIT_SET(hspi->Instance->CR2, SPI_CR2_TXEIE)) { hspi->TxISR = SPI_AbortTx_ISR; while (hspi->State != HAL_SPI_STATE_ABORT
-
Thread
12bit, 9-Kanal Soft-PWM für LEDs auf Mega16
Codevision, Optimize4Speed //Gammakorrektur flash unsigned int gammaArray22[256] = { 0,0,1,1,2,3,4,.......,4090,4095 }; //Variablen unsigned int c1r, c1g, c1b; unsigned int c2r, c2g, c2b; unsigned int c3r, c3g, c3b; unsigned int pwmCounter; unsigned char rxCounter; // Atmega IO konfigurieren
wieder ausknipsen if (pwmCounter==c1r) { PORTA.0 = 0; } if (pwmCounter==c2r) { PORTA.1 = 0; } //... if (pwmCounter==c3b) { PORTB.7 = 0; } //Serielle Behandeln if (UCSRA&RX_COMPLETE){ //RX_COMPLETE ist von CV definiert rxCounter++; if (rxCounter==1) {
-
Thread
ein Byte senden aber wie?!
kann es sein, dass Du TxD und RxD verwechselt hast? Invertiert werden muss nix bei uC zu uC. Nur wenn ein Partner RS232 Pegel verwendet, also +-12V, dann wird logisch '1' zu -12V, was dann mit einer Primitiv-Empfangsschaltung (z.B
Byte empfangen? in MovementMode,udr ;ja, Byte übernehmen ;weitere Mainloop-Jobs Diese 2 Zeilen kosten dich ganze 2 Takte Rechenzeit und bewirken das Selbe wie deine Routine. Hat aber den Nachteil, dass man keine weiteren Programmzeilen einfügen kann, z.B. das Setzen eines Flags, um andere
-
Thread
Unlösbares Problem - Serielle Schnittstelle LPC2138
läuft sie immer noch, zwar sehr langsam, aber sie läuft. Ich hab z.B. mal Debugausgaben über die UART gemacht, als Interrupthandler hats nicht funktioniert, aber im Main im Polling-Mode habe ich alle Debugausgaben erhalten. 2. Jeder Zugriff auf die Interruptregister
abfragen, sondern musst die drei Bits zusammen abfragen. Das war richtig von dir gedacht. status &= 0b00001110; // Bits 3:1 gelten status >>= 1; // um Bit 0 wegzubekommen ;-) if ( status == 0b010 ) // Empfang - RDA { rx_buffer1 = U1RBR; rx_counter1 = 1; } else if ( status == 0b110
-
Thread
STM32F10x USB VCP Einsteiger
du mit deinen sonstigen Setup's fertig bist. Ach ja, schau in die Quelle, bei mir liegt er auf Port B: PB2, das ist bei dir vermutlich anders. D+ und D- müssen natürlich zur USB-Buchse gehen, logo. Bei mir sind da noch jeweils 33 Ohm in der Leitung. Und VBUS liegt m.W. auf Port G: PG15 Die ganzen
Dummy-IR-Handler-Adressen siehst du im Startupcode. Dort sollte sowas stehen: DCD USB_LP_CAN1_RX0_IRQHandler ; USB Low Priority or CAN1 RX0 und EXPORT USB_LP_CAN1_RX0_IRQHandler [WEAK] W.S.
-
Thread
STM32F4 USART1
musste nur die entsprechenden Pins ändern. Die ganzen USART können auf verschiedenen Pins laufen z.B. für USART 1 PA9/10 oder PB6/7. Es werden die entsprechenden Pins genommen die du in dem untenstehenden Code siehst/einstellst. Bedenke USART1 hängt am APB2! [c] USART_InitStructure.USART_BaudRate
MII_TXD1 PB13 MII_RXD1 PC5 MII_RXD0 PC4 MII_RX_DV/RMII_CRS_DV PA7 MII_RX_CLK/RMII_REF_CLK PA1 MII_MDC PC1 MII_MDIO PA2 Heinweis: Damit ist der MEMS Sensor nichtmehr nutzbar. Mit dem Ethernet (
-
Thread
pySerial Probleme
try: while rx != "\n": rx = self.rx() rx_buffer += rx return rx_buffer except: print("rx_buffer fail") else: return "None" def rx_filter(self): rx = "" rx = self.rx_buffer_read() command = "command" data = "data" if "#" in rx: rx = rx[1:] return rx, command
-
Thread
Serielle Kommunikation STM32 -> ESP8266 klappt nicht
Hi, - GND ist verbunden? - Loopbacktest ( TX/RX kurzschließen) auf ESP-Seite klappt auch? - Was sagen die UART-Fehlerbits auf ESP-Seite ? - ist die Baudrate auf beiden Seiten von einer ausreichend genauen Quelle (zB Quarz/kalibrierter RC-Oszillator
einmal alles überprüft und frisch angeschlossen, und siehe da: [code] ets Jan 8 2013,rst cause:2, boot mode:(3,2) load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d v8b899c12 ~ld Init done. [/code] Dieser Fehler wiederholt sich ca. alle Sekunde. rst cause 2 steht
-
Thread
RS-Pegel +15/-15V auf Mikrocontroller Pin führen?
. Es kann also sein, das du besser noch einen kleinen Widerstand von den Dioden zum MC einfügst, z.B. so 220-470 Ohm.
parasitären und nich genau spezifizierten > "Schutzdioden", sondern eben ein externes Diodenarray (z.B. BAV99S) > nehmen. Kommt auf den Controller an. In einer AN von Atmel z. B. werden direkt 230 V - über einen entsprechenden Widerstand - zum Pin geführt.
-
Thread
Funktionszeiger und Funktionen mit unterschiedlich vielen Argumenten
Hallo, geht das ? Ist auch noch typesicher. typedef void (*tfnp2) (int,int); typedef void (*tfnp3) (int,int,int); union vproc { tfnp2 p2; tfnp3 p3; }; typedef union vproc tfnpx; void fn2 (int a, int b) { } void fn3 (int a, int b,int c)
p; }; void fn2 (int a, int b) { printf ("%d %d\n" , a,b); } void fn3 (int a, int b,int c) { printf ("%d %d %d\n" , a,b,c); } struct iv INIT[] = { {1,2,0,fn2}, {5,6,7,fn3}, }; void call
-
Thread
RS232 auf TTL Belegung / Anschluss
Erstmal bei DTE Pin2= RX Pin3= TX Pin5= GND Sender und Empfänger Pin3 gegen Pin5 messen ob die +/-3V bis 12V haben. Wenn das der Fall ist: 2+3 kreuzen. Wenn nicht: 2 zu 2 und 3 zu 3 cu
Gerät, Dein GSM Modem auch. Die Buchse wäre am Computer. Du brauchst also ein Nullmodenkabel, also 2-3 gekreutzt mit 2 Buchsen. Ob RX/TX/GNS reichen, hängt davon ab, ob das GSM-Modem ohhne Hardwarehandshake läuft bzw. die Schnittstelle so eingestellt werden kann. Aonst müssen eben CTS/RTS/DTR/DSR
-
Thread
Einfaches Bussystem, theoretische Frage
Adernpaar für RX und TX. Spannungsversorgung auf dem anderen Paar. Protokoll: Master - Multislave mit Polling. Bitstuffing zur leicherten Synchronisation bzw 8b/10b Code Leitung: "RJ11" Kabel bzw Telefonverlegekabel
nur ein Adernpaar für RX und TX. > Spannungsversorgung auf dem anderen Paar. > > Protokoll: Master - Multislave mit Polling. Bitstuffing zur leicherten > Synchronisation bzw 8b/10b Code > > Leitung: "RJ11" Kabel bzw
-
Thread
einfache und performante W5500 LIB
>Für Daten relativ problematisch oder wenig Sinnvoll da der >Buffer vom W5500 pro Socket nur 2k groß ist. Stimmt nicht ganz. Du kannst für jeden Socket einen TX- und einen RX-Buffer zwischen 0 und 16k festlegen. Die Grenze von 16k pro Summe der TX-/RX-Buffer bleibt natürlich bestehen. MfG
W5500. Es gibt zwei Möglichkeiten festzustellen ob neue Pakete angekommen sind. A: per ISR B: lesen des Registers RX_RSR um die Differenz zwischen read u. write pointer sich ausgeben zu lassen. Beim lesen muss man aber eins beachten! Das mitunter wenn man nicht schnell genug ließt können
-
Thread
Schaltregler 16V => 3,3V ~120mA gesucht
typisch 75dB ripple rejection. Das fällt bei 100kHz schon auf 35dB. Und weiter als bis 100kHz reicht das Diagramm gar nicht ...
connected CT For using connected CT signals inside the Transformer or inside RJ45 the matching network (2x 50R) of the RX+/- signals must be isolated from CT (3.3V). For that isolation we need C23 and C24. Also nur bei verbundenen Center-Taps ? Aber das Ref. Layout wird doch sicher so funktionieren
-
Thread
STM32F103: bei UART1 remapped funktioniert der UART1 Interrupt nicht
GPIOB PIN6 and PIN7 (alternative function) */ GPIO_InitTypeDef gpiob_init_struct; RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1 | RCC_APB2Periph_AFIO | RCC_APB2Periph_GPIOB, ENABLE); GPIO_PinRemapConfig(GPIO_Remap_USART1, ENABLE); /* Enalbe clock for USART1, AFIO and GPIOA */
USART_Cmd(USART1, ENABLE); /* Baud rate 9600, 8-bit data, One stop bit * No parity, Do both Rx and Tx, No HW flow control */ usart1_init_struct.USART_BaudRate = 9600; usart1_init_struct.USART_WordLength = USART_WordLength_8b; usart1_init_struct.USART_StopBits = USART_StopBits
-
Thread
Einfacher Kopfhörerverstärker mit OpAmp NE5534
verstärkt ein Line-Signal. Um den OP nicht zu überlasten, bekommt er einen "dicken" Vorwiderstand Rx. Der Kopfhörer hat einen Gleichstromwiderstand von 32R. Frage: kann das so funktionieren und wie groß muss Rx sein für eine 2-fache Verstärkung?
das auf Deine eigenen Beiträge? Der Schalldruck moderner Kopfhörer liegt grob zwischen 90-110dB/mW. Nur mal als Beispiel, die "100dB-Grenzen" von ein paar Hörern: Koss Portapro 1mW -> ~220mV -> 100dB AKG K141 Studio 1mW -> ~210mV -> 100dB Grado (viele) 2mW -> ~230mV -> 100dB
-
Thread
(R)MII auf FPGA einsynchronisieren
> Was ich leider auch nicht ganz verstanden habe, ist ob der RX und der TX > Clock zueinander synchron sind, oder ist das vom Phy Baustein abhängig? TxCLK und RxCLK sind zueinander asynchron zum Einsynchronisieren kannst du entweder mit einem höhreren interen Takt des FPGAs die Signale abtasten. RxCLK und TxCLK sind 25 MHz also brauchst du mindestens 50 MHz zum Abtasten, oder du benutzt eine FIFO-Struktur, indem du z.B die Register, mit denen du die Rx-Daten empfängst, mittels RxCLK eintaktest
-
Thread
Atmega - RS232 funktioniert nicht
Manni wrote: > 1. Warum nimmst du 2 stop bits ? Hast du das auch im hyperterminal so > gesetzt ? Wenn der Sender 2 Stopbits sendet, ist es völlig wurscht, ob beim Empfänger 1 oder 2 Stopbits eingestellt sind. Nur umgekehrt ist es problematisch
UART verwendet -> etwas vor dem MAX, aber nichts dahinter Tx *und* Rx "von Hand" getoggelt -> etwas vor und hinter dem MAX => wahrscheinlich Rx und Tx vertauscht
-
Thread
Problem mit SW UART
) { OCR2 = RX_TIME_BIT_TIME; TIFR |= (1 << OCF2); if (ucRxCnt >= 8) { if (PIN_RX) { ucSWUARTData = ucInputShiftReg; bSWUARTReceived = TRUE; } ucRxCnt = 0; vSetEdgeDetect
ucRxCnt = 0; ucInputShiftReg = 0; TIFR |= (1 << OCF2); TIMSK |= (1 << OCIE2); }
-
Thread
Avr mit QT Creator auslesen?
Quellcode: void Dialog::on_Berechnen_clicked(bool checked) { int value=60; int value2=70; Dialog::updateRGB(QString("a%1b%2").arg(value).arg(value2)); qDebug() << value; } void Dialog::updateRGB(QString command) { if(arduino->isWritable()){ arduino->write(
den String ausgeben, nicht den Value. Quick&Dirty wäre so: [c] Dialog::updateRGB(QString("a%1b%2").arg(value).arg(value2)); qDebug() << QString("a%1b%2").arg(value).arg(value2); [/c] Ich glaube, du musst noch ein bisschen mehr über die Programmiersprache lernen, bevor du dich an Kommunikationsschnittstellen
-
Thread
2 unterschiedliche Baudraten auf einem ATMEGA128
mich jetzt falsch versteht. > Ich muss: > - Eine bidirektionale Verbindung mit 921.8k betreiben (RX / TX) > - Eine bidirektionale Verbindung mit 250.0k betreiben (RX / TX) Du hast 2 Verbindungen und dafür 2 UARTs zur Verfügung, wo ist das Problem? Gruss Reinhard
ziemlich jede Baudrate mit ausreichender Genauigkeit bei 16 bzw. 32MHz Systemtakt einstellen. Und 2 UARTs haben die meisten xMegas außerdem. Z.B. der ATXmega64A3 hat 2 UARTs im TQFP64 Gehäuse. Oder nimm gleich den ATXmega128A1 im TQFP100 mit 4 UARTs. Ansonsten ist IMHO nur die Lösung mit 2 ATmegas
-
Thread
ATmega8 und UART => Code bringt Einsteiger zum Verzweifeln
(0V bis 5V) lese ich am ADC0 ein > * PD2 wird high, wenn der ATmega8 den MAX487 zum Senden freigibt Mit cbi(PORTD,PD2); Soll der MAX487 auf RX oder TX geschaltet werden? Und ein paar ns später erwartest Du in if(zeichen==0x0D
high, wenn der ATmega8 den MAX487 zum Senden freigibt > Mit cbi(PORTD,PD2); > Soll der MAX487 auf RX oder TX geschaltet werden? > Und ein paar ns später erwartest Du in > if(zeichen==0x0D) > daß ein komplettes Zeichen eingelesen wurde? Mit cbi(PORTD,PD2) wird der
-
Thread
DCF träger empfangen
Ist der Witz nicht, das der Träger mit der CS2 in Phase ist? Wieso moduliert man denn dann den Träger? Habe ich das Richtig verstanden, das die Modulation sich im Mittel aufhebt?? Also wenn ich zB einen Abgleich eines Zählers anhand des Trägers
XSD und XKE... nur noch für Romantiker und Sentimentale ... Hier fand ich noch Unterlagen über den Rx: http://bama.edebris.com/manuals/rohdeschwarz/xke2rx/ Ciao Wolfgang Horn
-
Thread
Hile beim Verständnis von ARM Befehlen.
; CODE XREF: ROM:0000168C↑p ROM:000016AE 03 25 MOVS R5, #3 ROM:000016B0 1B E0 B loc_16EA ROM:000016B2 ; --------------------------------------------------------------------------- ROM:000016B2 ROM:000016B2 loc_16B2 ; CODE XREF: sub_16AE+40↓j ROM:000016B2 41 68 LDR R1, [R0,#4] ROM:000016B4 08 30 ADDS R0, #8 ROM:000016B6 0A 1C MOVS R2, R1 ROM:000016B8 2A 40
-
Thread
Leidiges Thema RS232!
Schmidt schrieb im Beitrag #2532743: > Wenn Du den Adapter testen > möchtest, verbinde einfach die RX und TX Leitung. Wenn Du jetzt ein Byte > in HTERM sendest solltest Du es sofort empfangen. Danke für die gute Antwort. Und was ist wenn ich auch ohne verbinden von RX und TX mein eigenes gesendetes
noch genau umgekehrt. ------- | |TX ----------- --------- Mega |--->| z.B. |--------->| RS232-| USB | |RX | MAX232 | RS232 | USB |-----------| PC |<---| Wandler |<---------| |-----------| | | | | |