[C/MCC18] Karakters wijzigen in string lukt niet

[NMe]

Ik ben momenteel bezig met een stukje hardware (uitgerust met een PIC18F8621) dat moet kunnen praten met een touchscreen middels RS-485. Om dat mogelijk te maken kan ik bepaalde commando's naar het touchscreen sturen, die iets wegschrijven naar diens geheugen, danwel iets uitlezen uit dat geheugen.

De commando's volgen ruwweg deze indeling: ze beginnen met 0x05, een enquiry-byte dus, gevolgd door twee bytes die aangeven op welk venster de wijziging van toepassing is. Daarna komt er een escape-byte, gevolgd door een 'R' voor een leesactie of een 'W' voor een schrijfactie. De volgende 12 bytes geven in groepen van 4 respectievelijk een adres, het aantal bytes dat gelezen/weggeschreven moet worden en, in het geval van een schrijfactie, een waarde aan in stringrepresentatie. De string wordt afgesloten door een carriage return en een linefeed. Als ik dus naar adres 103 de waarde 2 wil wegschrijven, dan ziet de string in kwestie er zo uit:
\x005FF\x01bW010300010002\r\n

So far, so good, die waarde kan ik doorsturen en die komt ook goed aan. Nu komt echter het probleem: ik wil een waarde die ik uitlees uit een ADC omzetten naar een percentage, en dit opslaan in het geheugen van het touchscreen. Dit mag echter blijkbaar niet. Ik heb het probleem weten terug te brengen tot een simpele vorm:

C:

char* send = "\x005FF\x01bW010300010000\r\n";

send[16] = '1';

writeRS485(send);

Wanneer ik regel 3 weglaat, dan wordt de string die ik aangeef netjes verstuurd zoals gevraagd. Als ik regel 3 echter wel toevoeg, dan verwacht ik dat de byte vóór de \r in een 1 verandert. Dit gebeurt dus niet; de string die doorgestuurd wordt is exact dezelfde die ik in het begin definiëer. De volgende manieren gaan (logischerwijs) ook niet:

C:

send[16] = 0x31;
//of
*(send + 16) = '1';

Waar en waarom het fout gaat weet ik niet; debuggen is een ramp in de MPLAB IDE die Microchip levert. Ik hoop dat iemand hier er ervaring mee heeft.

[DroogKloot]

Als je in C een string initialiseert zoals jij daar doet dan wordt -ie immutable gemaakt omdat het een literal is, expliciet mallocen dus.

[ Voor 28% gewijzigd door DroogKloot op 19-07-2006 18:57 ]

[NMe]

Ik heb geen malloc tot mijn beschikking, en de verscheidene non-standaard strcat-functies werken eveneens niet goed; die laten het apparaat in zijn geheel vastlopen. De variabele als volgt declareren vindt de compiler ook niet leuk:

C:

char send[19];
send = "\x005FF\x01bW010300010000\r\n";

Dit resulteert in:

C:\VeTeTronics\steenbeck\current\main.c:779:Error [1153] cannot assign array type objects
C:\VeTeTronics\steenbeck\current\main.c:779:Error [1102] cannot assign to 'const' modified object
C:\VeTeTronics\steenbeck\current\main.c:779:Error [1131] type mismatch in assignment

[DroogKloot]

C:

char send[32] = "\x005FF\x01bW010300010000\r\n";

[NMe]

Dat levert, in eenzelfde constructie als die hierboven niet meer op dan het doorsturen van random bytewaarden. send als op dezelfde manier char send[20] (precies genoeg) definiëren helpt ook niet.

[bigbeng]

Werkt strcpy wel?

Anders vrees ik dat je char voor char je array zal moeten vullen.

[joca]

Waarom defineer je send als een pointer? Een pointer is toch alleen bedoeld om een geheugenadres te bewaren? zoiets als: send = &test[16];

Je kan je array overigens ook nog als onderstaand declareren:

unsigned char send[4] = {0x01,0x02,0x03,0x04};

edit:
nav Droogkoot.
Hm je krijgt dus het geheugenadres mee van iets dat je alleen op de stack alloceert, hmm wist niet dat dat kon, weer wat geleerd.

Maar goed als dat dus niet werkt kan je altijd nog van je variabele in de writeRS485 een pointer maken en vervolgens het adres van send doorgeven, dan heb je iig niet alles op de stack.

[ Voor 41% gewijzigd door joca op 19-07-2006 14:50 ]

[DroogKloot]

