> Vad är "vanlig asynk kommunikation"?
Med start/stop bitar som synkar det hela.
Synkron kommunikation använder normalt synkroniserade
klockor med mycket högra noggranhet för att slippa start/stop
bitar efter varje "tecken", därav den större effektiviteten.
Som t.ex i HDLC/SDLC i SNA kommunikation, där man kanske
överförde kommuniktion från ett 20 tal terminaler och skrivare
over samma 9600 baud linje, så var effektiviteteten viktig.
PIC programmering i C
Jo visst, men async start/stop bitar är ju bara till för att hitta synkronisering på teckennivå. Om alla datapaket var endast ett tecken (t.ex. en byte) långt skulle allt vara klappat och klart med async överföring. Nu vill man ju vanligen överföra större data paket (och inte löpande text så att säga), som mottagaren automatiskt kan göra nån slags processering av. Och då är det inte lika självklart längre hur datan skall kodas.
Det är ju precis det jag säger... 
Asynk: synkar på varje tecken med lägre krav på klockorna, men med mer overhead.
Synk: Synkar med speciella "synk-tecken" med högre krav på klockorna men med mindre overhead.
> Och då är det inte lika självklart längre hur datan skall kodas.
Antingen KISS, eller nåot mer komplext (som t,.ex HDLC liknande protokoll)
om man har processorkraft och utvecklingstid för det.
Ganska enkelt igentligen...
Asynk: synkar på varje tecken med lägre krav på klockorna, men med mer overhead.
Synk: Synkar med speciella "synk-tecken" med högre krav på klockorna men med mindre overhead.
> Och då är det inte lika självklart längre hur datan skall kodas.
Antingen KISS, eller nåot mer komplext (som t,.ex HDLC liknande protokoll)
om man har processorkraft och utvecklingstid för det.
Ganska enkelt igentligen...
NU funkar min seriella överföring.
har en start byte 0xFF och en slutbyte 0xFE, däremellan har jag 5 bytes.
Trots alla era råd så valde jag att dela upp en int och skicka den som två chars. Det var för krångligt att implementera och jag förstod inte helt enkelt.
Nu är det så att omvandlingen av int till char inte fungerar riktigt.
int x (15-0) -> HighChar(15-8 ) +LowChar(7-0) Detta är bara en illustrationen av vad jag vill göra och bitnumren i respektive variabel.
såhär ser min kod ut;
unsigned char GetLowChar(unsigned int x)
{
unsigned char z;
return z=(unsigned char)x&0xFF; //Type cast x to char and "bit and" to selects its lower byte into z
//return z = *(char*)&x; // Sändar byten på låga adressen //ICECAP Ditt förslag som jag kommenterat bort
}
unsigned char GetHighChar(unsigned int x)
{
unsigned char z;
return z=(unsigned char)x>>8; //Type cast x to char and shift the second byte in x to z
//return z = *(unsigned char*)(&x + 1); // ICECAP ditt förslag Sändar byten på höga adressen
}
GetLowChar fungerar fint, men GetHighChar fungerar inte. Den fungerar inte med din kodsnutt heller ICECAP.
Vad kan felet vara. Det konstiga är när jag kommenterar bort allt inuti funktionen GetHighChar, så fungerar det som tänkt!!?
har en start byte 0xFF och en slutbyte 0xFE, däremellan har jag 5 bytes.
Trots alla era råd så valde jag att dela upp en int och skicka den som två chars. Det var för krångligt att implementera och jag förstod inte helt enkelt.
Nu är det så att omvandlingen av int till char inte fungerar riktigt.
int x (15-0) -> HighChar(15-8 ) +LowChar(7-0) Detta är bara en illustrationen av vad jag vill göra och bitnumren i respektive variabel.
såhär ser min kod ut;
unsigned char GetLowChar(unsigned int x)
{
unsigned char z;
return z=(unsigned char)x&0xFF; //Type cast x to char and "bit and" to selects its lower byte into z
//return z = *(char*)&x; // Sändar byten på låga adressen //ICECAP Ditt förslag som jag kommenterat bort
}
unsigned char GetHighChar(unsigned int x)
{
unsigned char z;
return z=(unsigned char)x>>8; //Type cast x to char and shift the second byte in x to z
//return z = *(unsigned char*)(&x + 1); // ICECAP ditt förslag Sändar byten på höga adressen
}
GetLowChar fungerar fint, men GetHighChar fungerar inte. Den fungerar inte med din kodsnutt heller ICECAP.
Vad kan felet vara. Det konstiga är när jag kommenterar bort allt inuti funktionen GetHighChar, så fungerar det som tänkt!!?
På föregående sida har du ju fina makron för att ta ut den höga respektive låga byten ur en int.
#define hibyte(x) (unsigned char)(x>>8 )
#define lobyte(x) (unsigned char)(x & 0xFF)
Varför man kör med "&0xFF" vet jag dock inte. Det borde fungera utan. Någon som vet?
Anledningen till varför GetHighChar() inte fungerar är nog att du måste ha parenteser kring "x>>8". Men till sådana här småsaker tycker jag att det är snyggare att använda makron.
Förresten behöver du inte variabeln "z" i dina funktioner.
#define hibyte(x) (unsigned char)(x>>8 )
#define lobyte(x) (unsigned char)(x & 0xFF)
Varför man kör med "&0xFF" vet jag dock inte. Det borde fungera utan. Någon som vet?
Anledningen till varför GetHighChar() inte fungerar är nog att du måste ha parenteser kring "x>>8". Men till sådana här småsaker tycker jag att det är snyggare att använda makron.
Förresten behöver du inte variabeln "z" i dina funktioner.
sodjan
Jag får bara noll tillbaks oavsett.
Hur ska man göra då? Jag skickar mina bytes binärt/hexadecimalt. Det är räknare som räknar upp från 0-400. Därför jag behöver en int. Oavsett vad jag använder som start och stopbit, så kommer det ju att komma med när en av mina bytes räknas upp! Eller finns det någon annan lösning på detta?
Som jag har sett så fungerar det fint. Jag har ett labview program som ser ut som excel där jag tar emot allt och sedan kan spara ner till excel.
cykze;
Att det var så lätt
Tack för hjälpen
Jag har lite andra småproblem. Ska se om jag kan lösa det annars får jag be om hjälp här. Men det är lite invecklat handlar om kalibrereing och stegningen av stegmotorerna.
Jag får bara noll tillbaks oavsett.
Hur ska man göra då? Jag skickar mina bytes binärt/hexadecimalt. Det är räknare som räknar upp från 0-400. Därför jag behöver en int. Oavsett vad jag använder som start och stopbit, så kommer det ju att komma med när en av mina bytes räknas upp! Eller finns det någon annan lösning på detta?
Som jag har sett så fungerar det fint. Jag har ett labview program som ser ut som excel där jag tar emot allt och sedan kan spara ner till excel.
cykze;
Att det var så lätt
Tack för hjälpen
Jag har lite andra småproblem. Ska se om jag kan lösa det annars får jag be om hjälp här. Men det är lite invecklat handlar om kalibrereing och stegningen av stegmotorerna.
> binärt/hexadecimalt.
Vilket av dom ?
Det är binär överföring som kan vara problem. (1)
Att skicka i HEX däremot ska vara OK, rent överföringsmässigt. (2)
Och HEX är enklare i processorn att hantera än t.ex decimal överföring.
(1) Löses genom att alltid förutsätta en viss längd, d.v.s att stop tecknet
inte alltid tolkas som "stopp".
(2) Eftersom alla tecken mellan start och stopp kommer att vara "0-9","A"-"F".
> Jag får bara noll tillbaks oavsett.
OK, då är det väl själva uppdelningen av en 16-bits int i två 8-bits bytes
som är problemet, inte överföringen i sig.
Vilket av dom ?
Det är binär överföring som kan vara problem. (1)
Att skicka i HEX däremot ska vara OK, rent överföringsmässigt. (2)
Och HEX är enklare i processorn att hantera än t.ex decimal överföring.
(1) Löses genom att alltid förutsätta en viss längd, d.v.s att stop tecknet
inte alltid tolkas som "stopp".
(2) Eftersom alla tecken mellan start och stopp kommer att vara "0-9","A"-"F".
> Jag får bara noll tillbaks oavsett.
OK, då är det väl själva uppdelningen av en 16-bits int i två 8-bits bytes
som är problemet, inte överföringen i sig.
Det sodjan menar (tror jag) är att det är ingen större ide att sända synkroniserinstecken (FF och FE i ditt fall) i början och slutet om själva data också kan innehålla de samma tecknen.
Men, om du nu vet att din räknare har maxvärde 400, kan du ju göra såhär:
int x = ValueToBeSent();
SendByte(0xFF);
SendByte(x & 0x7F);
SendByte((x >> 7) & 0x7F);
SendByte(0xFE);
Dvs, du sänder endast 7 bitar per byte av din räknare, så att högsta biten alltid är 0 i datat du sänder. Du kan då överföra 14 bit, dvs 0...16383. Behöver du överföra hela 16 bitar får du sända de två högsta bitarna i en tredje byte.
Men, om du nu vet att din räknare har maxvärde 400, kan du ju göra såhär:
int x = ValueToBeSent();
SendByte(0xFF);
SendByte(x & 0x7F);
SendByte((x >> 7) & 0x7F);
SendByte(0xFE);
Dvs, du sänder endast 7 bitar per byte av din räknare, så att högsta biten alltid är 0 i datat du sänder. Du kan då överföra 14 bit, dvs 0...16383. Behöver du överföra hela 16 bitar får du sända de två högsta bitarna i en tredje byte.
Jag har föreslagit det tidigare: skriv det som text. Värdet 12 blir då '1' och '2', före och efter slängar du då ett start- och ett sluttecken. Enkelt och tydligt.
Men insisterar du på att köra med binära värden får du nog adaptera HDLC eller liknande och det blir nog minst lika "besvärligt" som att överföra som ren text.
En möjlighet mer är att bara skicka 7 bit åt gången, det medför lite shiftande av data och en extra byte i överföring men högsta bitten kan man då markera specialtecken med: 0x80 = start av block, 0x81 = slut av block. Alla värden däremellan går mellan 0x00 och 0x7F, den bit som "blir över" får läggas in i nästa som sänds osv.
Sammantaget blir det lika besvärligt som att sända det som text.
Ser du var jag vill komma?
Edit: oj då, jag var inte ensam om 7-bit idéen...
Men insisterar du på att köra med binära värden får du nog adaptera HDLC eller liknande och det blir nog minst lika "besvärligt" som att överföra som ren text.
En möjlighet mer är att bara skicka 7 bit åt gången, det medför lite shiftande av data och en extra byte i överföring men högsta bitten kan man då markera specialtecken med: 0x80 = start av block, 0x81 = slut av block. Alla värden däremellan går mellan 0x00 och 0x7F, den bit som "blir över" får läggas in i nästa som sänds osv.
Sammantaget blir det lika besvärligt som att sända det som text.
Ser du var jag vill komma?
Edit: oj då, jag var inte ensam om 7-bit idéen...
Vill man absolut skicka data som rådata med start och sluttecken så kan man göra så att man byter dessa tecken inuti packetet mot tvåteckenskombinationer. T.ex om FF är använt till start eller stopp så byter man FF inuti packetet mot t.ex FE 01 och byter FE mot FE 00. Sedan omvänt när man läser ut det igen. Så länge man ligger i synk och inte missar några tecken så är det inga problem alls. Skulle man missa tecken så får man börja på nytt packet med starttecken igen. Behöver man två start/stopp-tecken (som i ditt fall) så lägger man på en kombination till. Detta blir ett effektivare protokoll teckenmässigt (jämfört med ASCII-variant), men inte lika lättläst med t.ex. ett terminalprogram. Jag har kört varianter på sådana här protokoll under närmare 15 år.
Tack för förslagen, jag ska gå igenom prova och förstå och återkommer sedan.
Eftersom programmet som ska ta emot redan är klart och han som har gjort den är på semester så får jag hålla mig till den tills vidare och itne ändra i protokollet. Men att då skicka 7 byte endast verkar intressant. Alla förslag är itnressanta och ger lärdom. Sedan kan man ju göra det bättre nästa gång nu när jag vet allt detta.
Eftersom programmet som ska ta emot redan är klart och han som har gjort den är på semester så får jag hålla mig till den tills vidare och itne ändra i protokollet. Men att då skicka 7 byte endast verkar intressant. Alla förslag är itnressanta och ger lärdom. Sedan kan man ju göra det bättre nästa gång nu när jag vet allt detta.
USB interface
Vad rekommenderar ni för lättdesignat USART-USB interface. Så att man kan använda usb anslutning till datorn, istället för USART-RS232 via seriellinterfacet?
Gärna inte alltför litet package. Så att det går att handlöda.
Jag har använt ett från Silabs förut.
Gärna inte alltför litet package. Så att det går att handlöda.
Jag har använt ett från Silabs förut.
Borde kanske ha varit en ny tråd, det börjar bli lite väl långt
från "PIC programmering i C"...
Annars är väl någon av FTDI kretsarna de som verkar vara populärast...
http://www.ftdichip.com/FTProducts.htm
från "PIC programmering i C"...
Annars är väl någon av FTDI kretsarna de som verkar vara populärast...
http://www.ftdichip.com/FTProducts.htm
