-
Thread
dsPIC "intelligenter" DMA?
wird die CPU dafür für einige Takte angehalten, mal ist abwechselnd CPU u DMA aktiv, mal geht der Transfer 'spurlos' (ggfs über DPRAM) an der CPU vorbei. Je leistungsfähiger der Transfer desto aufwändiger und teurer der uC. WAS das für Daten sind, ist dem DMA-Controller egal.
-
Thread
Atollic TrueSTUDIO STM32F4 mit C++ undefined reference to `main' und co.
undefined reference to `main' in startup_stm32f4xx.s undefined reference to `EVAL_AUDIO_TransferComplete_CallBack' in stm32f4_discovery_audio_codec.c undefined reference to `EVAL_AUDIO_GetSampleCallBack' in stm32f4_discovery_audio_codec.c ich habe bis jetzt keine Lösung finden. Vielleicht
nicht. Denis SagIchNicht schrieb im Beitrag #2556554: > undefined reference to `EVAL_AUDIO_TransferComplete_CallBack' in > stm32f4_discovery_audio_codec.c Es sieht danach aus, als hättest du das entsprechende *.c file nicht als linked resource drin. Schau im Projekt, ob unter 'StdPeriph_Driver
-
Thread
Tiefpass mit Simululink
Laplace-Transformierte von die Funktion lautet: H(s)= 1 / (1 + s*RC) In Matlab gibt es einen Block "Transfer function". Ich weis, das man diesen dazu verwenden muss. Allerdings kommt bei mir dann eine Funktion mit der Form eines Hochpasses raus, wenn ich am Eingang einen Signalgenerator mit Kontant gleich
step(H) %Sprung mit 1 aufs System Falls es dann passt(oder auch schon vorher) kannste ein Transfer Block in Simulink nehmen. Musst die Koeffizienten des Ploynoms von s eintragen, angefangen mit der höchsten Potenz hier s bei zweiter Ordnung s^2 und darfst auch keins auslassen. Also beim Integrator
-
Thread
SAMC20 ASF DmaDescriptor
with DMA - SAM C21 Xplained Pro" angeguckt. In diesem Beispiel wird folgendes gemacht: [c] // [transfer_descriptor] COMPILER_ALIGNED(16) DmacDescriptor example_descriptor SECTION_DMAC_DESCRIPTOR; // [transfer_descriptor] [/c] Kann mir bitte jemand erklären, was da gemacht wird? Vielen Dank!
-
Thread
Ist der ATtiny85 "abwärtskompatibel"?
5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Endpoint
5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10
-
Thread
Gute Pufferlösung zwischen ISR und Mainloop
die Übertragung eines *einzigen* Bytes über den UART! Also mal rechnen: Bei 9600 Baud dauert der Transfer eines Bytes 1/960 s = 1.041666 ms. Das sind bei 8 MHz Taktfrequenz 11333 Zyklen, in denen ein AVR ca. 7000 Instruktionen abarbeiten kann. Right? Wenn nun die Aufbereitungsroutine für die Displaydaten
Übertragung eines > *einzigen* Bytes über den UART! Also mal rechnen: Bei 9600 Baud dauert > der Transfer eines Bytes 1/960 s = 1.041666 ms. Das sind bei 8 MHz > Taktfrequenz 11333 Zyklen, in denen ein AVR ca. 7000 Instruktionen > abarbeiten kann. Right? Wenn nun die Aufbereitungsroutine für die
-
Thread
Bit "SIOINH" Serial Bus Interface (SIO-Mode)
Cortex M3-Toshiba TMPM330FDFG und bin über das o.g. Bit "gestolpert" Im Datenblatt steht nur "0: Transfer Continue" und "1: Transfer forced termination". Kann mir jemand dem Sinn des Transfer-Modus "Zwangsende" erklären? Danke :) T.Müller
-
Thread
Leiterplatten für HF-Anwendungen
Alternativ ginge vielleicht die Toner-Transfer-Methode ;)
Köhler schrieb im Beitrag #2565481: > ;) Genau, HF-Platinenmaterial, z.B. PTFE, und dann Toner-Transfer-Methode... ..iss klar :-)
-
Thread
Problem mit LPT unter WinNT,Win200, WinXP
Standard Mode, it will behave just like a Standard Parallel Port (SPP) with no bi-directional data transfer. If you require bi-directional transfer, then set the mode to Byte Mode. The Parallel Port FIFO mode and ECP FIFO mode both use hardware to generate the necessary handshaking signals. The only difference
-
Thread
generierten Code in STM32CubeIDE modularisieren
cpu-zeit-sparen-mit-direct-memory-access Das macht es schon etwas verständlicher: - Beim ersten Erscheinen von UART_DMA_TransferComplete handelt es sich um einen Prototyp? - Beim zweiten Erscheinen wird der Callback registriert? - Beim dritten Erscheinen wird der Callback (die Funktion) definiert?
cpu-zeit-sparen-mit-direct-memory-access > Das macht es schon etwas verständlicher: > - Beim ersten Erscheinen von UART_DMA_TransferComplete handelt es sich > um einen Prototyp? > - Beim zweiten Erscheinen wird der Callback registriert? > - Beim dritten Erscheinen wird der Callback (die Funktion) definiert? Hm, bin gerade
-
Thread
ILI9341 SPI Pixel auslesen geht teilweise. ID4 auslesen nicht
bcm2835_aux_spi_setCS(2); char rxBuf[4] = { 0x00, 0x00, 0x00, 0x00 }; bcm2835_aux_spi_transfern(rxBuf, sizeof(rxBuf)); bcm2835_gpio_write(RPI_BPLUS_GPIO_J8_36, HIGH); //CS High to end transmission bcm2835_gpio_fsel(RPI_BPLUS_GPIO_J8_36, BCM2835_GPIO_FSEL_ALT4
diesem Punkt hast du SPI nicht verstanden. Ein SPI Schreiben ist auch immer ein Lesen. Es ist ein Transfer in beide Richtungen. Erst der Kontext bestimmt ob im Lese- oder im Schreib-Register etwas sinnvolles drinsteht. Beispiel: wenn du 0xE0 kommandierst bekommst du im Lese-Register auch etwas zurück
-
Thread
Kryptografie: Anonyme Accounts möglich?
das Oscar Deinen Key hätte, wenn er nicht vorher schon gehashed worden wäre. Ich hatte nur den Transfer gemeint, nicht das Storage auf dem Server. Da beissen Dich natürlich noch ganz andere Hunde ;-) Grüße Andreas
der Hash (Challenge-token, hash-key) gesendet. Diesen Hash kann Oscar aber nach dem originalen Transfer nicht mehr gebrauchen, weil das Challenge-token jedes mal neu erzeugt wird. Aber DU wirst jetzt sicher argumentieren, dass Oscar ja das Challenge-Token auch gesehen hat, also aus dem Hash ja theoretisch
-
Thread
SPI für verteilte Systeme
I2C disablen, dann kriegt der Master ein NACK auf die Adresse. Der Master weiß also immer, ob ein Transfer geklappt hat. Ganz im Gegensatz zum SPI. Felix schrieb im Beitrag #6570662: > Der Master würde also nicht sofort die > Antwort erwarten, sondern erstmal eine Reihe von Nullen akzeptieren.
Mumpitz, wenn der Slave nicht schnell genug ist. Der Slave kriegt ein Kollisionsbit, wenn er erst im Transfer das Sendebyte schreibt. Nur kann sich der Master dafür nichts kaufen. Er muß durch höhere Protokolle den Mumpitz erkennen, alles nochmal anfordern und hoffen, daß es diesmal klappt.
-
Thread
Zwischen ADW und PC MC mit SPI nötig?
eine Messkette zum Messen von UV-Strahlen aufbauen. Ich bin jetzt an dem Punkt angekommen, der den Transfer des Binärcodes aus dem AD-Wandler in den PC betrifft. Ich habe die Vermutung, dass ich dazu einen Mikrocontroller mit einer SPI benötige als Schnittstelle zwischen ADW und PC. Ist das richtig?
@ Claude Juncker (berus) >jetzt an dem Punkt angekommen, der den Transfer des Binärcodes aus dem >AD-Wandler in den PC betrifft. Hmmm. >Ich habe die Vermutung, dass ich dazu einen Mikrocontroller mit einer >SPI benötige als Schnittstelle zwischen ADW und PC. Ist
-
Thread
DMA funktioniert nur einmal
nicht, wie du den ADC wieder startest. Ich konfiguriere bei mir den DMA, dann den ADC. DMA mit transfer complete interrupt. Wenn der auslöst, dann lösche ich das DMA und CONT-bit beim ADC. Bei einem Neustart muss ich dann DMA, CONT und SWSTART-bit setzen. Wie das mit der HAL geht kann ich aber nicht
du den ADC wieder > startest. > > Ich konfiguriere bei mir den DMA, dann den ADC. DMA mit transfer > complete interrupt. Wenn der auslöst, dann lösche ich das DMA und > CONT-bit beim ADC. > > Bei einem Neustart muss ich dann DMA, CONT und SWSTART-bit setzen. Wie > das mit der HAL geht kann
-
Thread
LIS331H (Beschleunigungssensor) über SPI/SSI mit TI-Stellaris auslesen?
GPIO_PIN_6,0); /* Contrl_Reg 1 auswählen */ SSIDataPut(SSI0_BASE,0x20); /* Warten bis Transfer beendet*/ while(SSIBusy(SSI0_BASE)); /* In Control Register 1 0xC4 schreiben zum Aktivieren des Sensors und zum Aktivieren der Z-Achse */ SSIDataPut(SSI0_BASE,0xC4); /* Warten bis Transfer
-
Thread
I2C Problem LPC1768
not yet set. This occurs between other states and when the I2C block is not involved in a serial transfer. 0xF8 No relevant state information available; SI = 0. No I2DAT action No I2CON action Wait or proceed current transfer. Im ersten Teil steht ja das SI nicht gesetzt ist. Das muss aber
-
Thread
RFM12 und AVR: Wie nach Fehlern suchen?
port_init_hw_spi(void); #define myrfm12_spi_init myrfm12_port_init_hw_spi /* HW SPI specific transfer function */ uint16_t myrfm12_trans(uint16_t wert) { #if(MYRFM12_CONF_DEBUG == MYRFM12_CONF_DEBUG_YES) myrfm12_debug(cmd); #endif CONVERTW val; val.w=wert; cbi(MYRFM12_CONF_PORT,
port_init_sw_spi(void); #define myrfm12_spi_init myrfm12_port_init_sw_spi /* SW SPI specific transfer function */ uint16_t myrfm12_trans(uint16_t cmd) { #if(MYRFM12_CONF_DEBUG == MYRFM12_CONF_DEBUG_YES) myrfm12_debug(cmd); #endif unsigned char i; cbi(MYRFM12_CONF_PORT, MYRFM12_CONF_CS
-
Thread
STM32F103 DMA ADC und SPI gleichzeitig Fehler
viele DMA Transfers für den SPI Bus generiere geht das ca. 1 bis 3 Stunden gut. Dann wird der DMA Transfer Complete Interrupt nicht ausgelöst. Das Transfer Completet Interrupt Flag ist zu diesem Zeitpunkt auch nicht gesetzt. Benutzt werden DMA1_Channel1 -> ADC DMA1_Channel2 -> SPI RX DMA1_Channel3
DMA_Cmd(DMA1_Channel2, DISABLE); DMA_Cmd(DMA1_Channel3, DISABLE); [/c] und starte dann einen neuen Transfer läuft alles erst mal ein paar Stunden normal weiter, bis irgendwann der Transfer complete Interrupt erneut nicht ausgeführt wird. Wenn ich nun den ADC inklusive ADC DMA nicht starte läuft alles
-
Thread
EAR Gesetz in Kraft - was bedeutet das in der Praxis ?
Problem sind, dann kannst du dich doch registrieren. Oder verstehe ich etwas falsch hier? Knowhow Transfer? Eine Fertigungsfirma ist nicht an Knowhow Transfer interessiert. Ich sehe eher ein Problem bei der Fertigung durch Dritte. Bei vielen Mini-Firmen haperts mit der Dokumentation. Ich sollte wirklich
@Peter, ich spreche von Gewinn/Stück. Die Absatzmenge ist allerdings eher gering. "Knowhow Transfer? Eine Fertigungsfirma ist nicht an Knowhow Transfer interessiert" Da habe ich mich missverständlich ausgedrückt. Sorry! Ich meinte damit, dass die Fertigung an sich sehr individuell ist (zumindest
-
Thread
Vcc im Datenblatt - 2.0, 4.5, 6.0V - warum
Frage zu Datenblättern an Beispiel 74HC14 (Link): Warum werden als Referenz Vcc (z.B. Abschnitt Transfer Characteristics) so merkwürdige Spannungen wie 2.0, 4.5, 6.0V verwendet und nicht übliche 3.3, 5.0V?
Daniel D. schrieb im Beitrag #7573567: > Warum werden als Referenz Vcc (z.B. Abschnitt Transfer Characteristics) > so merkwürdige Spannungen wie 2.0, 4.5, 6.0V verwendet Untere und obere Grenze der Recommended operating conditions, 4.5V entspricht der unteren Grenze des 74HCT14 und wurde
-
Thread
I-Phone mit Win 7 per Bluetooth wie verbinden
ich hab auf meinem iPhone WiFi PhootoTransfer (kostenlos.. son gelbes icon) da der appstore bei mir grade spinnt.. chip link: https://www.chip.de/downloads/WiFi-Photo-Transfer-iPhone-_-iPad-App_52609229.html Das Ding.. ich find's super
-
Thread
STM32: effizienter UART-Empfang mit DMA-Ringpuffer
Semaphoren mit Interrupts freigeben, wenn neue Daten empfangen werden. Dafür nutze ich momentan "transfer complete", "transfer half complete" des DMA-Streams und "idle" des UARTs. Das heißt, immer wenn der Ringpuffer halb voll bzw voll ist oder der UART keine neuen Daten mehr empfängt, wird der Semaphor
-
Thread
USB an STM32F7 wird nicht erkannt
USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009) IRP information: 0x01, Direction: PDO -> FDO URB bus id: 2 Device address: 2 Endpoint: 0x81, Direction: IN URB transfer type: URB_INTERRUPT (0x01) Packet Data
-
Thread
StringToUpper
ein so genannter "Hacker". Oder Leute die Binärdaten verarbeiten zur Speicherung in Dateien oder Transfer über Netzwerk.
Ist doch gut! ;-) > Oder Leute die > Binärdaten verarbeiten zur Speicherung in Dateien oder Transfer über > Netzwerk. Dann sind das aber keine Strings mehr. Was nützt mir eine Funktion, die von allen Zahlen in einen Array(!!) 32 abziehen kann?
-
Thread
Kuriose effekte beim beschreiben von EEprom 24C512
********************************************** Issues a start condition and sends address and transfer direction. If device is busy, use ack polling to wait until device is ready Input: address and transfer direction of I2C device **********************************************************
-
Thread
Neuer gcc compiler für ARM und Optimierungen
läuft und im Fehlerfall einfach zu debuggen wäre. Eigentlich ganz simpel: [code] void DMA11_transfer_abwarten(void) { while(DMA->CH11_CTRL_TRIG & DMA_CH11_CTRL_TRIG_BUSY_Msk); } [/code] aber es wird nicht beachtet. Erst eine zusätzliche Warteschleife wirkt als notwendige Bremse. Insofern
Mi N. schrieb im Beitrag #7561663: > void DMA11_transfer_abwarten(void) > { > while(DMA->CH11_CTRL_TRIG & DMA_CH11_CTRL_TRIG_BUSY_Msk); > } > aber es wird nicht beachtet. Erst eine zusätzliche Warteschleife wirkt > als notwendige Bremse. Das optimiert
-
Thread
LPC17xx I2C und SPI Interrupts
Bytes in der Interruptroutine von SPI dem SPDR überbracht werden) und "gleichzeitig" einen I2C Transfer anstoße um etwas aus dem Eeprom zu lesen, bekomme ich beim I2C teilweise 0xFF statt der richtigen DAten angezeigt. Wenn ich den I2C Transfer erst starte, sobald der SPI Transfer abgeschlossen ist,
-
Thread
STM32F4 debugging mit Eclipse unter Linux
run_flash_loader(0x8000000) failed! == -1 Und danach unendlich viele: [!] send_recv libusb_submit_transfer(-6) Wer kann mir weiterhelfen? Bis jetzt habe ich immer mit ein paar LEDs mein debugging machen können, aber bei größeren Sachen wäre ein funktionierender debugger sicher von Vorteil, oder?
irgendwie funktioniert nichts davon. >Und danach unendlich viele: >[!] send_recv >libusb_submit_transfer(-6) hast Du auch mal einen anderen USB Port benutzt? Und startest OpenOCD oder das ST-Link Util mit Root-Rechten (sudo)? (geht auch ohne, das kannst Du aber fixen, wenn's mit sudo funkt)
-
Thread
Konfigurationsdaten wie speichern?
mit ein paar Hilfsfunktionen zu lösen sind. Du scheinst noch nicht begriffen zu haben, dass ein Transfer-Protokoll nicht das geringste darüber aussagt, wie du die Dinge speicherst, bzw. wie man dann im Programm (oder als Benutzer) auf die Werte zugreift. Leg dir deine Datenstrukturen so zurecht, dass
du diese Zugriffe einfach machen und möglichst so, dass man keine oder kaum Fehler machen kann. Transfer sind aber genau 2 Funktionen: senden und empfangen. Wenn man dort ein wenig Aufwand treiben muss, dann macht man diesen Aufwand nur einmal und nur an genau diesen beiden Stellen.
-
Thread
ILI9341 - nicht mehr verfügbar? Alternatives Display?
1007.13338.71800.000000000000000&pvid=f4fc09c4-426d-472b-81d8-e4bb8c985214&tpp=1 Display für 6 USD mit TransferPCB, Display und MMC Karte? rgds
1007.13338.71800.000000000000000&pvid=f4fc09c4-426d-472b-81d8-e4bb8c985214&tpp=1 > > Display für 6 USD mit TransferPCB, Display und MMC Karte? Das von Dir verlinkte Angebot ist aber ohne den Touch-IC XPT2046, ausserdem kommen noch Versandkosten drauf. Der Threadstarter hat schon Recht: Diese Displays (rotes
-
Thread
STM32 DMA aktivieren in USART-Interrupt -> Byte doppelt
Im DMA-Interrupt setze ich das Transfer-Complete-Flag zurück und deaktiviere den DMA: [code] // DMA interrupt handler void DMA1_Channel5_IRQHandler(void) { // DMA transfer complete if (DMA_GetITStatus(DMA1_IT_TC5)) { // Clear
-
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 :-)