Håller på och programmerar en PIC som ska prata med en annan PIC via USART.
Nu är den kopplad till datorn och jag vill smidigt kunna skicka olika kommandon i hex-format gärna med hjälp av makron från datorn.
På så vis skulle jag lätt manuellt kunna agera den andra PICen och se att jag får rätt meddelanden. Telnet i windows eller terminalen i min kompilator (MikroC) klarar inte ens att skicka strängar i hex-format.
Helst ska det vara en freeware.
Terminal med macros mm för att kommunicera med PIC
Vad menar du med "hex-format" och "strängar i hex-format" ??
Ett HEX-format innhåller ju enbart tecknen "0-9" och "A-F" och borde inte
vara något problem. Om du däremot vill skicka 8 bitars *BINÄRA* värden
i intervallet 0-255 så kan det vara problem. Många av dessa tecken
kommer att tolkas på olika sätt som "control-tecken" o.s.v.
Generellt gäller att du ska försöka hålla dig till ett protokol som
gör att du alltid skickar "skrivbara" ASCII-tecken, då får du minst problem.
Ett HEX-format innhåller ju enbart tecknen "0-9" och "A-F" och borde inte
vara något problem. Om du däremot vill skicka 8 bitars *BINÄRA* värden
i intervallet 0-255 så kan det vara problem. Många av dessa tecken
kommer att tolkas på olika sätt som "control-tecken" o.s.v.
Generellt gäller att du ska försöka hålla dig till ett protokol som
gör att du alltid skickar "skrivbara" ASCII-tecken, då får du minst problem.
> Vill alltså bara behöva trycka ett macro för att sända en viss sekvens av
> hex-data. Som det är nu har jag olika filer med hex-datat som jag
> måste ladda och skicka vilket är rätt bökigt.
Fullständigt omöjligt att förstå det där !
Det måste vara en massa information som du själv har
"mellan öronen" man som du glömmer att vi inte har...
> hex-data. Som det är nu har jag olika filer med hex-datat som jag
> måste ladda och skicka vilket är rätt bökigt.
Fullständigt omöjligt att förstå det där !
Det måste vara en massa information som du själv har
"mellan öronen" man som du glömmer att vi inte har...
Om jag förstår det rätt så vill han ha ett terminalprogram där man kan programmera in sekvenser som skickas då man väljer dem. Tyvärr känner jag inte till något sådant, jag behövde ett en gång men då fixade jag det själv.
Ett lite enklare alternativ än att ladda filer borde ju vara att copy/pasta in dem i terminalprogrammet - om sekvenserna inte är otroligt långa.
Ett lite enklare alternativ än att ladda filer borde ju vara att copy/pasta in dem i terminalprogrammet - om sekvenserna inte är otroligt långa.
Var tydligen rätt dålig på att förklara mig. Ska försöka bättre.
Som hh var inne på så är det ett terminalprogram som man kan skicka olika sekvenser på serieporten med. Sekvenserna är ca 30 byte långa och är i binärt format. Dvs ASCII-värden mellan 0-255.
Det där med macron var alltså att man bara ska behöva trycka på en knapp eller köra ett kommando för att skicka en viss sträng. Tex Ctrl+1 skickar en sync-sträng, Ctrl+2 getdata-sträng osv.
Tittade på Realterm men tycker det är rätt bökigt. Har inte klurat ut hur jag skickar binärdata ännu.
Som hh var inne på så är det ett terminalprogram som man kan skicka olika sekvenser på serieporten med. Sekvenserna är ca 30 byte långa och är i binärt format. Dvs ASCII-värden mellan 0-255.
Det där med macron var alltså att man bara ska behöva trycka på en knapp eller köra ett kommando för att skicka en viss sträng. Tex Ctrl+1 skickar en sync-sträng, Ctrl+2 getdata-sträng osv.
Tittade på Realterm men tycker det är rätt bökigt. Har inte klurat ut hur jag skickar binärdata ännu.
> Sekvenserna är ca 30 byte långa och är i binärt format. Dvs ASCII-värden mellan 0-255.
Är det "hugget i sten" ?
Även mellan två processorer är det normalt enklare att hålla sig till
ASCII tecken, bl.a för att enklare debugga kommunikationen via t.ex
terminalemulator på en PC eller en RS232 linjelyssnare. Eventuellt att
men begränsar sig till något enstaka controll tecken som ESC eller liknande
som inte har så stor sannolikthet att "fastna" på vägen.
Ren binärdata kan enkelt skickas som hex för enkel felsökning och
säker kommunkation.
Men det kanske är styrt av något annat som du inte har kontroll över...
Är det "hugget i sten" ?
Även mellan två processorer är det normalt enklare att hålla sig till
ASCII tecken, bl.a för att enklare debugga kommunikationen via t.ex
terminalemulator på en PC eller en RS232 linjelyssnare. Eventuellt att
men begränsar sig till något enstaka controll tecken som ESC eller liknande
som inte har så stor sannolikthet att "fastna" på vägen.
Ren binärdata kan enkelt skickas som hex för enkel felsökning och
säker kommunkation.
Men det kanske är styrt av något annat som du inte har kontroll över...
Kommunikationen sker via Easy-Radio modul så det blir som att prata direkt mellan PICarna. Manskulle kunna säga att jag sätter upp ett protokoll där flera PICar sitter på samma seriellkabel och att det finns en master som bestämmer.
Hur som helst så håller jag mig till binär data eftersom det är bla 1-wire ID-nummer som ska skickas och de innehåller inga vanliga ASCII-tecken. Skulle kunna skriva HEX-värdena i ASCII format men då blir det dubbel så mycket data som ska skickas och det känns onödigt.
Hur som helst så duger Realterm för mitt ändamål nu.
Hur som helst så håller jag mig till binär data eftersom det är bla 1-wire ID-nummer som ska skickas och de innehåller inga vanliga ASCII-tecken. Skulle kunna skriva HEX-värdena i ASCII format men då blir det dubbel så mycket data som ska skickas och det känns onödigt.
Hur som helst så duger Realterm för mitt ändamål nu.
I realterm, kolla tabben "send" där skriver du in dina strängar binärt, typ" 234 11 25 54 23" etc.. sen trycker du på "send numbers så sänds de iväg binärt. Tyvärr finns det inte mer än två fält som man kan skriva in olika strängar i, det saknar jag med. Men lite klipp och klistra från en textfil är inte så farligt.
OK, du har bestämt dig, men jag måste i alla fall kommentera...
> eftersom det är bla 1-wire ID-nummer som ska skickas...
Helt ointressant *vad* som skickas! Du har full kontroll på båda sidor
och du kan välja att koda trafiken precis som du vill.
> Skulle kunna skriva HEX-värdena i ASCII format men då blir det
> dubbel så mycket data som ska skickas och det känns onödigt.
Först, HEX = ASCII !
Du menar antagligen "...skriva de binära värdena i HEX-format..."
Det blir lite mer kod i varje ände, men annars ser jag inte vad som är "onödigt".
Att koda om mellan binärt och hex är väldigt enkelt (i koden)
Det är en annan sak om man inte *hinner* att skicka datat under den
tillgängliga tiden.
*Personligen* skulle jag prioritera enkel felsökning och loggning
framför att spara in några ms på varje sändning.
Hur som helst, jag tänker inte fortsätta tjata om detta...
> eftersom det är bla 1-wire ID-nummer som ska skickas...
Helt ointressant *vad* som skickas! Du har full kontroll på båda sidor
och du kan välja att koda trafiken precis som du vill.
> Skulle kunna skriva HEX-värdena i ASCII format men då blir det
> dubbel så mycket data som ska skickas och det känns onödigt.
Först, HEX = ASCII !
Du menar antagligen "...skriva de binära värdena i HEX-format..."
Det blir lite mer kod i varje ände, men annars ser jag inte vad som är "onödigt".
Att koda om mellan binärt och hex är väldigt enkelt (i koden)
Det är en annan sak om man inte *hinner* att skicka datat under den
tillgängliga tiden.
*Personligen* skulle jag prioritera enkel felsökning och loggning
framför att spara in några ms på varje sändning.
Hur som helst, jag tänker inte fortsätta tjata om detta...
