Varför kan man inte skicka värden konstant via FTDI?

[Al_Bundy]

Hej!

Jag försöker kommunicera med min ATmega och dator via ett FTDI interface. Det går bra, men efter en tids skickande med strängar så stängs FTDI interfacet ned.

Är detta med någon buffert eller? Dvs att man kan inte skicka hur mycket som helst via FTDI chippet?
Det går till en viss total storlek, sen stopp?

[sodjan]

Man kan få "overflow" i precis vilken kommunikation som helst.
Det är svårt utifrån din beskrivning att säga något mer än så.
Det är på tok för många okända parameterar i din fråga.
Hur ser en "sträng" ut, typiskt?
Hur lång tid är "efter en tid"?
Hur mycket data motsvarar det?
Läses datat kontinuerligt på "andra sidan"?
Hinner "andra sidan" med att läsa datat?
Vad betyder det att FTDI interfacet "stänger ner"?
O.s.v o.s.v...

[Al_Bundy]

Ja! En overflow blir det. Vi skickar strängar så som heltal och decimaltal då min andra grupp inte kan ta emot bytes, utan bara strängar.

Jag skickar värden varje 500 ms.
Det jag skickar är analoga värden från en 10 bit ADC.

Jag skickar bara data och sen får min PC avgöra om att ta emot dessa. Jag matar på.

Jag använder Serial.print(); för att skicka.

[ie]

Räkna på det.

Antal tecken * 10 bits (start, 8 data, stop) * 2 (två meddelanden per sek)

Då får du antal bits per sekund.

Kolla sen att PC/AVR kommunicerar med minst denna hastighet.

[Al_Bundy]

Räkna på det.

Antal tecken * 10 bits (start, 8 data, stop) * 2 (två meddelanden per sek)

Då får du antal bits per sekund.

Kolla sen att PC/AVR kommunicerar med minst denna hastighet.

Vad menar du?
Vi säger att jag skickar 34.56
Då blir det 4×10×8×2?

Jag kör med 9600 baudrate. Kanske är för lite?

[danei]

Du skickar alltså 10byte/s och har en kapasitet på 9600byte/s. Varför tror du då att överföringshastigheten är ett problem?

[Al_Bundy]

Just nu tror jag ingenting.
Jag vet inte vad som är fel.

[sodjan]

> Det går bra, men efter en tids skickande med strängar
> så stängs FTDI interfacet ned.

> Hur lång tid är "efter en tid"? ??? <==
> Vad betyder det att FTDI interfacet "stänger ner"? <==

[Al_Bundy]

Om jag kopplar in min FTDI adapter/interface i usb och ha kommunication mellan uC och PC så kan jag se att uC skickar värden till PC. Men efter ca 2 min så slutar den skicka värden. Även RX dioden slutar blinka.

Interfacet har jag köpt på sparkfun och byggt min egen "arduino" med en ATmega328p.

[Icecap]

USB är i gemen ganska störkänsligt. Jag har upplevd ett antal gångar att jag får jacka ut USB-dongeln för att återställa USB-RS232 funktionen.

Och riktigt illa är det när jag utvecklar och slår på och av strömmen till målsystemet, då kan det hända snabbt.

[sodjan]

> Även RX dioden slutar blinka.

Den sitter väl direkt på FTDI kretsen om jag minns rätt.
Förtsätter din AVR att skicka data?

[Al_Bundy]

Sjäva ATmegan rullar på och gör sitt. Men inga signaler eller samma signal kommer igenom FTDI.

Därför måste man starta om ATmegan för att det ska fungera igen.

Minns att PCn läste hela tiden 848.00 hela tiden.

[eqlazer]

Starta om ATmegan?? Så det är alltså inte FTDI-kretsen/USB som buggar ur?

[sodjan]

> Sjäva ATmegan rullar på och gör sitt.

Betyder det att du fortfarande har trafik på USART utgången på AVR'en?

> Även RX dioden slutar blinka.

Alltså "RXLED#" ? Den blinkar då FTDI tar emot data från USB.
Hur är det med de övriga? TXLED# och SLEEP# t.ex.?

> Därför måste man starta om ATmegan för att det ska fungera igen.

Power off/on? Eller soft-reset?
Inkluderar power off/on i så fall FTDI kretsen?

[Al_Bundy]

USB är i gemen ganska störkänsligt. Jag har upplevd ett antal gångar att jag får jacka ut USB-dongeln för att återställa USB-RS232 funktionen.

Och riktigt illa är det när jag utvecklar och slår på och av strömmen till målsystemet, då kan det hända snabbt.

Amen!

Men jag ska köra med en FTDI kabel istället och se hur härket går!