Heh? Kun je binnen die hardware-omgeving uberhaupt wel een pointer naar een op de stack gealloceerd array meegeven aan een andere functie dan? Daar lijkt me namelijk het probleem te zitten, want die assignment (in mijn laatste post) is compleet legaal...

[ Voor 5% gewijzigd door DroogKloot op 19-07-2006 14:46 ]

[NMe]

bigbeng schreef op woensdag 19 juli 2006 @ 14:42:
Werkt strcpy wel?

Anders vrees ik dat je char voor char je array zal moeten vullen.

Dat is dus wat ik hier probeer, maar wat niet echt wil lukken.

Joca schreef op woensdag 19 juli 2006 @ 14:42:
Waarom defineer je send als een pointer? Een pointer is toch alleen bedoeld om een geheugenadres te bewaren? zoiets als: send = &test[16];

Arrays zijn per definitie pointers, en strings zijn intern arrays van characters. Dus ja, een string moet een pointer zijn naar een char, althans, in C.

DroogKloot schreef op woensdag 19 juli 2006 @ 14:45:
Heh? Kun je binnen die hardware-omgeving uberhaupt wel een pointer naar een op de stack gealloceerd array meegeven aan een andere functie dan? Daar lijkt me namelijk het probleem te zitten, want die assignment (in mijn laatste post) is compleet legaal...

Met far en near is er wat aan te vangen, maar beide keywords hebben geen effect.

[bigbeng]

-NMe- schreef op woensdag 19 juli 2006 @ 15:04:
[...]

Dat is dus wat ik hier probeer, maar wat niet echt wil lukken.

[...]

Snap ik, maar een char bla[..] = "" wordt compiletime afgehandeld

C:

char send[15];

send[0]='/x005';
send[1]=.. etc...

Doet dit het wel?

offtopic:
Leuk man, dit lowlevel geneuzel

[NMe]

bigbeng schreef op woensdag 19 juli 2006 @ 15:15:
[...]

Snap ik, maar een char bla[..] = "" wordt compiletime afgehandeld

C:

char send[15];

send[0]='/x005';
send[1]=.. etc...

Doet dit het wel?

Nope, dat levert ook allerlei random bytes op op mijn LCD-schermpje, evenals de oplossing van DroogKloot in "[C/MCC18] Karakters wijzigen in string l...". Ik ga de write-functie nog eens nalopen, misschien dat daar wat anders gaat vanaf het moment dat de string al dan niet van de stack af komt.

offtopic:
Leuk man, dit lowlevel geneuzel

offtopic:
Lowlevel speelgoed is erg leuk, maar strings vind ik in C al vervelend genoeg als ik wèl gebruik kan maken van de diverse stringfuncties die er zijn.

[bigbeng]

Wellicht ten overvloede: Vergeet niet om de laatste char nog even op 0 te zetten, want strings in C zijn 0-terminated.

[NMe]

Dat was inderdaad ten overvloede. Geen effect, helaas.

[DroogKloot]

Wat je nog wel zou kunnen doen is een globale char send[MAX_LEN] gebruiken zodat je helemaal niets aan writeRS485() hoeft mee te geven, maar dat valt bij mij onder de noemer "smerig".

[ Voor 6% gewijzigd door DroogKloot op 19-07-2006 17:18 ]

[NMe]

Dat is het verplaatsen van het probleem, aangezien de functie writeRS485() onder andere weer een andere functie aanroept uit de standaardlibrary. En die functie gebruikt dezelfde string als parameter.

[.oisyn]

Euh, volgens mij ga je er vanuit dat na de \x 3 getallen komen, maar dat zijn er maar 2. Als je positie 16 aan zou passen dan verander je ook niet het teken voor de \r, maar 3 tekens voor de \r

\x005 is ook helemaal niet 0x05, maar \0 gevolgd door een '5'

(dit naast het feit dat je string literals idd niet mag wijzigen, eigenlijk moet je ze ook assignen aan een const char*, maar een assignment aan char* is toegestaan om legacy redenen. Voor wijzigbare strings doe je char bla[] = "hoi")

[ Voor 38% gewijzigd door .oisyn op 19-07-2006 18:01 ]

[prototype]

-NMe- schreef op woensdag 19 juli 2006 @ 15:04:
[...]

Arrays zijn per definitie pointers, en strings zijn intern arrays van characters. Dus ja, een string moet een pointer zijn naar een char, althans, in C.

