-
Thread
AT90USB an usbser.sys Handshake?
Hallo Ulrich, CDC ist Bulk-Transfer. Für Interrupt-Transfer brauchst Du keine usbser.sys. Ich kenne jetzt das Beispiel von Atmel nicht, aber Du kannst ja den AVR so programmieren, dass er erst anfängt zu senden, wenn er vom Terminal
-
Thread
Billige Bluetooth-USB Dongle direkt am µC
reichelt: >>bluetooth usb2 preis:--- technische daten: ...... - File Transfer, DUN, LAN Access, Serial Port, Active Sync, OBEX, Fax, >HID >>DELOCK 61273 preis:8,90€ File Transfer, DUN, LAN Access, SerialPort, Active Sync, OBEX, Fax, >HID die beiden unterstützen
-
Thread
ENC28J60 Basics[Beispielprogramm in AVRGCC für atmega8]
while(len--){ char c = pgm_read_byte(&buffer[0]); buffer++; /* Transfer char c to ENC */ ... } else while(len--){ c = *buffer++; /* Transfer char c to ENC */ ... [/C] kann man so auch auf eeprom erweitern.
-
Thread
SPI-Kommunikation zwischen zwei ATTiny2313
received data return UDR; } // Function for transmitting data via SPI-Interface void SPI_Transfer(unsigned char data) { // Load data into the data-register USIDR = data; } int main (void) { unsigned char u8Data; DDRB = 0xFF; // Initialize USART and SPI USART_vInit()
& (1<<UDRE))); UDR = u8Data; // Transmit the received data to the SPI-Slave SPI_Transfer(u8Data); // Led on PORTB |= (1<<PB4); _delay_ms(500); // Led off PORTB &= !(1<<PB4); _delay_ms(500); } } [/c] Leider kann ich beim senden der Daten keine Reaktion
-
Thread
FT2232H Sync FIFO
Das geht zwar am schnellsten, aber nur wenn auf dem Bus Platz ist. Für Streaming gibts isochronen Transfer. Da bekommst du 24MB/s garantiert, aber eben keine Datensicherheit. Kannst oder willst du den Datentransfer nicht anhalten? Wir machen das bei uns so ähnlich wie Speicher-Oszi, der Host PC fordert
benutze den FT232H - nicht FT2232H - und lediglich im asynchronen 245 FIFO Mode zum einseitigen Bulk Transfer FPGA->PC, das ist also noch deutlich einfacher) ebenfalls festgestellt, dass ausgehend von einem absolut fehlerfreien Datentransfer auf einmal sporadische Fehler auftraten, nachdem ich von meinem
-
Thread
FTDI unter Linux per cutecom, minicom, hterm ansprechen
5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint
5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 can't get
-
Thread
SENT Schnittstelle
Hall-Sensoren anstelle der bekannte PWM-Schnittstelle eine sog. SENT-Schnittstelle. (Single Edge Nibble Transfer) Beispielsweise der Infineon TLE4998S4. Die Vorteile und die Funktion von SENT leuchten mir grundsätzlich ein, ist ne tolle Sache. Was mich interessieren würde: hat jemand schon Erfahrungen mit
anstelle der bekannte > PWM-Schnittstelle eine sog. SENT-Schnittstelle. (Single Edge Nibble > Transfer) Beispielsweise der Infineon TLE4998S4. Die Vorteile und die > Funktion von SENT leuchten mir grundsätzlich ein, ist ne tolle Sache. > > Was mich interessieren würde: hat jemand schon Erfahrungen
-
Thread
LCD W204B-NLW
delays mehr. Wenn du dein Display direkt an einem parallel-Port hast, kannst du einfach den I²C-Transfer weglassen, aber die Bytes, die du in dein Port schreibst sind die selben. Nur für das passende Timing mußt du dann selbst sorgen (delay())
Byte. > Wenn du dein Display direkt an einem parallel-Port hast, kannst du > einfach den I²C-Transfer weglassen, aber die Bytes, die du in dein Port > schreibst sind die selben. > > Nur für das passende Timing mußt du dann selbst sorgen (delay()) ok ich versuche das Mal
-
Thread
SPI-Slave ATSAMD51 / 24 Bit Frames empfangen
einen weiteren GCLOCK zu belegen, läut der CPU-Core jetzt auch auf 100 MHz. Statt dem zahmen SPI-Transfer von oben habe ich jetzt das hier im Master laufen: [code] PORT->Group[1].OUTCLR.reg = PORT_PB01; SERCOM5->SPI.DATA.reg = 0x55; while((SERCOM5->SPI.INTFLAG.reg & SERCOM_SPI_INTFLAG_TXC) == 0)
PORT->Group[1].OUTSET.reg = PORT_PB01; counter++; [/code] Um das DATA Register nach dem Transfer nicht lesen zu müssen habe ich den Empfänger abgeschaltet. Die Lücken zwischen den Bytes und zum CS bekomme ich so nicht mehr kleiner. Das wird jetzt auch nicht mehr alle 150ms ausgeführt, sondern
-
Thread
Wer kauft noch Netztrafos?
das "analoge" Telefonnetz schon seit Längerem. > > https://de.wikipedia.org/wiki/Asynchronous_Transfer_Mode > > Wird jetzt auf IP umgemodelt. > "...Ersetzt wird die ATM-Technik durch Ethernet-basierte Technik und > IP-basierende VPNs...." > > Nur "Knöpfchen mit Köpfchen" funktioniert nicht
das "analoge" Telefonnetz schon seit Längerem. > > https://de.wikipedia.org/wiki/Asynchronous_Transfer_Mode > > Wird jetzt auf IP umgemodelt. > "...Ersetzt wird die ATM-Technik durch Ethernet-basierte Technik und > IP-basierende VPNs...." Fra N. schrieb im Beitrag #5265476: > oder wurde, wie
-
Thread
welches Filesystem
Dateisystem bietet sich da an? du könntest auch MTP verwenden https://de.wikipedia.org/wiki/Media_Transfer_Protocol
Dann bleibt dir in der Tat nur die Wahl, entweder MSD (mass storage device) oder MTP (media transfer protocol) zu implementieren. Und bei MSD hast du anschließend noch die Qual der Wahl, welches Filesystem auf dem exportierten Speicherblock drauf sein soll. Als kleinster gemeinsamer Nenner bleibt
-
Thread
USB-Tutorial mit STM32
parat? Ich hatte damals nen netten bug in der stm usb lib gefunden. damit funktionierte der Transfer von der webcam zum µC leider nicht.
als dem Einsatz von constexpr oder nicht. Jedenfalls in dem Teil deines Codes der am Ende für den Transfer zuständig ist, konnte ich keine modernen C++ Sprachmittel finden die den Code schneller oder kleiner machen. Niklas G. schrieb im Beitrag #5224967: > Wenn man nicht ewig auf den > Sprachmitteln
-
Thread
Atmega 16 Interrups
Overflow Handler jmp nix ;TIM0_OVF ;Timer0 Overflow Handler jmp nix ;SPI_STC ;SPI Transfer Complete Handler jmp nix ;USART_RXC ;USA RT RX Complete Handler jmp nix ;USART_UDRE ;UDR Empty Handler jmp nix ;USART_TXC ;USART TX Complete Handler jmp nix ;ADC ;
OVF0addr ;= 0x0012 ; Timer/Counter0 Overflow rjmp timer0 ;.org SPIaddr ;= 0x0014 ; Serial Transfer Complete ;.org URXCaddr ;= 0x0016 ; USART, Rx Complete ;.org UDREaddr ;= 0x0018 ; USART Data Register Empty ;.org UTXCaddr ;= 0x001a ; USART, Tx Complete ;.org ADCCaddr ;= 0x001c ;
-
Thread
Stack Monitor Disabled ????
reti ;TIMER0 COMPARE .org $016 reti ;TIMER0 OVERFLOW reti ;SPI Transfer beendet .org $01a reti ;UART byte empfangen .org $01c reti ;UART datenreg .org $01e reti ;UART transfer beendet reti ;ADC conversion
-
Thread
STM32F4 Ausführungszeit
verstanden habe ist das mit deinem Trigger. Bei dieser Methode wird dann pro Timer Event DMA-Transfer angestoßen und das Timing ist nicht mehr von der CPU abhängig.
CS): "3.5 Latch DAC Input (LDAC) The LDAC (latch DAC synchronization input) pin is used to transfer the input latch register to the DAC reg- ister (output latches, V OUT ). When this pin is low, V OUT is updated with input register content. This pin can be tied to low (V SS ) if the V OUT update
-
Thread
DMA per IPIF
Komonente schon relativ schön zusammen klicken läßt. Ich verstehe bisher nur noch nicht, wie der DMA Transfer wirklich abläuft. Hat jemand sowas schonmal gemacht oder kenn jemand Seiten/Foren, wo man fündig werden könnte?
, es wird aber das Prinzip von DMA erklärt. "Ich verstehe bisher nur noch nicht, wie der DMA Transfer wirklich abläuft." MFG Falk
-
Thread
Wired-Or-Bus statt TriState-Bus
-- read/write htrans : std_logic_vector(1 downto 0); -- transfer type ... testrst : std_ulogic; -- scan test reset scanen : std_ulogic; -- scan enable testoen : std_ulogic;
type ahb_slv_out_type is record hready : std_ulogic; -- transfer done hresp : std_logic_vector(1 downto 0); -- response type hrdata : std_logic_vector(AHBDW-1 downto 0); -- read data bus hsplit : std_logic_vector(NAHBMST
-
Thread
I2C, ATxmega und EMV - Ein Erfahrungsbericht
ich Konstruktionen wie die Folgende in den ASF-Libraries etwas peinlich: while (! twim_idle(transfer.bus)) { barrier(); } Ein einziger Fehler, und das Ding hängt für immer.
Konstruktionen wie die Folgende in den > ASF-Libraries etwas peinlich: > > while (! twim_idle(transfer.bus)) { barrier(); } > > Ein einziger Fehler, und das Ding hängt für immer. ...oder bis der WDC zuschlägt :-)
-
Thread
ATM32F030 + ADC + DMA
beobachten, dass TIM1->CNT bis zum vorgeschriebenen Wert hochzählt und wieder von vorne beginnt. Das „Transfer Complete Flag“ vom DMA1 Channel 1 wird jedoch nie gesetzt. Ich weiß leider echt nicht mehr weiter und hoffe, dass jemand von euch mir ggf. ein paar Tipps geben kann. Gruß
dass TIM1->CNT bis zum > vorgeschriebenen Wert hochzählt und wieder von vorne beginnt. > Das „Transfer Complete Flag“ vom DMA1 Channel 1 wird jedoch nie gesetzt. wo ist dein: [c]TIM1_IRQHandler(){ und TIM_ClearITPendingBit(TIM1, TIM_IT_Update); //hier den richtigen flag raussuchen //ADC val
-
Thread
STM32H7 SPI HW-Fifos
Wird für jede neue Registeradresse ein neuer /SS-Zyklus benötigt, geht das wohl nur mit "TI mode transfer". Welchen Baustein willst Du denn auslesen?
für jede neue Registeradresse ein neuer /SS-Zyklus benötigt, geht das > wohl nur mit "TI mode transfer". > Welchen Baustein willst Du denn auslesen? Die Bausteine sind 3 x TDC7200 und soweit ich die H7 SPI verstanden habe sollte das direkt mit den eingebauten Hardware Fifos funktionieren. Das auslesen
-
Thread
20Euro Embedded System mit ARM, 128MB ram und 256MB Flash
. Siehe: > http://www.rudiswiki.de/wiki/DockStarAutoMountSamba > Ergebnis in Gigabit Netzwerk Transfer: > File size: 430 MB, using atop 5 (5 s interval) > CPU load 23% smbd > Read from DockStar NET so 21,6 MB/s > Write to DockStar NET si 9,0 MB/s > # with MOUNTOPTION sync in file /etc/usbmount
wsize spielen, siehe: https://wiki.archlinux.org/index.php/Nfs#Unreliable_performance.2C_slow_data_transfer.2C_and.2For_high_load_when_using_NFS_and_gigabit btw, Samba dürfte da um einiges langsamer sein.
-
Thread
Asssembleprogramm für Mega16 auf Mega8535 anpassen, Sprungweite "call" und "jmp"
Overflow .equ OVF0addr = 0x0009 ; Timer/Counter0 Overflow .equ SPIaddr = 0x000a ; SPI Serial Transfer Complete .equ URXCaddr = 0x000b ; USART, RX Complete .equ UDREaddr = 0x000c ; USART Data Register Empty .equ UTXCaddr = 0x000d ; USART, TX Complete .equ ADCCaddr = 0x000e ; ADC Conversion
Overflow .equ OVF0addr = 0x0012 ; Timer/Counter0 Overflow .equ SPIaddr = 0x0014 ; Serial Transfer Complete .equ URXCaddr = 0x0016 ; USART, Rx Complete .equ UDREaddr = 0x0018 ; USART Data Register Empty .equ UTXCaddr = 0x001a ; USART, Tx Complete .equ ADCCaddr = 0x001c ; ADC Conversion
-
Thread
stm32f103 dma-spi
adafruit-music-maker-shield-vs1053-mp3-wav-wave-ogg-vorbis-player/downloads wartest du darauf, das der DMA Transfer beendet wurde bevor du das 2. Device an SPI ansprichst ? Und wie kannst du DMA benutzen wenn du zwischen 2 CS umschalten musst ?
dasrotemopped schrieb im Beitrag #4889639: > wartest du darauf, das der DMA Transfer beendet wurde bevor du das 2. > Device an SPI ansprichst ? Und wie kannst du DMA benutzen wenn du > zwischen 2 CS umschalten musst ? Nur dieser Teil [c] uint8_t i; for (i
-
Thread
Wie bekommt man eine double Variable in ein char Array?
. Tom M. schrieb im Beitrag #2872715: > Wozu 32 chars? Ist der maximal zu erwartende spi transfer. Steffen
Steffen H. schrieb im Beitrag #2872759: > Ist der maximal zu erwartende spi transfer. > > > Steffen memcpy(spi_buf+pos*sizeof(double), &n, sizeof(double)); Wobei pos 0 ... sizeof(spi_buf) / sizeof(double). Vergiss das Shiften, ist so einfacher, natürlich musst du pos
-
Thread
STM32F4 SD-Karte sowohl in Applikation als auch über USB-MSC am PC zugreifbar
verwaltet werden kann. du müsste dafür auf MTP umsteigen (http://de.wikipedia.org/wiki/Media_Transfer_Protocol)
verwaltet werden kann. > > du müsste dafür auf MTP umsteigen > (http://de.wikipedia.org/wiki/Media_Transfer_Protocol) Vielen Dank für die schnellen Antworten. MTP liefert der STM-HAL leider nicht mit und ich will ihn nur ungerne selbst umsetzen... Dann bleibt es wohl bei entweder, oder. Nur aus interesse
-
Thread
rs232
have try to laplink and non cross rs232 cable, but it's not working at all ( i can't receive and transfer data). my question : how rs232 configuration on the pc side ? (on the device side you can take alook at file rs232.doc). thank you, and please respon asap ....
i'v try with laplink and non CROSS rs232 cable, but it's not working at all(i can't receive and transfer DATA). my question: how rs232 configuration on the PC side? (on the DEVICES side you CAN take alook at file rs232.gif). thank you, and please respon asap....
-
Thread
FTDI zerstört Fake Chips durch Windows-Update
ftdi-driver-kills-fake-ftdi-ft232/285/ die "versehentliche Protokollerweiterung": https://marcan.st/transf/ftdi_evil.png Für mich hat das Ganze schon Auswirkungen, auch wenn ich nur kleine Brötchen backe, es ist gerade ein Punkt auf dem Radar in Schottland verschwunden... Gruß, Holm
schrieb im Beitrag #3854764: > die "versehentliche Protokollerweiterung": > https://marcan.st/transf/ftdi_evil.png Na, wenn das mal nicht unter Computersabotage fällt. Interessant ist: FTDI erlaubt unter bestimmten Umständen auch die Benutzung "ihrer" Vendor- und Produkt-ID für andere, um mit
-
Thread
ADXL345 und ESP8266: Echtzeitdatenergassung mit konstanter Abtastrate und Interrupts
Messwert vorliegt (INT1 = high, kann auch einfach als Pin am Controller ausgewertet werden) SPI Transfer auslösen und Messwerte in Array eintragen an die Stelle an die der Zähler verweist und Zähler auf nächstes freien Eintrag zeigen lassen. Falls Zähler = Array Eintrag 45 ist UPD Paket mit Array Einträgen
die Register (readRegister). Hier bin ich mir nicht sicher, ob das der von Dir angesprochene SPI-Transfer ist. Da muss ich morgen nochmal ran. Ich würde mich sehr darüber freuen, wenn Du mit mir weiter die Lösung entwicklen könntest - bitte entschuldige meine vielleicht manchmal dummen Nachfragen -
-
Thread
HAL SPI TransmitReceive
} } } /* Check if we are in Rx only or in Rx/Tx Mode and configure the DMA transfer complete callback */ if (hspi->State == HAL_SPI_STATE_BUSY_RX) { /* Set the SPI Rx DMA Half transfer complete callback */ hspi->hdmarx->XferHalfCpltCallback = SPI_DMAHalfReceiveCplt
XferCpltCallback = SPI_DMAReceiveCplt; } else { /* Set the SPI Tx/Rx DMA Half transfer complete callback */ hspi->hdmarx->XferHalfCpltCallback = SPI_DMAHalfTransmitReceiveCplt; hspi->hdmarx->XferCpltCallback = SPI_DMATransmitReceiveCplt; } /* Set the DMA error
-
Thread
Verständnisfragen zu SSL Zertifikaten
Signatur soll Manipulaton der Daten unterbinden. So heisst es in der Schnittstellenspezifikation. Als Transfer-Medium wird HTTPS mit fest definierten Zertifikaten verwendet, aber das ist momentan nicht meine Sorge. Den privaten Schlüssel habe ich natürlich vorliegen. Den brauche ich ja ohnehin zum signieren
> Manipulaton der Daten unterbinden. So heisst es in der > Schnittstellenspezifikation. Als Transfer-Medium wird HTTPS mit fest > definierten Zertifikaten verwendet, aber das ist momentan nicht meine > Sorge. Im Prinzip kann Transport Layer Security (TLS -- das "S" in HTTPS) in den modernen
-
Thread
Frage zu Mapped PDO's bei CANOpen
restlichen 4 Daten. Das ist aber nur eine von 4 (PDO, Segmented SDO, Expedited SDO, Block SDO) Transfer-Möglichkeiten. Ein CANopen-konformes Gerät muss davon aber mindestens 3 (PDO, Segmented SDO, Expedited SDO) unterstützen. Holger B. schrieb im Beitrag #3518850: > Demnächst bekomme ich ein Gerät
Zusammensetzung der Nachrichten > analysieren. Wenn das Gerät CANopen-Konform ist, nein; dann musst du die Transfer-Art konfigurieren (durch ein eigenes Programm auf einem µC oder ein gekauftes Konfigurations-Tool) und kannst nach deinen Wünschen einstellen was da übertragen wird. Standardmäßig sendet ein CANopen-Gerät
-
Thread
Neues bei ST: STM32F217
die I2C-Einheit bugfrei ist. Diverse Quellen reinitialsieren die gesamte Hardware nach jedem I2C Transfer, vor allem kombinierte Read/Write Zugriffe bringen Probleme. http://www.mikrocontroller.net/topic/167193 http://www.jiangsheng.tk/56.html http://svn.openpilot.org/blame.php?repname=OpenPilot&
not possible to manage the EV7, EV7_1, EV6_1, EV2, EV8, and EV3 events before the current byte transfer and before the acknowledge pulse when changing the ACK control bit, it is recommended to: 1. use the I2C with DMA in general, except when the Master is receiving a single byte 2. use I2C interrupts
-
Thread
Interrupt Vektoren beim Mega32
;TIMER0 COMPARE .org $016 jmp GetKeys ;TIMER0 OVERFLOW reti ;SPI Transfer beendet .org $01a jmp empfangen ;UART byte empfangen .org $01c jmp TransINT ;UART datenreg .org $01e reti ;UART transfer beendet reti ;ADC conversion
-
Thread
RS485 Protokoll auf einen ATmega32
genau? Wie schließe ich denn nun die Schnittstellen-ICs an den uC an, wie steuere ich denn nun den Transfer? Kann mir jemand ma ein Codeschnipsel zukommen lassen wie dass für mein Problem aussehen könnte? (z.B. ich drücke am uC 1 einen Taster, der uC 2 soll das per RS485 "erfahren" und einen Ausgang schalten
potentialgetrennt mit MAX1490. Wie das aussieht steht in den Datasheets. > wie steuere ich denn nun den Transfer? Du schreibst, dass du RS232 schon mal verwendet hast. Genau so.
-
Thread
STM32F7 HAL DMA Interrupt Problem
(HAL_DMA_IRQHandler) erkennt den Interrupt nicht. Setze ich das Flag TCIF0 (bzw. HTIF0 für Half-Transfer) mittels CTCIF0 (bzw. CHTIF0) im Debugger manuell zurück, läuft alles wie gewollt weiter bis zum nächsten Interrupt. Der STM32 läuft mit SYSCLK = 216 MHz und APB2 = 108 MHz. Meine Funktionen lauten
{ /* Start Conversation Error */ Error_Handler(); } /* Disable all IRQ except Transfer Complete */ // hadcx.DMA_Handle->Instance->CR &= ((uint32_t)~(DMA_IT_HT | DMA_IT_TE | DMA_IT_DME)); } [/c] Die Init des DMA sowie des GPIO und die TMR Clock habe ich in der HAL MSP module integriert