Svenska ElektronikForumet

Felsöka är jag duktig på, men inte när det gäller dessa komponenter jag jobbar med. Då har jag bristande kunskap.

Det jag vill är att skicka värdet 1023 just PC:n från uC via FTDI:n men någonstans tar det stopp. Det tar stopp i FTDI:n och endast samma värde skrivs från FTDI:n till PC:n.

När uC skriver till FTDI:n så blinkar RX lysdioden till och PC:n kan inte skicka något värde till uC via FTDI:n. Att reseta uC hjälper inte heller för FTDI:n måste också få en egen "reset".

Som jag ser det som är att koden fungerar OK då koden fungerar med ATmega16U2 felfritt.
Så jag utesluter att den blir någon krock.

Jag har även testat skriva ut "hello Word" via ett enkelt exempel och loopa det snabbt, samt sakta.
Resultatet när jag loopade "hello World" snabbt var att jag fick bara ¤#¤%¤#%& upp på skärmen, men när jag lade in en delay() i loopen så gick det saktigare och då kunde jag se "hello World" på skärmen.

Min slutsats är att mitt program skriver för snabbt till FTDI:n så det krockar.

Nu pratar jag om FTDI breakout board från SparkFun och inte FTDI kabeln.

Exakt HUR vill du skriva värdet 1023?
* Som text?
* eller Binärt värde?

Om du gör det som binärt värde kan du ju fundera på hur du ska kunde skriva 1023 med en byte som kan vara 255 som mest...

Grejen i ditt fall är att du använder alla dessa färdiga funktioner (t.ex. SerialPrintxxx()) och du har precis noll koll på exakt hur de fungerar och om de fungerar.

Jag kan lova dig att chansen för att du kan köra en data overrun på FTDI-kabeln är så nära noll som du kan tänka dig!

När seriell kommunikation bli goja och man inte har ändrat baudrate brukar det vara för att det blir osynkroniserat med start- och stopbit. Detta kan ibland lösas med att använda 2 stopbit på sändaren.

Jag skriver värdet 1023 som en sträng då PC:n (på labbet) inte kan ta emot annat än en sträng. Det är inte jag som programmerar PC, det gör någon annan.

Det kan vara så att jag kan behöva ändra baudrate från 9600 till annat. Vad menar du med "2 stopbit på sändaren."?

Hur vet du att din atmega verkligen skickar ut något på uarten?

Hej!

Att felsöka handlar om att backa tillbaka, även om det verkar ologiskt och testa i små små steg i taget, men det gör du nästan. Men att förutsätta att saker fungerar är farligt...

På din icke-fungerande uppkoppling. kör följande kod:


LOOPA:
{
Skicka "hej" på serieporten.
Vänta typ 400millisekunder
}

Fungerar det hela tiden? tar pc:en emot "hej" hela tiden?

Om RX-dioden på FTDI-kabeln/adaptern inte blinkar så betyder det i min värld att din AVR inte längre skickar data till
pc:en, även om du tror det. Det är nog därför vi misstänker att problemet finns på AVR-sidan.

MVH: Mikael

Vi både analyserar det med LabView och Arduinos inbygda monitor.
Jag har också kopplat in en display på ATmegan som visar ett värde.

När displayen visar t.ex 834 och LabView visar t.ex 900 hela tiden och RX lysdioden har slocknat och om vi skickar något till uC från LabView via FTDI:n så händer det inget. Då måste det ha varit något fel någonstans.

Jag har tillgång till en AVR ISP MKII programmerare men jag har oftast bara kört programmering med bootloader då jag har ett fåtal USB portar på min dator som är redan upptagna.

DU har fortfarande inte talat om eller förklarat om din AVR verkligen skickar något.
Varken LabView eller interna program kan tala om huruvida du verkligen skickar något.
För att ta reda på det, behöver du skapa en loopande kod som kontinuerligt skickar bestämda data, och titta på det i ett oscilloskop.
Hur har du konfigurerat AVRens UART?

adent skrev:Hej!

Att felsöka handlar om att backa tillbaka, även om det verkar ologiskt och testa i små små steg i taget, men det gör du nästan. Men att förutsätta att saker fungerar är farligt...

På din icke-fungerande uppkoppling. kör följande kod:


LOOPA:
{
Skicka "hej" på serieporten.
Vänta typ 400millisekunder
}

Fungerar det hela tiden? tar pc:en emot "hej" hela tiden?