Errrrr, nee toch echt niet Dit is een veelvoorkomend misverstand. Je leest vaak dat pointers en arrays equivalent zijn, maar met deze equivalentie wordt niet bedoelt dat pointers, arrays zijn. Het wil zeggen dat pointer arithmatiek en arrayindexing equivalent zijn in C, i.e. pointer en array arithmatiek zijn zo gedefinieerd dat een pointer handig gebruikt kan worden voor het immiteren en aanspreken van een array. Pointers en arrays zijn wel degelijk verschillend.

[NMe]

.oisyn schreef op woensdag 19 juli 2006 @ 17:54:
Euh, volgens mij ga je er vanuit dat na de \x 3 getallen komen, maar dat zijn er maar 2. Als je positie 16 aan zou passen dan verander je ook niet het teken voor de \r, maar 3 tekens voor de \r

\x005 is ook helemaal niet 0x05, maar \0 gevolgd door een '5'

Dat dacht ik ook, totdat ik erachter kwam dat dat niet werkte. Vervolgens heb ik de documentatie van de compiler doorgenomen (voor zover die überhaupt bestaat), en daarin gebruikten ze telkens 3 getallen na de \x. De waarden die aankomen op mijn touchscreen kloppen bij die letterlijke sting ook prima, ik krijg de hexwaarden 5, 46, 46, 1B, etc. Dat is dus blijkbaar niet fout.

(dit naast het feit dat je string literals idd niet mag wijzigen, eigenlijk moet je ze ook assignen aan een const char*, maar een assignment aan char* is toegestaan om legacy redenen. Voor wijzigbare strings doe je char bla[] = "hoi")

Met de notatie char bla[] = "hoi" ben ik bekend en die gebruikte ik in de eerste instantie ook, maar blijkbaar mag dat ook al niet van de compiler. Het resulteerde in de zoveelste syntaxerror die ik niet kon plaatsen.

prototype schreef op woensdag 19 juli 2006 @ 18:10:
[...]

Errrrr, nee toch echt niet Dit is een veelvoorkomend misverstand. Je leest vaak dat pointers en arrays equivalent zijn, maar met deze equivalentie wordt niet bedoelt dat pointers, arrays zijn. Het wil zeggen dat pointer arithmatiek en arrayindexing equivalent zijn in C, i.e. pointer en array arithmatiek zijn zo gedefinieerd dat een pointer handig gebruikt kan worden voor het immiteren en aanspreken van een array. Pointers en arrays zijn wel degelijk verschillend.

Ik zeg ook niet dat pointers arrays zijn, ik zeg precies het omgekeerde: arrays zijn pointers. Net zoals auto's voertuigen zijn, maar een voertuig niet per se een auto is.

[ Voor 25% gewijzigd door NMe op 19-07-2006 18:16 ]

[prototype]

-NMe- schreef op woensdag 19 juli 2006 @ 18:15:

[...]

Ik zeg ook niet dat pointers arrays zijn, ik zeg precies het omgekeerde: arrays zijn pointers. Net zoals auto's voertuigen zijn, maar een voertuig niet per se een auto is.

Ook dan klopt het niet, daar een array meer informatie opslaat dan een pointer. Denk aan de size van de array, wat type embedded is. Of wil je beweren dat een array een subklasse is van een pointer?

[ Voor 9% gewijzigd door prototype op 19-07-2006 18:24 ]

[matthijsln]

prototype schreef op woensdag 19 juli 2006 @ 18:23:
[...]
Ook dan klopt het niet, daar een array meer informatie opslaat dan een pointer. Denk aan de size van de array, wat type embedded is. Of wil je beweren dat een array een subklasse is van een pointer?

((int[])ptr)[i] is hetzelfde als *((int*)ptr + i)

[prototype]

matthijsln schreef op woensdag 19 juli 2006 @ 23:47:
[...]


((int[])ptr)[i] is hetzelfde als *((int*)ptr + i)

prototype schreef op woensdag 19 juli 2006 @ 18:10:
[...]

Het wil zeggen dat pointer arithmatiek en arrayindexing equivalent zijn in C, i.e. pointer en array arithmatiek zijn zo gedefinieerd dat een pointer handig gebruikt kan worden voor het immiteren en aanspreken van een array. Pointers en arrays zijn wel degelijk verschillend.

Neem het ook eens van een andere aan, en speciaal omdat jullie vast referentiekader willen:
Cambridge University
TU Berlin
University of Washington
IBM
etc...

[farlane]

Ik zie een paar mogelijkheden:

