Byte-ordning bakvänd i MPLAB
Byte-ordning bakvänd i MPLAB
Är det fler än jag som tycker att Microchips(MPLAB) sätt att skriva byte-ordning på variabler är bakvänt.
Ett exempel:
Byte Order HIGH:LOW
Fösta adressen innehåller värdet 3
Andra adressen innehåller värdet 1
16-bitars variabeln innehåller värdet 259
Jag tycker det logiska är att resultatet blir 769
Vad tycker ni?
Ett exempel:
Byte Order HIGH:LOW
Fösta adressen innehåller värdet 3
Andra adressen innehåller värdet 1
16-bitars variabeln innehåller värdet 259
Jag tycker det logiska är att resultatet blir 769
Vad tycker ni?
Hög adress = höga värdet, låg adress = låga värdet, på vilket vis är det ologisk?
Det har med Little/Big Endian att göra och har nära nog alltid varit en tvistefråga mellan (org) Motorola och Intel.
Motorola kör Big Endian, alltså höga värden byten på lägsta minnesadress och Intel kör Little Endian.
Jag tycker att Big Endian är ologisk och skillnaden kan ställa till det när man portar kod (t.ex. C-program) som plockar ut delar av ett större värde.
Sen började jag också med Z80 med Little Endian....
Det har med Little/Big Endian att göra och har nära nog alltid varit en tvistefråga mellan (org) Motorola och Intel.
Motorola kör Big Endian, alltså höga värden byten på lägsta minnesadress och Intel kör Little Endian.
Jag tycker att Big Endian är ologisk och skillnaden kan ställa till det när man portar kod (t.ex. C-program) som plockar ut delar av ett större värde.
Sen började jag också med Z80 med Little Endian....
Jag ifrågasätter inte vilken ordning som är logisk att använda, i MPLAB kan man välja själv.
Det är sättet dom beskriver ordningen på som är ologisk, titta på mitt exempel igen.
[EDIT] Jag tycker att HIGH:LOW borde betyda Höga byten först och låga byten sen men detta sätt att beskriva det på är kanske standard.
Det är sättet dom beskriver ordningen på som är ologisk, titta på mitt exempel igen.
[EDIT] Jag tycker att HIGH:LOW borde betyda Höga byten först och låga byten sen men detta sätt att beskriva det på är kanske standard.
Det intressanta är om det avviker från hur det fungerar i PIC'en för övrigt.
Ta t.ex TMR1H:TMR1L i en PIC18.
Där är den första adressen (den lägre, h'FD6') TMR1L
och den andra (den högre, h'FD7') TMR1H.
Dock skrivs det som 'högre_adress:lägre_adress', alltså 'TMR1H:TMR1L'.
Så sättet som MPLAB benämner det stämmer överens med det sätt
som är standard i datablad och i arkitekturern för övrigt.
Ta t.ex TMR1H:TMR1L i en PIC18.
Där är den första adressen (den lägre, h'FD6') TMR1L
och den andra (den högre, h'FD7') TMR1H.
Dock skrivs det som 'högre_adress:lägre_adress', alltså 'TMR1H:TMR1L'.
Så sättet som MPLAB benämner det stämmer överens med det sätt
som är standard i datablad och i arkitekturern för övrigt.
Man anger ofta sammansatta värden med ett ':' som delning och det betyder inte att adressen ligger så men att det totala värdet styckas ihop på det vis.
Alltså Totala värdet = 'Högsta byte:Lägsta Byte'.
Att tillverkarna också försöker att göra samma sak i praktiken vid att placera adressorna så att det passar med den valda Endian är ju bara bra, det kan iaf. lösa en del buggar som kommer av obetänksamhet.
Alltså Totala värdet = 'Högsta byte:Lägsta Byte'.
Att tillverkarna också försöker att göra samma sak i praktiken vid att placera adressorna så att det passar med den valda Endian är ju bara bra, det kan iaf. lösa en del buggar som kommer av obetänksamhet.