Problem med seriell kommunikation
Problem med seriell kommunikation
God eftermiddag
Sitter idag och försöker mig på lite reverse engineering. Jag har två enheter som komunicerar seriellt mellan varandra enbart rx/tx i ttl nivåer. Har kopplat in PCn med realterm (via en max232 såklar) för att spana på datat som skickas mellan enheterna. Har provat diverse hastigheter och antal stopbitar osv. Men blir inte klok på vilka inställningar som är rätt. Är rädd för att tillverkaren valt någon udda hastighet.
Finns det något bra sätt att klura ut detta? Osciloskop och mäta tiderna?
Terminalprogram med autofunktion?
Sitter idag och försöker mig på lite reverse engineering. Jag har två enheter som komunicerar seriellt mellan varandra enbart rx/tx i ttl nivåer. Har kopplat in PCn med realterm (via en max232 såklar) för att spana på datat som skickas mellan enheterna. Har provat diverse hastigheter och antal stopbitar osv. Men blir inte klok på vilka inställningar som är rätt. Är rädd för att tillverkaren valt någon udda hastighet.
Finns det något bra sätt att klura ut detta? Osciloskop och mäta tiderna?
Terminalprogram med autofunktion?
Troligen inte för pin2 då det oftast sitter en hårdvaruuart imellan.
Däremot kan man läsa av kontrollpinnarna, frågan är om ditt OS är tillräckligt snabbt för att få med alla omslag.
Tja, wikipedias uppslag UART ger väll en bild. (engelska versionen)
Annars är det bara att ansluta skopet och titta hur lång kortaste pulsen är, det är sannolikt en bit, tittar man sen efter regelbundenheter i pulserna kan man snart se hur långt ett tecken är. Då har man ju hastigheten och är det då vanlig asyncron kommunikation så borde realterm kunna pressentera datan.
8N1 är en mycket vanlig inställning för serielt, även för inbyggda system.
Däremot kan man läsa av kontrollpinnarna, frågan är om ditt OS är tillräckligt snabbt för att få med alla omslag.
Tja, wikipedias uppslag UART ger väll en bild. (engelska versionen)
Annars är det bara att ansluta skopet och titta hur lång kortaste pulsen är, det är sannolikt en bit, tittar man sen efter regelbundenheter i pulserna kan man snart se hur långt ett tecken är. Då har man ju hastigheten och är det då vanlig asyncron kommunikation så borde realterm kunna pressentera datan.
8N1 är en mycket vanlig inställning för serielt, även för inbyggda system.
Jodå jag ser en hel data, och det känns som jag är ganska nära, men ändå inte. För att tända upp ett visst segment på displayen så skickas exvis "00 b2" och för att släcka "00 b3". Men i vissa fall skickas samma data både för att tända och släcka, vilket jag tror är fel.
Varför jag är ganska säker på att det är fel är att om man kopplar lös displayen så skickas fortfarande data i blindo. Kopplar man sedan in den i drift så blir allt rätt i alla fall. Därför är jag ganska säker att displayen inte arbetar med togglande uppdatering (samma kommando för att tända/släcka).
Varför jag är ganska säker på att det är fel är att om man kopplar lös displayen så skickas fortfarande data i blindo. Kopplar man sedan in den i drift så blir allt rätt i alla fall. Därför är jag ganska säker att displayen inte arbetar med togglande uppdatering (samma kommando för att tända/släcka).
> Jodå jag ser en hel data....
OK. Det var ju en jäkla skillnad, varför sa du inte det direkt ?
Om du faktiskt ser data som ser OK ut så kanske du ligger rätt
i *hastighet* i alla fall. Sen kanske 7/8 bit eller par/nopar kan spöka...
Jag skulle koppla tvärtom, d.v.s displayen till en PC och testa om det går att
få fram något.
Jag skulle även lägga mer krut på att hitta eller få tag på dokumentationen.
OK. Det var ju en jäkla skillnad, varför sa du inte det direkt ?
Om du faktiskt ser data som ser OK ut så kanske du ligger rätt
i *hastighet* i alla fall. Sen kanske 7/8 bit eller par/nopar kan spöka...
Jag skulle koppla tvärtom, d.v.s displayen till en PC och testa om det går att
få fram något.
Jag skulle även lägga mer krut på att hitta eller få tag på dokumentationen.
Man missar lätt att skriva lite information. Har i alla fall hittat detta program http://www.xs4all.nl/~jwasys/old/diy2.html , ska se om jag får det att fungera. Och förhoppningsvis kanske man blir lite klokare.
Tillverkaren lämnar inte ifrån sig information, har försökt.
Tillverkaren lämnar inte ifrån sig information, har försökt.
Jodå, det programmet kan nog vara till hjälp. Steg 2 är dock att analysera det jag fått fram.
Blev såhär http://bildplats.se/image/view/187
Tiden mellan de 2 röda sträcken är 1,05ms med reservation för lite mätfel.
Edit: Bittiden ligger på ca 105,88 uS vilket borde bli 9600 (med lite avrundning)
Blev såhär http://bildplats.se/image/view/187
Tiden mellan de 2 röda sträcken är 1,05ms med reservation för lite mätfel.
Edit: Bittiden ligger på ca 105,88 uS vilket borde bli 9600 (med lite avrundning)
Senast redigerad av ristomemo 1 december 2008, 17:02:46, redigerad totalt 1 gång.
Mitt tips är som Andli skriver. Kolla med skåp och tag reda på kortaste tiden. Det är troligen bittiden, vilket ger baudraten. Sedan kollar man tecken skiftena, d.v.s luskar ut startbit och stoppbit. Det ger antal bitar tecknen. Då har man tillräckligt för att få en första lyssning på serieporten. Paritet går att pröva sig fram till.
om du har oscilloskop så är det bara att mäta tiderna när dom är höga/resp låga - sikta på dom kortaste pulserna mitt i paketen som förmodligen är i datats baud-takt
Ett igenom detta så kan du sedan se om frekvenserna verka höra hemma i någon RS232 standard takt av 75/300/1200/2400/4800/9600/19200/28800/57600/115200 etc. baud och den vägen se om dessa tider verka rimliga.
Är det hembygge så kan det vara andra kristaller och UART-hastigheten hamnar någon stans mitt i mellan standardbaudtakt avsiktligt för att försvåra avlyssning - då kanske kristallbyte i enheterna är lösningen innan du kan börja debugga med datorn
Ett igenom detta så kan du sedan se om frekvenserna verka höra hemma i någon RS232 standard takt av 75/300/1200/2400/4800/9600/19200/28800/57600/115200 etc. baud och den vägen se om dessa tider verka rimliga.
Är det hembygge så kan det vara andra kristaller och UART-hastigheten hamnar någon stans mitt i mellan standardbaudtakt avsiktligt för att försvåra avlyssning - då kanske kristallbyte i enheterna är lösningen innan du kan börja debugga med datorn
Försökte räkna på din bild,men tidsslottarna är inte symetrisk.
En vanlig 8N1 ska ha 10 bitar, (1 start, 8 data och 1 stop), försökte rita upp det men får inte in start/stop bitarna.
Personligen är jag inte övertygad om att det går att bitbanga en serieport av en parallelport i windows i någon högre hastighet / korrekthet i mätningarna.
Jag skulle provat att mata in enkänd hastighet säg 115200 och se att det blir rätt.
Det kan vara så att det ser ut att vara 9600 men är något högre egentligen. Så ett riktigt scope hade varit intressant.
En vanlig 8N1 ska ha 10 bitar, (1 start, 8 data och 1 stop), försökte rita upp det men får inte in start/stop bitarna.
Personligen är jag inte övertygad om att det går att bitbanga en serieport av en parallelport i windows i någon högre hastighet / korrekthet i mätningarna.
Jag skulle provat att mata in enkänd hastighet säg 115200 och se att det blir rätt.
Det kan vara så att det ser ut att vara 9600 men är något högre egentligen. Så ett riktigt scope hade varit intressant.