- De compiler is erg slecht. Soms wil dat nog wel eens gebeuren met dit soort omgevingen. ( Als je dat wil checken zul je in de gecompileerde asm moeten wroeten )
- Je hebt ergens anders in je software een bug zitten die over je buffer schrijft
- Door een eigenschap van de hardware ( interrupts, timers, memory overlap ) loopt jouw stukje in de soep.
- Hardware is niet goed ( instabiele voeding bv )

Btw MPLAB sucked echt bigtime

[NMe]

farlane schreef op donderdag 20 juli 2006 @ 08:51:
Ik zie een paar mogelijkheden:

- De compiler is erg slecht. Soms wil dat nog wel eens gebeuren met dit soort omgevingen. ( Als je dat wil checken zul je in de gecompileerde asm moeten wroeten )
- Je hebt ergens anders in je software een bug zitten die over je buffer schrijft
- Door een eigenschap van de hardware ( interrupts, timers, memory overlap ) loopt jouw stukje in de soep.
- Hardware is niet goed ( instabiele voeding bv )

Btw MPLAB sucked echt bigtime

MPLAB zuigt inderdaad. Ik heb ook met Keil µVision gewerkt en vond dat niks, maar nu zou ik graag terug willen, die omgeving was 10x beter. Anyway, om die reden geloof ik ook dat dit niet door mij komt. Deze compiler pakt allerlei dingen totaal anders aan dan de standaard, en niet alleen in de basis, maar ook in libraries en dergelijke. Ik heb complete regels code "weggeoptimaliseerd" zien worden.

Interrupts, timers, enz. kunnen het probleem niet zijn trouwens, ik heb op dezelfde hardware ook een projectje gemaakt dat puur en alleen met het touchscreen wil praten, en dat gaat op dezelfde plek mis. De hardware is ook goed, we hebben het spul verschillende keren grondig doorgemeten.

Ik denk dat ik de assembly listing maar eens door ga nemen, goeie tip. Alleen maar hopen dat mijn kennis van ASM niet te ver is afgezakt om hulp te kunnen bieden.

prototype schreef op donderdag 20 juli 2006 @ 00:58:
[...]


Neem het ook eens van een andere aan, en speciaal omdat jullie vast referentiekader willen:
Cambridge University
TU Berlin
University of Washington
IBM
etc...

Ik heb ook nooit beweerd dat een van de dingen in die bronnen niet waar is?

[prototype]

-NMe- schreef op donderdag 20 juli 2006 @ 09:06:
[...]

Ik heb ook nooit beweerd dat een van de dingen in die bronnen niet waar is?

Door te zeggen dat arrays pointers zijn, zoals je hierboven hebt gezegd, doe je dat wel.

[NMe]

Ik had het inderdaad beter kunnen verwoorden. Maar goed, ik was ook een beetje preoccupied.

De fout is er inmiddels uit. Het blijkt dat die willekeurige tekst die naar het touchscreen gestuurd werd niet veroorzaakt werd door een foute string; die string was namelijk goed in de notatie die onder andere .oisyn hierboven aanhaalt. Wat er daar fout ging, was dat een literal string in het programmageheugen staat, terwijl mijn variabele string in het RAM-geheugen terechtkomt. De USART-functie die ik gebruikte voor de RS-485 communicatie verwachtte echter een pointer naar ROM-geheugen, waardoor ik prut doorstuurde. Simpelweg de RAM-versie van dezelfde functie aanroepen was genoeg om het probleem op te lossen. En daar zit je dan anderhalve dag op te debuggen.

[farlane]

Lees dit nu en ik had me net bedacht dat sommige van dat soort compilers const dingen automatisch in programma geheugen zetten ( PSOC oa en dus ook MPLAB ) en dat functies die die data gebruiken dan andere instructies mioeten gebruiken.

Maar je had em al gevonden

[NMe]

Mjah, het leuke is dus dat ik dit allang wist, en al eerder met een vergelijkbare fout heb gezet, en daarna dus bewust de program memory-versie gebruikt heb.

Laat ik maar als excuus aandragen dat ik door de hitte te weinig geslapen heb en hiervoor 2 weken niet aan het project heb kunnen werken, dan sta ik tenminste niet helemaal voor lul.

[.oisyn]

-NMe- schreef op donderdag 20 juli 2006 @ 23:16:
dan sta ik tenminste niet helemaal voor lul.

Helaas

[NMe]

Niet meer dan anders bedoel ik.

[farlane]

-NMe- schreef op vrijdag 21 juli 2006 @ 11:16:
Niet meer dan anders bedoel ik.