Har fått kommunikationen att fungera men det blir fel värde när det väl nått PICen.
Skickar värden med RealTerm och det blir helt andra värden än vad jag sänder.
Fick en tanke om att det skulle vara att värdena bara är inverterade men icke.
Skickar in övre raden från en fil och i picen dyker den undre raden upp:
0C 00 00 00 01 00 00 00 01 1E 01
DE FF FF FF FD FF FF FF FD C3 FD
jag sänder med 8 bitar, ingen paritet och 1 stoppbit.
I PIC18F442 har jag ställt in att köra utan den nionde kontrollbiten.
Alla datamängder stämmer dock dessbättre, verkar bara vara datan i sig som blir fel.
Vad kan detta bero på?
Får in fel ascii-värde i PIC18F442 via PCns serieport
Hittade felet när jag skulle beskriva hur jag kopplat.
Tack för hjälpen
Så borde jag väl rimligen förklara vad som hänt, hade tidigare gjort en koppling via en flipflop med en klockfrekvens på 40MHz, klockan genereras av en oscillator som ger fyrkantsvåg ut och det verkade fungera då i alla fall.
Kollade inte vilken data som faktiskt kom fram bara att det kom data och att vågformen var snyggt fyrkantig i oscilloskopet.
Tydligen inte tillräckligt bra upplösning i tid för PICens mottagning.
När jag satte den till en MAX232 så fungerade det lika bra som sändande av data från PIC till PC som fungerat avsevärt mycket bättre.
Medans jag väntade på svar så kopierade jag två dumpar från PICen av PICens minne och några register.
ganska snygg tycker jag så ta gärna en titt.
Om någon vill ha dess kod så ska jag nog kunna plocka ut den och lägga upp men den är nästan helt okommenterad, däremot målande namn på subrutinerna.
Här är de tre dumparna pejstade i en fil.
http://ottd.dyndns.org/1/nano/random%20 ... -09-21.txt
PS.
Det jag skrev om att jag skickade en fil till PICen, det jag gjorde var att jag helt enkelt valde en fil som jag lät RealTerm skicka seriellt till PICen över seriekabeln mellan datorn och picen (med MAX232 emellan).
Inga stora filer, 80 byte och 1500 byte beroende på fil.
Skickar man den stora några gånger så får PiCen fnatt, antar att den börjar skriva i funktionsregistren eftersom jag inte satt något tak på när den ska sluta skriva och skicka ett Xoff tecken, 0x19 om jag inte har fel?
Får se om RT alls accepterar Xoff för det verkar inte finnas någon inställning för det utom ifall RT ska styra överföringen istället för PICen
Tack för hjälpen
Så borde jag väl rimligen förklara vad som hänt, hade tidigare gjort en koppling via en flipflop med en klockfrekvens på 40MHz, klockan genereras av en oscillator som ger fyrkantsvåg ut och det verkade fungera då i alla fall.
Kollade inte vilken data som faktiskt kom fram bara att det kom data och att vågformen var snyggt fyrkantig i oscilloskopet.
Tydligen inte tillräckligt bra upplösning i tid för PICens mottagning.
När jag satte den till en MAX232 så fungerade det lika bra som sändande av data från PIC till PC som fungerat avsevärt mycket bättre.
Medans jag väntade på svar så kopierade jag två dumpar från PICen av PICens minne och några register.
ganska snygg tycker jag så ta gärna en titt.
Om någon vill ha dess kod så ska jag nog kunna plocka ut den och lägga upp men den är nästan helt okommenterad, däremot målande namn på subrutinerna.
Här är de tre dumparna pejstade i en fil.
http://ottd.dyndns.org/1/nano/random%20 ... -09-21.txt
PS.
Det jag skrev om att jag skickade en fil till PICen, det jag gjorde var att jag helt enkelt valde en fil som jag lät RealTerm skicka seriellt till PICen över seriekabeln mellan datorn och picen (med MAX232 emellan).
Inga stora filer, 80 byte och 1500 byte beroende på fil.
Skickar man den stora några gånger så får PiCen fnatt, antar att den börjar skriva i funktionsregistren eftersom jag inte satt något tak på när den ska sluta skriva och skicka ett Xoff tecken, 0x19 om jag inte har fel?
Får se om RT alls accepterar Xoff för det verkar inte finnas någon inställning för det utom ifall RT ska styra överföringen istället för PICen
> Hittade felet när jag skulle beskriva hur jag kopplat.
Och om du hade beskrivit hur du kopplat i första inlägget så
hade du aldrig behövt göra det inlägget alls.
Du får nog ta och fundera på vad du hafsar ihop i fortsättningen.
Jag fattar inte ett smack av vad du svamlar om.
Vad har flipflop'en med kommunikationen att göra ?
När du "satte den till en MAX232" ? Var ditt första inlägg utan den ???
Och vad är "den" förresten ? PIC'en ?
Vad har dumparna med kommunikationsproblemen att göra ?
> Skickar man den stora några gånger så får PiCen fnatt,
Nej, det är din kod som är inte tar hand om det på rätt sätt.
Och om du hade beskrivit hur du kopplat i första inlägget så
hade du aldrig behövt göra det inlägget alls.
Du får nog ta och fundera på vad du hafsar ihop i fortsättningen.
Jag fattar inte ett smack av vad du svamlar om.
Vad har flipflop'en med kommunikationen att göra ?
När du "satte den till en MAX232" ? Var ditt första inlägg utan den ???
Och vad är "den" förresten ? PIC'en ?
Vad har dumparna med kommunikationsproblemen att göra ?
> Skickar man den stora några gånger så får PiCen fnatt,
Nej, det är din kod som är inte tar hand om det på rätt sätt.
>Och om du hade beskrivit hur du kopplat i första inlägget så
>hade du aldrig behövt göra det inlägget alls.
Det är ju sant, såg inget som tydde på att det skulle ha med elektroniken att göra trots att så var fallet.
En erfarenhet mer i bagaget.
>Vad har flipflop'en med kommunikationen att göra ?
Ingenting normalt sett, men jag hade kopplat via den för att vara säker på att inte förstöra PICen av misstag när jag inte visste vilka spänningar som skulle dyka upp och sedan blev det kvar "tills vidare" för att det verkade fungera.
>När du "satte den till en MAX232" ? Var ditt första inlägg utan den ???
Utgående data gick via MAX232 ingående data gick via en flipflop oturligt nog.
>Och vad är "den" förresten ? PIC'en ?
Ja
>Vad har dumparna med kommunikationsproblemen att göra ?
När jag gjorde dem så visade de vilka data som fanns i picen.
Och den kunde ev vara bra för någon mer, jag fann den mycket andvändbar för att se vilka fel man gjort.
>> Skickar man den stora några gånger så får PiCen fnatt,
>Nej, det är din kod som är inte tar hand om det på rätt sätt.
Ja, och då får den fnatt, den ska när programmet är klart säga stopp till RealTerm när 255 byte har tagits emot men jag har inte kommit så långt ännu.
>hade du aldrig behövt göra det inlägget alls.
Det är ju sant, såg inget som tydde på att det skulle ha med elektroniken att göra trots att så var fallet.
En erfarenhet mer i bagaget.
>Vad har flipflop'en med kommunikationen att göra ?
Ingenting normalt sett, men jag hade kopplat via den för att vara säker på att inte förstöra PICen av misstag när jag inte visste vilka spänningar som skulle dyka upp och sedan blev det kvar "tills vidare" för att det verkade fungera.
>När du "satte den till en MAX232" ? Var ditt första inlägg utan den ???
Utgående data gick via MAX232 ingående data gick via en flipflop oturligt nog.
>Och vad är "den" förresten ? PIC'en ?
Ja
>Vad har dumparna med kommunikationsproblemen att göra ?
När jag gjorde dem så visade de vilka data som fanns i picen.
Och den kunde ev vara bra för någon mer, jag fann den mycket andvändbar för att se vilka fel man gjort.
>> Skickar man den stora några gånger så får PiCen fnatt,
>Nej, det är din kod som är inte tar hand om det på rätt sätt.
Ja, och då får den fnatt, den ska när programmet är klart säga stopp till RealTerm när 255 byte har tagits emot men jag har inte kommit så långt ännu.
OK.
Jag antar att du inte kan påverka sändingen på något annat sätt !?
Bättre hade ju varit att sända datat i mindre "paket" som PIC'en
ACK'ar när den är klar att ta imot ett nytt paket.
Även om datat ligger i filer, så kan man ju skriva ett enkelt
program i VB eller liknande som tar hand om det.
Sen så trodde jag att Xon/Xoff sattes direkt på COM porten :
Jag antar att du inte kan påverka sändingen på något annat sätt !?
Bättre hade ju varit att sända datat i mindre "paket" som PIC'en
ACK'ar när den är klar att ta imot ett nytt paket.
Även om datat ligger i filer, så kan man ju skriva ett enkelt
program i VB eller liknande som tar hand om det.
Sen så trodde jag att Xon/Xoff sattes direkt på COM porten :
Kod: Markera allt
C:\>help mode
Konfigurerar systemenheter.
Seriell port: MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
[to=on|off] [xon=on|off] [odsr=on|off]
[octs=on|off] [dtr=on|off|hs]
[rts=on|off|hs|tg] [idsr=on|off]
