Toen ik jaren terug begon met programmeren in C, vond ik pointers ook lastig. Het heeft wel even wat oefening nodig gehad om het goed door te hebben.
Het is ook soms wel beetje gevaarlijk wat ik met pointers doe. Maar in dit geval kan het, je kan niet altijd alles maar up en downcasten

.
(&LATB)
Is inderdaad "geef mij het adres van" LATB.
Omdat LATB van het type 16-bits integer is, zal de compiler hem met 16-bit "gedoe" aanspreken. Ik wil dat juist met 8-bits doen. Omdat ik daar bij ook nog eens het eerste of tweede deel wil aanspreken, is het makkelijker om met een pointer te werken. Daarom zeg ik :
(unsigned char*)
Waarschijnlijk was het originele type LATB een (volatile) unsigned int. Met & had ik het type al gewijzigd naar het type volatile unsigned int*.
Door het om te zetten naar een unsigned char*, gaat de compiler hem gebruiken als losse bytes. Door dan de array index te gebruiken kan ik de eerste of tweede pakken.
Dat * een dereferentie is , is dus deels waar. Als het bij een variabel type staat, betekent het dat die variabele een verwijzing is naar het type wat het aangeeft. Als je dan * op die variabele zet bij aanspreken, zal het met dat geheugenadres werken zoals dat type aangeeft.
[0] spreekt eigenlijk ook de variable op dat adres aan. [1] ook , maar dan 1 voor uit geschoven.
Ik had , eigenlijk, ook kunenn zeggen:
*((unsigned char*)(&LATB) + 1) = 0x55;
Hier mee zet ik de pointer ook 1 "unsigned char" naar voren. Eigenlijk identiek aan [1].
Het is niet per definitie 1 byte overigens, al was het type bvb een object van 32 bytes, was het pointer-adres met +1 maarliefst 32 bytes naar voren geschoven..
Dan geldt er ook nog een regel dat * eerder wordt uitgevoerd dan ++, net zoals we eerst vermedigvuldigen en delen, voor plus en min.
Over de vraag van kitao.
Ja er bestaan debuggers die kunnen backsteppen voor bepaalde talen en omgevingen (was onlangs ook met GCC/GDB mogelijk gemaakt), maar ik heb het persoonlijk nog nooit nodig gehad of gebruikt. Bovendien had men toen het enkel nog over de command-line functionaliteit van GDB, wat nog niet de debug functionaliteit van elke IDE is.
Ik zou niet weten wat de huidige status hier van is. Ik ben persoonlijk nog teveel gebonden aan Windows met mijn ontwikkelomgevingen, ik wil graag nog een keer echt de overstap maken naar Linux. Maar ik moet dan games & Altium missen
Over je debug methodiek:
Je hoeft niet op elke lijn breakpoints te zetten. Je kan ook "Step Into" (F11) en "Step Over" (F10) doen.
Intellitrace is enkel geschikt voor managed omgevingen, zoals Visual Basic en C#. Daar heb ik eigenlijk ook nog geen Step Back functie gezien overigens..
Naar mijn mening, is de beste manier om te leren, examples te lezen en proberen te begrijpen (waar je nu mee bezig bent), maar dan vervolgens dat zelf in de praktijk te kunnen brengen door iets van niets te bouwen. Door dat te doen ga je ook fouten maken, en door te observeren en goed na te denken kan je zien wat er echt gebeurd.
Tenminste, zo heb ik veel geleerd. Dat komt niet van tutorials, die heb ik eigenlijk amper doorgespit. Ik ben o.a. op school, hobby & stages/werk gewoon bezig gegaan met projecten en door vallen proberen op te staan en dingen goed werkend te krijgen
En de bugs waar je met 1 collega
letterlijk 1 week vast zit, zijn het frusterends, maar wel het meest leerzaams (en ook een reminder dat alles vaak tot in de puntjes perfect moet functioneren, wil een systeem goed werken).
Een goed geheugen helpt altijd. Uiteindelijk zorgt het er voor dat troubleshooten sneller gaat, want soms heb je dingen al eerder gezien. Bovendien is het minder omslachtig, want als je continu alles moet opzoeken is het vaak allemaal een raadsel, en dat is niet handig.
Zo
had ik een (hardware) collega die elk ontwerp dat hij maakte "iets nieuws wou proberen". Waar dat op sloeg was dat zijn design altijd copy+paste van vorige designs was (dan bedoel ik voeding, communicatie interfaces, processor, debug poorten, enz.) en hij 1 stuk vernieuwde voor het specifieke doeleinde van de ECU. Hij had dus geluk dat veel van de hardware gemeenschappelijke goederen hadden.
Alleen het probleem was; soms werkte delen van vorige designs ook (eerst) niet, en dat documenteerde hij dan ook niet. Resultaat: nieuwe design werkt weer niet op zelfde punt, maar hij was vaak ook vergeten of het vorige design dat ook had, vergeten wat hij er aan gedaan had, en ook vergeten dat
overal in de documentatie bij te werken. Het goede onderdeel stond wel op de bestellijst die naar de PCB-fabrikant ging hoor.. maar hoe het daar gekomen is en waarom niet.
Een goed geheugen was in zo'n geval dan handig geweest, danwel een goede structuur om bij te houden wat er mis ging. Natuurlijk is beide negeren erg gevaariljk.
Ik mis zelf structuur maar heb een goed geheugen.. hoewel ik merk dat die ook niet volledig heilig is als je in 2 jaar tijd meerdere keren geopereerd wordt/narcose krijgt.
[
Voor 8% gewijzigd door
Hans1990 op 19-05-2014 23:24
]