Nerre skrev:Hur VET du att din burk fortsätter skicka värden? Har du kopplat en lysdiod på TX som blinkar?
På FTDI breakout Board från Sparkfun är det inbyggt TX och RX lysdioder. RX blinkar varje gång jag kör kommandot Serial.println(sträng); i min kod. Men jag kanske kör troligvis för snabbt så den "buggar ihop". Jag kanske måste ha en delay för jag har bara en 100 ms delay + andra operationer programmet gör innan den anropar Serial.println(sträng);
while (Serial.available() == 0)
{
Serial.println(callPHmeter(0)); // prints out callPHmeter(0)
digitalWrite(13, HIGH);
show_values_display(callTemp(), callPHmeter(0), 0); // JUST FOR THE MOMENT!
delay(100);
}
När PC skickar ett värde, vad som helst, så bryts loopen. Annars så skickar uC hela tiden analoga värden som datorn tar upp för analys. Funktionerna callTemp(), callPHmeter(0), bidrar också till en liten delay. Skulle loopen brytas så kommer LED 13 släckas.
LOW kommer direkt efter loopen.
Men LOW kommer aldrig köras då FTDI:n verkar haka upp sig. Det går varken.
Det som händer är att om jag har en loop som spottar ut olika värden hela tiden på skärmen(Serial I/O). Till slut ser du bara samma värde hela tiden, du kan inte skicka värden till uC och RX lampan har slutat blinka. Den blinkar varje gång man skickar ett värde.
Kan det vara så att min kod ovan är för belastande för just FTDI:n? För samtidigt kollar jag om det finns någon data att hämta Serial.available() och raden nedan så skriver jag ut data.
hummel skrev:Använder du någon typ av handskakning i ditt protokoll?
Ja. På mitt FTDI breakout board från SparkFun har jag en handskanking mellan ATmegans RTS och FTDI:ns RTS. Mellan dessa har jag en 0.1 uF kondensator.
Det fungerar. Men när jag använder en kabel...så fungerar det inte. Det är inte bara jag som verkar ha detta problem.
På bilden på kopplingen står det att RTS går till RESET via en konding. Detta är för att kunna starta om ATMegan när man ska gå in i programmeringsläge. Det har ingenting med handskakning att göra när du skickar data. Om du inte använder reset som något annat än reset?
Jag är fortfarande mer övertygad om att det är fel på din kod än fel på FTDI-kretsen, men eftersom du inte verkar klara av att felsöka systematiskt så ger jag upp med att försöka hjälpa till.
hummel skrev:Använder du någon typ av handskakning i ditt protokoll?
Ja. På mitt FTDI breakout board från SparkFun har jag en handskanking mellan ATmegans RTS och FTDI:ns RTS. Mellan dessa har jag en 0.1 uF kondensator.
Det fungerar. Men när jag använder en kabel...så fungerar det inte. Det är inte bara jag som verkar ha detta problem.
På bilden på kopplingen står det att RTS går till RESET via en konding. Detta är för att kunna starta om ATMegan när man ska gå in i programmeringsläge. Det har ingenting med handskakning att göra när du skickar data. Om du inte använder reset som något annat än reset?
Ja. ATmegan startas om då en ledlampa i SCK(dvs pin13) blinkar till lite.
Jag har ingen annan reset. Vad jag vet
Nerre skrev:Jag är fortfarande mer övertygad om att det är fel på din kod än fel på FTDI-kretsen, men eftersom du inte verkar klara av att felsöka systematiskt så ger jag upp med att försöka hjälpa till.
Jag har felsökt nog mycket.
Jag lutar mer mot att jag måste ha lite delays i min kod. Annars buggar den upp.
Jag kan inte se nåt i tråden som indikerar att du har uteslutit att det är sändande sidan det är fel på. Snarare tvärtom. Minnesläcka, missförstånd om hur sakerna fungerar, matningsglitch etc kan vara troliga orsaker.
När jag testar på mitt UNO kort som har ATmega16U2 som "FTDI"-chip så fungerar min kod perfekt. Jag kan loopa koden hur mycket som helst, utan att RX slutar blinka.
Al:
Systematisk felsökning:
1: Få ett överblick över vad som SKA hända.
2: Få ett överblick på vad som INTE händer.
3: Bryt ned komponenter, funktionsblock eller liknande.
4: För varje block: kan det brytas ner ytterligare?
5: Analysera vilka delar som är utanför misstanke.
6: Testa del för del, då kommer felet upp helt enkelt.
Ta en bil som exempel:
Motorn startar inte.
I din logik (som du så ofta har visat här) är det nog för att däcktrycket är fel och detta är vad du kan komma till uteslutande för att du inte analysera något alls. Om din totala brist på analys och logisk tänkande sedan beror på att din hjärna är skruva ihop på det vis eller att du har en brist i uppfattningen av vad verkligheten är kan jag inte sia om.
Du har definitivt ett ytterst lågt kännedom till hur µC fungerar och vad man kan klara med dessa - och det är ju ingen hjälp heller.
Vi andra - som har utbildning inom felsökning - börjar istället att analysera lite:
* Finns det bränsle i tanken?
* Är det rätt bränsle?
* Kör startmotorn?
* Drar startmotorn med runt motorn?
* Är det tändning (vid bensin/sprit)?
* Kommer det bränsle in till motorn?
Osv osv.
Har man ingen logisk fel (12V till tändspolen hade hoppat av t.ex.) får man ta steg för steg och utesluta felfunktion, steg för steg.
* Hmm, förgasaren luktar bensin efter att ha ryckt i startmotorn - så det finns nog bensin fram och det sugs in lite här-var. Hade det varit felet hade den iaf. hostat till lite...
* Jupp, startmotorn drar runt motorn, hörs tydligt.
* Tändningen då? Aj för satan - jo, den fungerar!
* Tändstifterna, hur ser de ut? <skruva, kolla> Aj då, de är för jävliga... Sannolikt fel: kassa tändstifter.
