-
Thread
Einstieg in PCIe DMA Transfer zur Grafikkarte und CUDA
Hallo, ich suche einen Weg große Datenmengen per PCIe Steckkarte (von Lattice währe schon ein Demoboard mit PCIe da) über DMA zur Grafikkarte zu übertragen. Das ganze dann per CUDA oder OpenGL zu verarbeiten (FFT + Kreuzkorelation + ...) und auf dem Bildschirm darzustellen. Gibt es irgend welche änlichen Projekte oder empfehlenswerte Literatur zu diesem Thema? Mfg Michael
-
Thread
BLE Module mit Dualcore CPU: interrupts & sandbox
Daten auch live verarbeiten möchte muss der DMA (oder mit weiterem Peripheral): - automatisch Transfer triggern bei DRDY interrupt - Memoryaddresse nach jedem Transfer ändern können Das können manche, aber denke ich nicht alle Mikrocontroller. Die Anforderung ist, dass ich in Echtzeit (also höchste Interruptpriorität) alle 100µs einen DMA transfer starten kann. Wenn der Controller/DMA das automatisch kann, entfällt die Echtzeitanforderung.
-
Thread
TLC549CP: Spannungen über 5V (bis 15V) messen
byte readSPI(int csPin){ byte temp; pinMode(csPin, LOW); // ADC aktivieren temp = SPI.transfer(0); // Daten empfangen pinMode(csPin, HIGH); //ADC deaktivieren return temp; } [/c]
geben (t_su) temp = SPI.transfer(0); // Daten empfangen pinMode(csPin, HIGH); //ADC deaktivieren return temp; } [/c] Nach wie vor ist das Resultat weder linear, noch stabil. Der Wert schwankt und ist immer wieder 0
-
Thread
Displaya 16-Bit Mode?
write to shift register to begin transmission while( !SPI1STATbits.SPIRBF); // wait for transfer to complete return SPI1BUF; } [/c] Irgendetwas muss mit den SPI Leitungen/Initialisierunge noch im Argen sein. Jemand der sich mit dem Controller auskennt und auf Anhieb eine Idee hat?
swmiso_v) SPI_byte++; // capture current bit on MISO #endif } return (SPI_byte); } // END SPI_Transfer [/c]
-
Thread
brauche Hilfe für Problem mit Auto-Display
Number of channels : 2 Resolution : 8-bit UART (SCI) Number of channels : 1 Clock synchronous transfer : 62.5 Kbps to 1 Mbps Clock asynchronous transfer : 1202 bps to 31250 bps Supports bi-directional and master-slave communications. Extended I/O serial interface Number of channels : 2 Clock synchronous transfer : 31.25 Kbps to 1 Mbps (Using internal shift clock) Transmission format : Selectable LSB-first or MSB-first LCD controller/driver Number of common outputs : 4 Number of segment outputs : 32 Number
-
Thread
WS2811 mit SPI(atmega 2560)
gebraucht. Es geht auch sparsamer auf dem STM32. Man nehme: - einen Timer - zyklischen DMA-Transfer für jeweils 2 LEDs - ISR, welche den DMA-Buffer nach dem halben Transfer (also nach Datenübertragung für 1 LED) nachfüllt. RAM-Bedarf: 48 Bytes - unabhängig von der Anzahl der LEDs.
Frank M. schrieb im Beitrag #5064679: > - ISR, welche den DMA-Buffer nach dem halben Transfer (also nach > Datenübertragung für 1 LED) nachfüllt. Der Sinn (DMA) ist aber gerade in dem Fire-and-forget Prinzip. Wenn ich alle paar us irgendeine ISR anspringen muss, wird das Ganze
-
Thread
Tonertransfer will nicht
dagegen wenn der gute Jung auch ma nen anderes Verfahren zum Vergleich ausprobiert, bevor er am Transfer versagt.
Sicher. Aber da das Transfer-Verfahren billig, einfach und schnell (probiert) ist, sollte man denke ich dem immer zuerst eine Chance geben. Ein bisschen probieren gehört da schon zu, ich hab auch etwas gebraucht um das richtige
-
Thread
SAR ADC erzeugt Spikes während AD Wandlung?
am ADC-Pin Ch4 (blau): FPGA-Signal, Sampling-Phase waehrend HIGH 1: kein Sampling, kein USB Transfer -> keine hochfrequenten Spikessichtbar 2: Sampling mit 160kHz, kein USB Transfer -> minimale Spikes auf dem Rohsignal und zwischen OP4 und Lowpass; deutliche Spikes direkt am ADC-Pin 3: Zoom-In von 2 4: Sampling mit 160kHz, USB Transfer nur in den Sampling-freien Intervallen gestattet, gleiche Zoom-Stufe wie 3 -> Die Uebertragung mittels FT232H erzeugt ein minimales weiteres Artifakt auf allen Kanaelen, aber hier werden ja auch 10
-
Thread
USB-Kombigerät: zwischen HID und MSC umschalten
/* wMaxPacketSize */ 0x00, /* bInterval: ignore for Bulk transfer */ /* Terminator */ 0 /* bLength */ };[/c]Hat jemand eine Idee, in welche Richtung ich suchen muss? Schöne Grüße, Peter
konfiguriert habe, bekomme ich auf dem Bus regelmäßig (alle 32ms, klar) einen "URB Bulk or Interrupt Transfer issued" und 64ms später den dazugehörigen (woher weiß der Bus eigentlich, welche Antwort zu welcher Anfrage gehört?) "URB Bulk or Interrupt Transfer succeeded" mit den Daten, die mein Gerät liefert
-
Thread
Problem mit SPI
Kollisionsflag. The WCOL bit is set if the SPI Data Register (SPDR) is written during a data transfer. The WCOL bit (and the SPIF bit) are cleared by first reading the SPI Status Register with WCOL set, and then accessing the SPI Data Register. Warum wird dieser Flag gesetzt? Hat jemand eine Idee
Es müsste eigentlich helfen, ein [c](void)SPSR;[/c] obendrüber zu schreiben (über den /ersten/ Transfer).
-
Thread
Null modem kabel für die Atto FibreBridge 7500n
das Kabel recht lang sein sollte, müßte man über die Paare nachdenken. Lt. HB: ZModem Allows transfer of a firmware bundle to or from the FibreBridge using the zModem file transfer protocol. Available only through the RS232 interface. ZModem [Send filename | Receive] https://de.wikipedia.org/wiki
-
Thread
Brauche Hilfe beim Routen einer Platine zum selber ätzen
seit ein paar Stunden den angehängten Schaltplan so zu routen, dass ich den selbst mit der Toner Transfer Methode herstellen kann. Ich krieg aber nichts hin, mit dem ich zufrieden bin. Die Eckbedingungen sind: - Nicht zu fein, damit ich das ätzen kann, ohne zuviele Anläufe zu brauchen - Die Bauteile
ein paar Stunden den angehängten Schaltplan so zu > routen, dass ich den selbst mit der Toner Transfer Methode herstellen > kann. Zu Toner Transfer kann ich wegen mangelnder Erfahrung nichts sagen. > Ich krieg aber nichts hin, mit dem ich zufrieden bin. Es gehört zum Lernprozess, das nichts
-
Thread
Handydummy (Attrappe)mit richtigem Display - Sony Ericsson Vivaz
Address: 0x01 Open Pipes: 3 Endpoint Descriptor: bEndpointAddress: 0x01 Transfer Type: Bulk wMaxPacketSize: 0x0200 (512) bInterval: 0x00 Endpoint Descriptor: bEndpointAddress: 0x82 Transfer Type: Bulk wMaxPacketSize: 0x0200 (512) bInterval: 0x00 Endpoint Descriptor: bEndpointAddress: 0x83 Transfer Type: Interrupt wMaxPacketSize: 0x0020 (32) bInterval: 0x0B Bilder hänge ich an... Gleich mal nach dem controller googlen. Muss mich aber erstmal um meinen Kater kümmern.
-
Thread
Audio Spektrum Analysator
unterstützt mehrere Übertragungsarten, darunter auch den isochronen Datentransfer: "Der isochrone Transfer ist für Daten geeignet, die eine garantierte Datenrate benötigen.". Guggst Du hier: http://de.wikipedia.org/wiki/Universal_Serial_Bus#Isochroner_Transfer Latürnich müssen die Full- bzw. High-Speed-Geräte
unterstützt mehrere Übertragungsarten, darunter auch den isochronen > Datentransfer: "Der isochrone Transfer ist für Daten geeignet, die eine > garantierte Datenrate benötigen.". > Guggst Du hier: > http://de.wikipedia.org/wiki/Universal_Serial_Bus#... Richtig, aber man muss auch die ganze Wahrheit
-
Thread
STM32F4xx UsartRx mit DMA
sie eine time_out für die DMA forsehen. Damit weisst du wen da ein Zeichen fehlt, den ende DMA-transfer kommt nur nach das alle Zeichen von ein Packet enpfangen sind.
genau weiß wieviele Bytes man empfängt. Eine Möglichkeit um overflow zu entgehen, könnte der Half-Transfer Interrupt genutz werden. Beispielsweise: Man will 20bytes empfangen. Den Buffer setzt man auf 40 Bytes. Mit ein wenig Phantasie lässt sich schon was machen. W.S. schrieb im Beitrag #4545061: >
-
Thread
data to ddr fehlgeschlagen
if transfer is successful * - XST_FAILURE if either the transfer fails or the data has * error * * @note None * ******************************************************************************/
int Length, int Retries) { int Status; Done = 0; Error = 0; printf("Start Transfer \n\r"); /* Try to start the DMA transfer */ Done = 0; Error = 0; /* Flush the SrcBuffer before the DMA transfer, in case the Data Cache * is enabled */ Xil_DCacheFlushRange
-
Thread
Zeilenwechsel bei LCD will nicht gelingen
write mode movlw B'00110000' ; InitLcd step 1: 8 bit interface call Transmit ; transfer 8 bit instruction signal movlw B'00110000' ; InitLcd step 2: 8 bit interface call Transmit ; transfer 8 bit instruction signal movlw B'00110000' ; InitLcd step 3: 8 bit interface call Transmit ; transfer 8 bit instruction signal movlw B'00100000' ; InitLcd step 4: 4 bit interface call Transmit ; transfer 8 bit instruction signal call LcdBusy ; Lcd busy? If Lcd busy, busy
-
Thread
Juce Audio Framework
Teil des Juce-Api hat kein ownership transfer, also nimmst Du einfach den smart pointer in deinem Code, um die Ressource zu managen und übergibst an die Funktionen den Raw Pointer und fertig. Das ist doch absolut korrekt so. Ok, du benutzt
nicht um das GUI zu designen, korrekt? Da kommen dann schon ein paar Raw-Pointer mit ownership transfer vor, aber das ist auch sehr explizit und klar und auf ein einziges Standard-Pattern beschränkt. Finde ich jetzt auch keinen Beinbruch. vlg Timm
-
Thread
Blödes Erlebnis mit Aliexpress Händler
jeden Fall kann man sie auch für andere Controller als ST benutzen. Aber warum hat der Geld-Transfer nicht geklappt, hat der kein PayPal?
> Aber warum hat der Geld-Transfer nicht geklappt, hat der kein PayPal? Hat er nicht. Und auch keinen Partner in Deutschland. Sonst hätte ich dem die Dinger geschickt. > Wie auch immer, ich würde Dir noch einen ST-Link Adapter
-
Thread
Debian Sarge und RS232/ttyS0 = Verzweiflung!
Ach ja Martin, um auf dein "transfer.h" zugreifen zu können müsste ich mich über KielNet einwählen - von einem anderen Provider aus klappts nicht... Peter
>um auf dein "transfer.h"..... Ich denke das lag an der Berechtigung, die war falsch gesetzt.
-
Thread
Unter Linux/Openwrt Treiber für andere VID/PID
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 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 16
-
Thread
HP LaserJet 2600n seltsames Phänomen
sind, die für jede Farbe extra gehalten sind. anbei ein paar, die mir gerade einfallen: - "Transfer roller" - Kontakt zwischen "Transfer roller" und "High voltage power supply" - Kontakt zwischen "Charge roller" (in Tonerkassette integriert) und "High voltage power supply" - Teil der Lasereinheit
-
Thread
Optokoppler - kleinster Eingangsstrom
ab, wieviel Strom du durch die LED sendest. Das Verhältnis dieser beiden Werte ist CTR (Current Transfer Ratio). Das Datenblatt verrät dir, in welchen Grenzen sich der CTR-Wert bewegt, aber nur für IF = 5 mA. Für andere Ströme könntest du anhand Fig. 11 abschätzen, wie weit der CTR reduziert ist,
Empfänger" des LED-Lichts. If ist der "Flußstrom", also der Strom durch die LED. CTR (current Transfer rate) ist schlicht die Stromverstärkung. 1mA LED-Strom erzeugen einen Ausgangsstrom zwischen 0,5mA...6mA.
-
Thread
ISA Bus 16bit IO Transfer Problem
hallo, ich habe eine ISA Karte gebastelt und will die jetzt gerade mit 16bit datenwörtern füttern. meine karte lauscht an der adresse 0x202, d.h. A0 wäre 0. bei einem 8bit zugriff bekommt er die daten ohne probleme! klappt alles bestens.. wenn ich allerdings vom PC aus den hier mache: assembler: mov eax, 8 out dx, ax dann bekomm ich den wert 0 zur karte, sowohl aufm lowbyte als auch aufm highbyte! bei: out dx, al klappt alles bestens! also da meine karte eh nur 16bit daten empfangen soll letztendlich, spar ich mir die auswertung von der BHE leitung. selstsamerweise reagiert meine
-
Thread
230V galvanisch getrennt erzeugen - Trenntrafo - fast keine Last
Andererseits funktioniert der Transfer nicht in beide Richtungen mit gleicher Übersetzung. Heisst, bei 230V auf 24V kommen zwar im Zwischenkreis 24V plus Leerlauf an, mit dem gleichen Trafo hochtransformiert kommen aber nur 200 oder
Karl schrieb im Beitrag #5479308: > Andererseits funktioniert der Transfer nicht in beide Richtungen mit > gleicher Übersetzung. Neue Naturgesetze gefunden?
-
Thread
FPGA - embedded Linux Interconnect Ansatz
recht flexibel. Kann bis 100 MHz Taktfrequenz und richtig lange Sequenzen (mehrere kByte in einem Transfer möglich). Also rein vom Datenvolumen sollte es machbar sein, das über die SPI Schnittstelle rüberzubekommen. Allerdings habe ich im Scope gesehen, dass je nachdem ob die DMA im SoC irgendwas
habe ich schon drüber nachgedacht, würde es aber wirklich so haben wollen, dass wenn ich einen SPI-Transfer mit der Größe X starte, dann sollen die Daten alle passennd alligned da drinnen liegen im Buffer dann. Ein reshuffeling würde ich gerne verhindern. Ja... irgendwie wird es auf einen ausreichend
-
Thread
sw spi tuning
cbi MOSI_DDR ldi r20, 8 ;8 bits to transfer SLAVE_TRANSFER_0: sbi MISO_PORT sbrs r16, 7 ;change if miso line should not be high cbi MISO_PORT SLAVE_TRANSFER_1: sbis SCK_PIN ;wait for h on sck rjmp SLAVE_TRANSFER_1 rol r16 ;get to next
sbr r16, 0 sbis MOSI_PIN ;change if bit in read register should not be set cbr r16, 0 SLAVE_TRANSFER_2: sbic SCK_PIN ;wait for l on sck rjmp SLAVE_TRANSFER_2 subi r20, 1 ;one bit more to transfer brne SLAVE_TRANSFER_0 ret Kann man die Routine noch schneller machen (abgesehen von loop unrolling
-
Thread
NAS Schreiben per WLan friert ein
Problem: Wenn ich vom Notebook aus eine größere Datei zum NAS per SMB übertragen will, fängt der Transfer normal an. Nach einer Weile werden keine Daten mehr übertragen. Wenn man den Transfer abbricht, verbleibt eine Datei auf dem NAS, auf die man nicht mehr Zugreifen kann. Nur ein Neustart des NAS hilft
den Tip. Ich habe all 4 Ports der Fritz auf "Eco Mode" 100MBit umgestellt. Nach ca. 2min ist der Transfer wieder abgebrochen. Der Windows Fehlercode ist 0x8007003B Meine suche nach dem Fehlercode finden nur Leidensgenossen aber keine Lösung :(
-
Thread
Tonertransfer und erste Ätzversuche: Was kann ich besser machen?
exakt Deckungsgleich, der Laminator scheint das Papier etwas weg zu ziehen. Problem 3: Nach dem Transfer lässt sich das Papier am besten in sehr warmem/heißem Wasser lösen. Egal ob Finger oder Zahnbürste: Wenn ich die Kupferbahnen vom Papier befreien will, reibe ich den anderen Toner wieder ab. War der
> nicht immer 100% gleich. Hab mit dem Reichelt-Papier auch durchwachsene Erfahrungen. Der Transfer geht gut, aber das Papier läßt sich nur mühselig entfernen. Ich verwende jetzt welches aus dem EMP-Katalog, das kann man fast vollständig abziehen, für die Reste genügt leichtes Rubbeln.
-
Thread
RauschfreieSpannungs-/Stromquelle
willst Du denn messen? Read-Noise misst man besser im Dunkeln. QE? Fixed Pattern Noise? Photon Transfer Curve?
willst Du denn messen? Read-Noise misst man besser > im Dunkeln. QE? Fixed Pattern Noise? Photon Transfer Curve? was ich genau messe will ich hier nicht erklären, das ist zu komplex und schafft nur Verwirrung. Wenn es jemanden wirklich brennend interessiert bitte am Ende der KW32 nochmal nachfragen
-
Thread
STM32F4 Discovery Audio DAC CS43L22
return 1; } uint16_t EVAL_AUDIO_GetSampleCallBack(void) { return 1; } void EVAL_AUDIO_TransferComplete_CallBack(uint32_t pBuffer, uint32_t Size) { } void EVAL_AUDIO_HalfTransfer_CallBack(uint32_t pBuffer, uint32_t Size) { } void EVAL_AUDIO_Error_CallBack(void* pData) { while(1
-
Thread
Optokoppler Datenblatt verstehen
CTR = Current Transfer Ratio, also das Verhältnis von Steuerstrom durch die LED zum mögl. Laststrom durch den Fototransistor.
Ja, habe ich im Datenblatt gefunden 5. Current transfer ratio (CTR : MIN. 50% at IF=5 mA, VCE=5V ,Ta=25℃ Dann würden bei meiner Schaltung mit 3K3 bei 15 Volt ca. 4mA durch die OK - LED fließen (14V/3300 Ohm) Der PulUp am Ausgang hat 470 Ohm
-
Thread
ESP8226 mit Bad Request
persistente Verbindung unterstützt? Weil er weder den Content-Length Header noch den Chunked-Transfer verwendet hat. Habe ich doch oben geschrieben. Ohne das kann er keinen 2. Request senden.
der Content-Length, b) beim Schließen der Verbindung, c) bei der Ende-Markierung vom Chunked Transfer (nur HTTP 1.1)
-
Thread
Belichten ist schwierig
Ergebnisse erhalten. Also Augen Auf beim Eier...äh Druckerkauf. Hat eigentlich schonmal die Bügel-Transfer-methode versucht? Bin schon seit einigen Jahren auf der Suche nach den entsprechenden Laser-transfer-Folien, in Schreibwarengeschäften werd ich immer ganz komisch angeschaut wenn ich danach frage,
-
Thread
Bitte Platine für Toner Transfer checken (im Anhang)
die Abstände zwischen den Leiterbahnen zu eng sind u.ä. Ich habe vor, das Board mit dem Toner Transfer Verfahren herzustellen. PS: auf die Pads oben kommen die LEDs wie beim Original, die Pads über dem ATTiny sind für Jumper Pins und die Pads unten sind für die Batteriekabel. Pläne: http://learn.adafruit.com
-
Thread
Domain-Transfer: Nach 48 Stunden weiterhin alte IP-Adresse?
Hallo, ich habe vor über einer Woche erstmalig einen Domain-Transfer von einem amerikanischen Anbieter (.com - Domain) auf einen deutschen Anbieter durchführen lassen. Seit Samstag ist der auch vollzogen (E-Mail erhalten und in der Verwaltungssoftware des neuen Anbieters
Üblicherweise stellt man ein paar Tage vor dem Transfer die TTL etwas herunter. Dann geht das Refresh der DNS-Server-Caches deutlich schneller. Wenn das durch ist, stellt man die TTL wieder hoch.
-
Thread
FT2232H USB 2.0 High Speed
SIWUA kannst Dui verwenden, wenn der FT eine Transfer anstossen will, obwohl sein Puffer voll ist. Aber wenn der PC keine daten anfordert, dann hilft das auch nicht. Das FIFO in meinem Code ist kein externes Ram, sondern ein BRam im Spartan6. Ein
Auf jeden Fall pro USB Transfer requests mit jeweils 128k Grösse aufsetzen damit der Protokoll Overhead bei USB so gering wie möglich ist. Die 128k sind USB spec geschuldet. Christian hat ja auch über die USB Transfergrösse
-
Thread
[Biete] Komplettes Starter-Kit zum Platinen Herstellen
kalten Keller gelagert wurden. Naja, dann kann man die Platinen eben bevorzugt für das Foto-Transfer-Verfahren nutzen
"Naja, dann kann man die Platinen eben bevorzugt für das Foto-Transfer-Verfahren nutzen" Sorry, habe mich verschrieben, meinte natürlich Reichelt-Verfahren (Bügel-Transfer-Verfahren). Da ist der Photolack ja eh überflüssig für...
-
Thread
Windows Programm für Spektrum-Analyzer HP859x
recht erinnere. Einige Analyzer verwenden dies, um dem GPIB-Controller zu signalisieren, dass der Transfer beendet ist (z.B. HP4195), während andere Analyzer das EOI-Signal nie verwenden und stattdessen mit irgend einem Sonderzeichen das Ende der Telegramme markieren (z.B. HP436). Es ist also eigentlich
erinnere. Einige Analyzer verwenden dies, um dem > GPIB-Controller zu signalisieren, dass der Transfer beendet ist (z.B. > HP4195), während andere Analyzer das EOI-Signal nie verwenden und > stattdessen mit irgend einem Sonderzeichen das Ende der Telegramme > markieren (z.B. HP436). das ist in
-
Thread
Frage UDS TesterPresent
darauf hat. Kann es vorkommen, dass vom Tester während dieser conductive-frames schickt (z.B. bei Transfer-Data), zwischendrinn ein Tester-Present als request schickt? Oder muss ein gestarteter Request erst bis zum ende gesendet werden? In der ISO konnte ich so einen fall nirgends finden.
Timer aufzieht, ohne übers ISOTP/UDS laufen zu müssen, weil das ja gerade mit einem segmentierten Transfer beschäftigt sein könnte.
-
Thread
Und wieder Belichtungs-Methode - Entwicklungs-Wettrennen gegen Perma-Nachbelichtung!?
finde das Arbeiten mit der Belichtungsfolie bisher extrem umständlich... dagegen war der Toner-Transfer ja ein Sonntagsspaziergang auf einer Blumenwiese. Wobei vieles von der aufgebauten Arbeits-Routine und dem Aufbau des Arbeitsplatzes abhängt, das ist mir klar. Aber bei mir eben: Katastrophe: Zuerst
ist, denke ich, noch gröber - und anrauen mit Naps ist mir zuweilen zu umständlich. Beim Toner-Transfer hatte ich mit dem Anrauen durch Stahlwolle eigentlich nie Probleme. Ich denke mal auch nicht, dass die jetzigen Probleme damit etwas zu tun haben (?), aber das mit Scheuerpulver & Co., das werde ich
-
Thread
Posix Thread Fehler bei Übergabe mehrerer Parameter?
//state_get_Mess_Data(&Thread_Struct); //state_Flash_Firm(&Thread_Struct); //state_Transfer_Data( Config_PTR); //exit(0); //TESTS OFF //Threads starten //while (pthread_create (&threads[1], NULL, state_SD_mount_umount, NULL) != 0) // printf ("Fehler Thread state_SD_mount_umount
/* if (!(Config_PTR->SD_Only)) { while (pthread_create (&threads[3], NULL, state_Transfer_Data, Config_PTR) != 0) printf ("Fehler Thread state_Transfer_Data!"); while (pthread_create (&threads[4], NULL, state_Flash_Firm, &Thread_Struct) != 0) printf ("Fehler
-
Thread
STM32F4 - SPI TX Interrupt verbieten
brauche also niemals die Receive/Transmit interrupts. Daher habe ich explizit die Interrupts für TXE (Transfer register empty) und RXNE (receive register not empty) abgeschaltet. Ich möchte mit der ISR nämlich nur Fehlerfälle abfangen. Dazu sieht meine ISR momentan so aus: [Code] // called on error conditions
Stream2, DMA_FLAG_TCIF2); // Processing here ... } /* DMA_FLAG_TEIFx: Streamx transfer error flag * DMA_FLAG_DMEIFx: Streamx direct mode error flag * DMA_FLAG_FEIFx: Streamx FIFO error flag */ else if (DMA_GetFlagStatus(DMA2_Stream2, DMA_FLAG_TEIF2)) {
-
Thread
AD9102 und 30MHz Sinus
write_register(uint16_t reg, uint16_t value) { uint16_t answer; digitalWrite(SPICS,LOW); SPI.transfer16(reg); answer = SPI.transfer16(value); digitalWrite(SPICS,HIGH); return answer; } [/c]
write_register(uint16_t reg, uint16_t value) { uint16_t answer; digitalWrite(SPICS,LOW); SPI.transfer16(reg); answer = SPI.transfer16(value); digitalWrite(SPICS,HIGH); return answer; } [/c] Trotzdem bin ich grad noch am grübeln, was ich in meiner Implementierung bis jetzt
-
Thread
ATSAM4S TWI Master
Slave-Chips brauchen das aber. (Meiner :-) Mit einem kleinen Trick kann man jedoch einen Write-Read Transfer machen, wenn man nur bis zu drei Bytes im Write machen muss: Man kann dem TWI bis zu drei Address Bytes geben, die er, bevor der eigentliche Transfer stattfindet, per Write Transfer schreibt. Dabei
-
Thread
usb 2.0 mit control pannel
schicken,wo ich mittels control panel dise hex wert sehe. das heisst ,ich benutze ein endpoint als IN transfer:in diese endpoint fifo schreibe ich diese hex wert. kann mir jemand bitte sagen ob ich direkt dise wert schreiben kann oder muss ich erstmal ein endpoint für out transfer definiere und von dort die
kriege und in port pin zum beispiel pa.0 anschliesse und von dort die daten in ein endpointfifo(IN transfer)zwichenspeichere und weitereschicke zum pc. dass heisst ich brauche kein kopierung von daten von ein endpoint in andere endpoint. MfG
-
Thread
STM32 feature DMAMUX
DMA1_Channel0 using DMAMUX SET_BIT(DMA1_Channel1->CCR, DMA_CCR_EN_Msk); // Start new transfer SET_BIT(SPI1->CR2, SPI_CR2_TXDMAEN_Msk); } [/c] Ist also so ähnlich wie bei Dir und funktioniert.
hast? Da kann es doch eigentlich garnicht funktionieren. Du müsstest schon warten bis der DMA-Transfer fertig ist.
-
Thread
Arduino zu viel Stromaufnahme? Alternative gesucht
abzapfen darfst. Du musst dir schon eine zuverlässige Quelle suchen, zumal ein ESP beim WLAN Transfer (Senden) eine Menge Strom zieht.
schrieb im Beitrag #7286246: > dir schon eine zuverlässige Quelle suchen, zumal ein ESP > beim WLAN Transfer (Senden) eine Menge Strom zieht. und zwar mehr wie 300mA , und das auch noch impulsartig ...
-
Thread
Timing FT2232H
Wieso geht da was verloren? Das darf doch bei BULK Transfer nicht passieren. Wenn du denn Buffer nicht schnell genug leerst, muss der FTDI die TXE# Leitung auf inaktiv setzen, und deine Logik das Schreiben stoppen. So jedenfalls funktioniert das beim FX2.
mir Full und ich hör auf mit Schreiben. Da geht nix verloren. Sowas hätte man höchstens bei ISO-Transfer.
-
Thread
PIC18F2550 USB und RS232
aktiviert ist und eine Übertragung über RS232 erfolgt, welche ja deutlich länger braucht, als ein USB-Transfer, dann bleibt für das Hauptprogramm nicht mehr genug Zeit, um die State-Machine für die USB-Kommunikation zu bedienen. Es käme somit zu einem sofortigen Abbruch und der PIC würde aus der Systemsteuerung
man die USB routine nur für eine gewisse Zeit unterbrechen darf. Für was ist dann der isochrone Transfer gut, welcher Echtzeit unterstützt? Angenommen ich habe ein System, das sagen wir mal 30 Minuten Daten über RS232 an den PIC sendet und von da aus via USB an den Host (PC). Dann geht das nur, wie