-
Thread
Cortex I2C zu kurze Impulsdauer
Cortex wartet dann endlos auf Event 8.2 EV8 software sequence is managed before the current byte transfer completes */ while ((I2Cx->SR1 & 0x00004) != 0x000004) und nichts geht mehr. Mesungen mit dem Oszi haben folgende Details gezeigt: Beide senden mit ca 400 kHz, aber der Cortex hat eine geringere
mode we can not guarantee the EV8 software sequence is managed before the current byte transfer completes */ while ((I2Cx->SR1 & 0x00004) != 0x000004) ; //while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)); /* Send the current byte */ I2Cx->DR
-
Thread
STM32 F051 ADC Abtastrate
DMA_InitStruct.DMA_PeripheralDataSize = DMA_PeripheralDataSize_HalfWord; /* data size to transfer to peripheral */ DMA_InitStruct.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord; /* data size to transfer from memory */ DMA_InitStruct.DMA_Mode = DMA_Mode_Circular
DMA_InitStruct.DMA_M2M = DMA_M2M_Disable; /* data transfer from memory to memory? */ DMA_Init(DMA1_Channel1, &DMA_InitStruct); /* DMA1_Channel1 + DMA1_Channel2 belong to ADC1 */ DMA_ITConfig(DMA1_Channel1
-
Thread
STM32F1 SPI Slave DMA Problem (Raspberry als SPI Master)
An sich funktioniert das Ganze recht gut, - der Raspberry triggert hin und wieder einen SPI Transfer an und Daten werden ausgetauscht. Die MISO und MOSI Buffergrößen sind identisch und liegen bei 75 Byte und diese werden per DMA an den SPI angebunden. Wenn ich jetzt aber meine Debug-Umgebung verlasse
[code]AA BB BB 00 00 00 00 .... 00 00 02[/code] Triggert der Raspberry jetzt noch einmal den Transfer, so steht das richtige Datum im Buffer. Im Datenregister des STM32-SPIs steht sicher noch was Altes, ohne das es mit dem DMA Speicher abgeglichen wird. Meine Frage ist nun, wie kann man dem SPI am
-
Thread
Suche einfaches TWI Beispiel
- // Definition of local constants //------------------------------------------- // master transfer acknowledge for address or data #define TW_MT_ACK (u08)0x08 //------------------------------------------- // Function Prototypes //------------------------------------------- void TWI_init
); // start last byte transfer without acknowledge while (!(TWCR & (1<<TWINT))); // wait for response val[i]=TWDR; // read databyte from TWDR } else { UART0
-
Thread
XMEGA 16-bit DMA Burst Transfer für Display Parallel Bus
im Speicher liegen würden, wäre das kein Problem, dann liesse sich dies durch ein 2 Byte burst Transfer bewerkstelligen. Dies ist leider nicht der Fall. Die einzige Lösung die mir bisher eingefallen ist, ist folgende: Ich Kopiere die Daten in 2 Byte Blöcken mittels DMA burst Transfer irgendwo im
die Bytes angekommen sind benutzte ich 2 weitere DMA Kanäle um die von dem Abgeschlossenen Burst-Transfer getriggert werden um jeweils eines der Bytes in das richtige IO-Register weiter zu leiten. Das müsste funktionieren ist mir aber wirklich zu umständlich. Aber ich kann möchte noch nicht akzeptieren
-
Thread
Tonertransfer Ecke fehlt.
bemerkt. Egal ob dickes oder dünnes Papier, o.g. Problem ist auch ein Zeichen dafür, daß der Transfer noch nicht zu 100% ok ist. Irgendwas verhindert die hohe Haftkraft des Toners auf dem Kupfer. Evtl. erreicht die Platine keine ausreichend hohe Temperatur (beim Bügeln geht gern ein großer Teil der
da ein wenig Aceton drauf und wische dann damit die Platine ab. Danach wird auch sofort mit dem Transfer losgelegt. Ich raue das Kupfer nicht an, kann das vielleicht der Fehler sein, da manche dies machen ? Ich werde am Wochenende mal die Tipps ausprobieren. Vielen Dank für die Tipps
-
Thread
SPI Probleme zwischen STM32 und ADT7310
auf TXE. TXE sagt nur das das Transmit Register beschreibbar ist. Es sagt nicht das der letzte Transfer beendet wurde.
TXE. > TXE sagt nur das das Transmit Register beschreibbar ist. > Es sagt nicht das der letzte Transfer beendet wurde. Danke mach ich auch mittlerweile. Aber immer noch ohne Erfolg Gruss Roger
-
Thread
nRF24L01+ Funkübertragung mit AVR
Sept. 2008 (Rev. 1.0). Lass' dir doch 'mal die gesendeten und empfangenen Werte in der spi_transfer() ausgeben und schau', ob die plausibel sind. Bei SPI kommt die Antwort auf ein Kommando üblicherweise NICHT im gleichen Transfer (der Slave muss ja darauf erst reagieren), sondern im nächsten
-
Thread
Firmwareupdate via Modbus TCP
eigentlichen Modbus-Protokoll verwendet werden. Das Modbus-Protokoll aber sieht keinen Mechanismus für den Transfer beliebiger Binärdaten vor, d.h. ein Bezug zwischen Deiner Hex-Datei und Modbus ist ohne weitere Informationen nicht herstellbar. Gibt es die Dokumentation, aus der Du in Deinem Eröffnungsposting
. F. schrieb im Beitrag #5759832: > Das Modbus-Protokoll aber sieht keinen Mechanismus für den Transfer > beliebiger Binärdaten vor Modbus File Records ;) Das kann man dafür sehr kreativ missbrauchen. Aber ja ohne Doku der Geräte wirds hier nicht weitergehen.
-
Thread
Initialisierung des ADC
aus, der nebenher noch andere Dinge des Programms synchronisiert (z.B. Tasten-Entprellung, Byte-Transfer zum LCD, Zeitbasis für Blinken, usw.). Dabei achte ich darauf, dass das Timer-Intervall größer ist als das Abtastintervall des ADCs. Wenn ich schnell samplen muss, dann nutze ich den Interrupt
der nebenher noch andere Dinge des Programms synchronisiert (z.B. > > Tasten-Entprellung, Byte-Transfer zum LCD, Zeitbasis für Blinken, usw.). > > Dabei achte ich darauf, dass das Timer-Intervall größer ist als das > > Abtastintervall des ADCs. Meine Anwendung ist nicht soo zeitkritisch und
-
Thread
[V] PCI-CAN von National Instruments 1Port High Speed
single-wire versions • Hardware timestamping • Intel 80386EX microprocessor for timed CAN frame transfer • Optical isolation up to 500 V • Import Vector database files with NI-CAN Operating Systems • Windows 2000/NT/XP/Me/98 • LabVIEW Real-Time Application Software (included) • Bus monitor
NI-CAN Number of Ports 1 Physical Layer High-Speed Maximum Transfer Rate 1 Mbits/s Minimum Transfer Rate 40 kbits/s Termination External Transceiver Philips TJA1041, Built-in Hardware Synchronization
-
Thread
ADC1 TIM1 DMA HAL H7
Init.DMAContinuousRequests = ENABLE; // diese Zeile manuell Ziel: bei jedem T1_TRGO soll eine ADC Wandlung + DMA Transfer ausgeführt werden (Daten an Zieladdr per DMA überschreiben). Ich habe die Vermutung, dass dieser DMA transfer aktuell nicht ausgeführt wird, wenn der vorgehende transfer noch nicht quitiert ist.
-
Thread
ADE7753 SPI-Problem
read_command ) { digitalWrite (ss,LOW); unsigned char b2,b1,b0; delayMicroseconds(25); SPI.transfer (read_command); delayMicroseconds(5); b2 = SPI.transfer(0x00); delayMicroseconds(5); b1 = SPI.transfer(0x00); delayMicroseconds(5); b0 = SPI.transfer(0x00); delayMicroseconds(5); digitalWrite
-
Thread
SD-Card mit DMA beschreiben
25; res=send_cmd(CMD25,kksectors); DMA0_from_buffer_to_SSP0_init(); DMA0_from_buffer_to_SSP0_transfer(0,516,0xfc); _delay_ms(100); DMA0_from_buffer_to_SSP0_end(); _delay_ms(100); //verify wait;wait;wait;wait; for(i=0;i<512;i++)buf_rx[i]=255; res=f_open(&Fil2, Dateiname, FA_READ | FA_OPEN_EXISTING
Aufruf von [c]void DMA0_from_buffer_to_SSP0_end(void){ DMA_STATUS=2; abfr_busy(); DMA3_transfer_from_SSP0_to_buffer(32); } [/c] Hier wird der rxfifo und wohl auch ein DMA-fifo geleert, so dass anschließend ohne Konflikte mit elm chan weitergearbeitet werden kann. Warum es hier 32 bytes
-
Thread
BCD Z ählen (AVR ASM)
reti ;Timer1 Overflow Handler reti ;Timer0 Overflow Handler reti ;SPI Transfer Complete Handler reti ;UART RX Complete Handler : RXCIE reti ;UDR Empty Handler reti ;UART TX Complete Handler reti ;ADC Conversion Complete Interrupt Handler
reti ;Timer1 Overflow Handler reti ;Timer0 Overflow Handler reti ;SPI Transfer Complete Handler reti ;UART RX Complete Handler : RXCIE reti ;UDR Empty Handler reti ;UART TX Complete Handler reti ;ADC Conversion Complete Interrupt Handler
-
Thread
Hardware CRC in Paketen
CRC eingerechnet, was ja so nicht funktionieren kann. Damit ergibt sich der ungünstige Weg, DMA Transfer zwei Byte kürzer (ohne CRC), im "DMA Block done" Interrupt die CRC nochmal berechnen und noch einzeln senden. Beim Empfang ergibt sich dann das gleiche Problem. Irgendwie kann ich nicht glauben,
oder du hast ein DMA-System, dass die CRC Bytes automatisch nachschieben kann. Einfach beim DMA-Transfer zuerst mal eine irgendwie vom Himmel gefallene Scheisdreck-CRC mitsenden und dann noch eine über den gesamten Block automatisch berechnete zweite CRC hinterherschieben ist ja wohl gaga.
-
Thread
SSH bestimmte Benutzer nur bei bestimmter IP-Adresse
AllowUser ... wird also "AllowUser ..." nur bei diesem Adressbereich angewandt. Shell-freien Transfer für selektive User/Adressen gibts beispielsweise über Subsystem sftp internal-sftp ... Match ... ForceCommand internal-sftp ... > Langsam verstehe ich nicht mehr, wie ich es noch lösen
besser. https://man.openbsd.org/sshd_config https://en.wikibooks.org/wiki/OpenSSH/Cookbook/File_Transfer_with_SFTP Obacht: scp != sftp. Nutzt zwar beides sshd, ist aber verschieden.
-
Thread
USB verbindet nur FullSpeed, aber nicht HighSpeed
Address: 0x02 Open Pipes: 2 Endpoint Descriptor: bEndpointAddress: 0x81 Transfer Type: Bulk wMaxPacketSize: 0x0200 (512) bInterval: 0xFF Endpoint Descriptor: bEndpointAddress: 0x00 Transfer Type: Control wMaxPacketSize: 0x0507 (1287)
-
Thread
Wittig(welec) DSO W20xxA Open Source Firmware (Teil4) Gesperrt
in Deinem Post neulich so verstanden, dass Du da an der freien Stelle einen Button für den USB-Transfer hinhaben wolltest. Hab ich Dich da falsch verstanden? Wir können das natürlich noch ändern bei Bedarf. Gruß Hayo
Anzahl der Shifts eingestellt? In der Software wird fleißig auf serdata->np_piodata zugegriffen, der Transfer anscheinend mit serstartsw->np_piodata ausgelöst. Jörg
-
Thread
TxD buffer beim ATXMega32E5 mehr als ein Byte?
DMA_TX_ESP_CHANNEL.ADDRCTRL |= EDMA_CH_DIR_INC_gc; // increment source address during transfer DMA_TX_ESP_CHANNEL.ADDRCTRL |= EDMA_CH_DESTRELOAD_NONE_gc; // destination address does not need to be reloaded DMA_TX_ESP_CHANNEL.ADDRCTRL |= EDMA_CH_DESTDIR_INC_gc; // Memory address
DMA_TX_ESP_CHANNEL.CTRLA = EDMA_CH_SINGLE_bm; // single shot mode (i.e. one burst transfer per trigger event) DMA_TX_ESP_CHANNEL.CTRLB |= EDMA_CH_TRNINTLVL_HI_gc; } void main(void) { EDMA.CTRL |= EDMA_ENABLE_bm; PMIC.CTRL |= PMIC_HILVLEN_bm | PMIC_MEDLVLEN_bm
-
Thread
Erprobte Werte für T_AS (Address Setup Time) bei HD44780 und Design-Probleme
Frage: muss man erst SPI deaktivieren oder kann man den Port auch manuell setzen wenn gerade kein Transfer im Gange ist? P.S.: Danke nochmal für die Unterstützung im Timer-Thread, hat auch bei der LCD-Bibliothek geholfen, die längeren Wartezeiten habe ich jetzt über eine Call-Back-Function gelöst,
: muss man erst SPI deaktivieren oder kann man den Port > auch manuell setzen wenn gerade kein Transfer im Gange ist? SPI wird wohl abgeschaltet werden müssen; alternativ kann man auch ganz auf SPI verzichten und die Bits per Software setzen/löschen. Seinerzeit hatte ich ein 6502-Derivat verwendet
-
Thread
Fehler beim vergleichen zweier Werte
union { struct { unsigned RunProg:1; // Run Programm unsigned TransferError:1; // Daten Transfer Error unsigned RunService:1; // Run Service }; // unsigned short Byte; unsigned char Byte; } PicGlobal ProzessStatus; Code in der *.c #define
-
Thread
Atmels USBKey läuft nicht mit Atmels HID-Demo!
Joystick-Status zurück liefern, durch einen konstanten String ersetzt und konnte diesen String in USBSpy als Transfer-Paket empfangen. Das letzte, was ich probiert habe, ist die Atmel AtUsbHID.dll durch SW zu ersetzen, die mir als Source vorlag (siehe http://www.lvr.com/hidpage.htm (http://www.lvr.com/files/HidTest.zip
Lösung hab ich noch nicht, aber ich experimentier grade mit der Puffer Länge. Bei einem Generic Data Transfer über HID muss - soweit ich weiß - die Pufferlänge exakt mir der Länge des out reports übereinstimmen ... Ich melde mich, wenn ich weiter komme und würd mich über jeden neuen Ansatz freuen...
-
Thread
Yocto Linux, bitbake und device tree
arguments depending on 'source' source=tftp|nfs -> [filename] - filename: file to transfer (required if using a partition name) source=usb|mmc|hsmmc|sata -> [device:part filesystem] [filename] - device:part: number of device and partition - filesystem: fat|vfat|ext2|ext3 - filename: file to transfer source=ram -> <image_address> <image_size> - image_address: address of image in RAM - image_size: size of image in RAM [/code] Vielen dank schonmal :)
-
Thread
36-bit auf 128-bit Worte effizient mappen
hättest du die Effektive Nutzungsrate von 72/128 auf 108/128 (~56% auf ~84%) gebracht bzw jeden 3. Transfer eingespart. Ansonsten könntest du auch 7 Wörter in 256 Bit Packen. Da wären nur 4 Bit Verlust auf 256 Datenbit. Wenn es unbedingt sein muss, 0 Bit Bandbreitenverlust zu haben dann wirst du um ein
hättest du die Effektive Nutzungsrate von 72/128 auf 108/128 (~56% > auf ~84%) gebracht bzw jeden 3. Transfer eingespart. > Ansonsten könntest du auch 7 Wörter in 256 Bit Packen. Da wären nur 4 > Bit Verlust auf 256 Datenbit. > Wenn es unbedingt sein muss, 0 Bit Bandbreitenverlust zu haben dann > wirst
-
Thread
Verständnisfrage zu Assembler bei PIC und ATMEL
anderen Architekturen heutzutage oft wegoptimiert wird. Und so macht das GCC ja auch. Aber der Transfer von XYZ zum SP ist nicht atomar und das ist bei Interrupts entscheidend. > Ich programmiere recht viel in Assembler Die Problematik bezieht sich auf C. In Assembler liegen lokale Daten selten
> Aber der Transfer von XYZ zum SP ist nicht atomar > und das ist bei Interrupts entscheidend. Das sollte eigentlich kein Problem sein, da der AVR beim Interrupt-Aufruf weitere Interrupts blockiert. Man kann SPH/SPL
-
Thread
Asus Tinkerboard startet nicht
4] local 192.202.0.2 port 52530 connected to 192.202.0.1 port 42000 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 0 417 KBytes [ 4] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 0 417 KBytes [ 4
460 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver IO: (SD-Karte
-
Thread
Breitbandige Ferritantenne
//media.internet11.de/PDF/508195.pdf "Input Capacitance = 2.4pF " - ist das Cgs? "Reverse Transfer Capacitance = 0.035pF " - ist das Cgd?
unterschiedlich verrechnet. Passt also nicht. rolf schrieb im Beitrag #6494688: > "Reverse Transfer Capacitance = 0.035pF " - ist das Cgd? Jain. Normalerweise sind die Kapazitäten ohne Biasspannungen anzugeben und werden dann nach bestimmten Kurven verrechnet. Der 2SK544 ist da aber sehr untypisch
-
Thread
STM32f2 ADC + DMA
transmission // and reception) Leave as default (direct mode) // 9. Configure the: // - data transfer direction, dma_set_transfer_mode(DMA2, DMA_STREAM0, DMA_SxCR_DIR_PERIPHERAL_TO_MEM); dma_set_transfer_mode(DMA2, DMA_STREAM2, DMA_SxCR_DIR_PERIPHERAL_TO_MEM); // - peripheral and memory incremented
DMA_STREAM2); // - Double buffer mode // Not enabled // - interrupts after half and/or full transfer, // ADC_MultiModeDMARequestAfterLastTransferCmd(ENABLE); // Not yet... // - and/or errors in the DMA_SxCR register. // Not yet... /***** Last step: enable streams again. Activate the
-
Thread
MBED IDE PATA Ansteuerung
mMMD_HDD_SECTOR_COUNT(); // Number of sector (512Byte) to be transfered PMDIN = 0x1; // transfer only one sector while(PMMODEbits.BUSY); // Wait until PMP is free mMMD_HDD_COMMAND_REGISTER(); // Set READ COMMAND*/ #ifdef DEBUG_MODE UART2PrintString("READ10 Sector
IDE_A0 = 0; // SectorCount if(blocks == 256) PMDIN = 0; // transfer 256 sector else PMDIN = blocks; // transfer x sector while(PMMODEbits.BUSY); // Wait until PMP is free IDE_A2 = 1; IDE_A0 = 1; Nop
-
Thread
µC und SDRam Performance, packen die das?
verstanden habe, agiert DMA2D ziemlich selbstständig, man kann nur eine gewisse "DeadTime" für den DMA2D-Transfer festlegen die dann für andere Peripherie freisteht. Diese habe ich gerade so eingestellt, dass das LCD noch synchron seine Daten bekommt. Nun geht es mir darum, dass kein AD-Wert verloren gehen
und das kostet nur die Zeit für die Bus-Arbitration (scheußliches Wort..) und den eigentlichen Transfer, aber was nun, wenn die Daten nicht maht bei X sondern bei Y dastehen? Zum Verarbeiten kannst du nen DMA nicht nehmen, das muß dir CPU tun. W.S.