Om RX-dioden på FTDI-kabeln/adaptern inte blinkar så betyder det i min värld att din AVR inte längre skickar data till
pc:en, även om du tror det. Det är nog därför vi misstänker att problemet finns på AVR-sidan.

MVH: Mikael

Det kan vara troligt faktiskt!

Kan det ha blivit minnesläcka när jag brände över programmet via FTDI:n? Jag kanske ska använda mig av programmeraren istället då jag redan har den tillgänglig.

Men det lustiga är att AVR:n fortfarande fungerar som den ska om om jag resetar den så är fortfarande FTDI:n fryst. Men FTDI:n är det samma oavsett om jag resetar ATmegan eller inte.

Så något från ATmegan måste orsaka att FTDI:n beter sig som den gör. Det är helt klart.
Om själva Serial.available() och Serial.println() kan orsaka att FTDI:n blir konstig?

Al: dagens tips. Montera en LED med lämplig strömbegränsarmotstånd mellan VDD och AVR Tx. Då blinkar den till när AVR'n sänder något.

Ännu bättre ville ju vara ett oscilloskop.

> På FTDI breakout Board från Sparkfun är det inbyggt TX och RX lysdioder.

Ja, men notera att dessa indikerar om/att det går trafik på *USB* sidan.
Inte om/att det går trafik på USART sidan. Det flera inkl mig har frågat
efter är om det är verifierat om det faktiskt går trafik USART sidan...

Men som flera också säger så är lite svårt att hänga med i de
lite osammanhängande turerna. Tydliga scheman och/eller bilder
över det hela skulle också sannolikt hjälpa till.

Det är som vanligt, den som frågar och sitter med prylarna
framför sig på bordet tycker att allt är solklart, medan vi som
inte vet mycket om det hela enbart tycker att det är rörigt...

Al_Bundy skrev:Felsöka är jag duktig på, men inte när det gäller dessa komponenter jag jobbar med. Då har jag bristande kunskap.

Man kan fortfarande ägna sig åt systematisk felsökning, vilket du inte gör.

Minnesläckor uppstår inte när man "bränner" kod, utan på dåligt skrivna program.
Att Din AVR funkar är säkert inte så konstigt, du kanske har missat något i setupen för din serieport och USB'n.

TomasL skrev:DU har fortfarande inte talat om eller förklarat om din AVR verkligen skickar något.
Varken LabView eller interna program kan tala om huruvida du verkligen skickar något.
För att ta reda på det, behöver du skapa en loopande kod som kontinuerligt skickar bestämda data, och titta på det i ett oscilloskop.
Hur har du konfigurerat AVRens UART?

Min AVR skickar kod och det står i min kod på föregående sida.
Jag har inte konfiguerat AVR:ens UART. Jag bara kopplade dit den och sedan dess har den fungerat under en kort tid.

Jag gör så här. Jag postar min kod så ni får ta del av mer information

Icecap skrev:Al: dagens tips. Montera en LED med lämplig strömbegränsarmotstånd mellan VDD och AVR Tx. Då blinkar den till när AVR'n sänder något.

Ännu bättre ville ju vara ett oscilloskop.

VDD? Menar du VCC?
strömbegränsarmotstånd? Menar du någon typ av LED diod?

sodjan skrev:> På FTDI breakout Board från Sparkfun är det inbyggt TX och RX lysdioder.

Ja, men notera att dessa indikerar om/att det går trafik på *USB* sidan.
Inte om/att det går trafik på USART sidan. Det flera inkl mig har frågat
efter är om det är verifierat om det faktiskt går trafik USART sidan...

Men som flera också säger så är lite svårt att hänga med i de
lite osammanhängande turerna. Tydliga scheman och/eller bilder
över det hela skulle också sannolikt hjälpa till.

Det är som vanligt, den som frågar och sitter med prylarna
framför sig på bordet tycker att allt är solklart, medan vi som
inte vet mycket om det hela enbart tycker att det är rörigt...

Men hur skulle jag veta att RX var "USB sidan"?

Al_Bundy skrev:

Icecap skrev:Al: dagens tips. Montera en LED med lämplig strömbegränsarmotstånd mellan VDD och AVR Tx. Då blinkar den till när AVR'n sänder något.

Ännu bättre ville ju vara ett oscilloskop.

VDD? Menar du VCC?
strömbegränsarmotstånd? Menar du någon typ av LED diod?

VDD och VCC är samma i detta fall, alltså den positiva sidan.

strömbegränsarmotstånd är det motsånd man använder tillsammans med LED för att de inte ska brinna upp.
Det finns LED med inbyggt motstånd men det är inget som har med detta att göra.