Programmeren van C-programma's in een AVR

[Fritsprt]

Hallo mede hobbyisten,

In het verleden heb ik zelf weleens kleine programmaatjes in C geschreven en vervolgens als hex bestand in een uController gezet.
Nu ben ik me aan het verdiepen in o.a. Opendcc decoders. Als ik die programma's bekijk dan bestaan die uit meerdere C programma's. Bijvoorbeeld: main.c, dcc_decode.c, dcc_receiver.c, enz.
Mijn vraag is hoe kan ik deze programma's met Atmel Studio builden tot hex bestand en vervolgens als 1 bestand in de AVR branden?
Het lijkt me nl. niet de bedoeling ze één voor één te programmeren omdat je dan volgens mij steeds het voorgaande programma overschrijft.

Ik weet dat de software van Opendcc ook één hex bestand bevat maar ik wil juist de source code kunnen aanpassen en dan het hex bestand maken.

Ik hoop dat mijn vraag voldoende duidelijke is en anders hoor ik het graag.
Alvast bedankt voor de hulp.

gr. Frits

[Dave van der Locht]

Korte versie: De combinatie van die bestanden maakt het programma met veelal 2 bestanden die je nodig hebt, 1 voor het flash geheugen en 1 voor de eeprom.
De losse bestanden kun je voor het gemak even zien als modules/bouwstenen van het 'hoofdprogramma', in dit geval main.c. Alle ingrediënten bij elkaar maakt 1 product, in dit geval 1 programma voor in het flash geheugen.

Om te compileren dien je overigens het/een project-bestand te openen en klik je simpelweg binnen Atmel Studio op 'build'. Dan wordt er een nieuw .hex bestand aangemaakt en worden wijzigingen in source daarin verwerkt.

Maar ik denk dat je eens moet Googlen naar hetgeen je allemaal wil weten, of waar je tegenaan loopt / gaat lopen. Op internet ligt meer informatie zo voor het oprapen dan wij met zijn allen kunnen typen hier. Zeker m.b.t. dergelijke beginnersvragen (no hard feelings).

Gr. Dave

[Fritsprt]

Hallo Dave,
bedankt voor je snelle reactie. Je uitleg heeft me in ieder geval weer op weg geholpen. Ik ga het gewoon proberen. Ik vermoedde al dat ik iets met dat main.c bestand moest omdat ik daar ook de include functies zag staan.
De reden dat ik het hier vroeg was juist omdat ik het op internet niet kon vinden. Alle manuals en tutorials gaan over enkelvoudige programma's.
Bedankt tot zover.

gr. Frits

[Bart Sanders]

Beste Frits,

Ik vermoedde al dat ik iets met dat main.c bestand moest omdat ik daar ook de include functies zag staan.

De software tools van Atmel doen precies hetzelfde als bijv. de Microsoft C-compiler. Uiteindelijk ontstaat er een hex-file die je in de micro kunt zetten. Men noemt deze laatse stap het maken van de executable uit de zgn. object-module(s). Het woord zegt het al, datgene dat werkelijk de logica van de software gaat uitvoeren.

Software maken kan grof opgedeeld worden op twee manieren, daarna de voor- en nadelen:

A. Je stopt de main() functies en alle aan main() ondergeschikte functies in één tekstbestand. Daarbij dan meestal een aantal include (*.h)  files. Maar, zelfs die kun je in dat ene, grote tekstbestand zetten. Laten we zeggen big.c.
Dan ga je big.c compileren en de Atmel tools maken daar uiteindelijk een hex-file van.

B. Je verdeelt big.c in een aantal tekstbestanden die elk een bij elkaar horend aantal functies bevatten. Voorbeeld: in mijn software voor de PC-XT besturing van een analoge baan, zijn alle functies die "iets" met de wissels doen in een bestand wissel.c gestopt. Alles dat op laagste nivo met de besturingshardware "praat" zit in een ander bestand port.c en zo voorts. De hogere en hoogste functies zitten dan nog steeds in aparte bestanden en de main.c doet dan niets anders meer dan het op de juiste manier achter elkaar aanroepen van de benodigde hoogste nivo functies.

Op compiler nivo is er een verschil: A. betekent één object-module en de zgn. "link" stap is eenvoudig want alleen dit object-module wordt naar hex vertaald.

B. betekent evenveel object-modules als er tekstbestanden zijn. De linker moet dit verteld worden en die koppelt dan alles aan elkaar om er daarna hex van te maken.

Discussie: A. is gemakkelijker als je iets aan het testen bent.

B. is zeer aan te bevelen als het software project ingewikkeld wordt. Je ziet al aan mijn beschrijving dat er hoe hoger je komt in de complexiteit van de functies, hoe meer details op lager nivo verborgen worden. Dat is alleen maar gemakkelijk: het zou heel vervelend worden als je in een hogere functie die bepaalt of een blok bezet is of niet, nog steeds moet programmeren in de bitjes en bytes die daar in de hardware bij worden gebruikt.

Dit proces van "abstraheren" ondersteunt dat je op de hogere nivo's je helemaal op de logica kunt concentreren en niet wordt afgeleid door allerlei laag nivo details.

En nóg een heel belangrijk voordeel van B.: als je elke functie, ook op het laagste nivo goed hebt getest, dan weet je zeker dat áls er problemen zijn, die in de hogere of het hoogste nivo zitten. M.a.w. in je algorithme en zeer waarschijnlijk niet in de - op zich belangrijke - details op hardware of tussennivo's.

Geloof me, als je meer doet dan wat testjes, dan wordt een lap tekst met alles daar in al vlot onoverzichtelijk. De een kan dat beter dan de ander, maar vanaf een bepaald aantal regels code wordt het voor jezelf - de schrijver van de software dus! - altijd een warboel van tekst.

En dan helpt het ook om een C-leerboek te gaan lezen waarin met name over gestructureerd programmeren wordt geschreven......   

Groet en laat eens weten hoe het gaat!

Bart

[Fritsprt]

Hallo Bart,

Bedankt voor je heldere uitleg. Je verwijst naar jouw programma voor de PC-XT. Heb je daar ergens een draadje van of een website over? Mijn (beperkte) kennis van programmeren in C heb ik van internet en uit twee boeken. AVR, hardware en C-programmering in de praktijk (Elektor) en Embedded C programming and the Atmel AVR. Dit laatste boek heeft wel een hoofdstuk over projects. Het nadeel is dat dit boek werkt met CodeVision AVR C Compiler terwijl ik met Atmel Studio werk. Als je nog een tip hebt voor een goed boek dan hoor ik het graag. Voorlopig kan ik echter wel weer vooruit met jullie tips en zal binnenkort de theorie in de praktijk proberen.
Bedankt tot zover.

gr. Frits

[De Stoker]

Ik lees mee in dit draadje, ik heb al enig ervaring met het programeren van uC van microchip maar krijg het nog niet voor elkaar de dcc er in te krijgen, of te wel het compatible te maken met mijn baan. (laatste maanden ook geen tijd in kunnen steken). Ben wel benieuwd naar je ontwikkelingen vandaar

[Fritsprt]

Hallo Gerwin,

Wil je zelf een C-programma maken of de Opendcc sourcecode aanpassen zodat je die in een PIC kunt schrijven? Dan is mijn vraag waarom wil je persé een PIC gebruiken? Indien je een PIC wil gebruiken dan kan je ook kiezen voor bestaande programma's. Een groot aantal staat bijv. op deze site: http://www.digital-bahn.de/eigenbau.htm

succes Frits

[De Stoker]

Hallo Frits,

De keus voor PIC is des tijds gemaakt omdat ik een mooie online cursus heb gedaan en daar ook de materialen (programeer spullen ed) voor heb aangeschaft. Ook heb ik een redelijk inzicht in de basis van basic (lijkt niet echt op C) aanvullend heb ik voor PIC ook verdiept in programeertaal van microchip zelf. Vandaar de keus voor PIC.

De website is mij wel bekend ik heb daar al wel wat aan voorbeelden weg gehaald maar dan blijkt toch dat ik alleen basis kennis heb. Het is voor mij nog niet concreet genoeg.
Het basis verhaal is mij duidelijk maar hoe ik het daadwerkelijk moet "schrijven" daar blijf ik steken.

Er moet een DCC stuk inkomen die canstant kijkt of er berichten zijn bestemd voor die PIC, en dan vervolgens aan de hand van die signalen de bewuste taken uitvoert (wat het ook mag wezen)
Het tweede deel lukt me wel LED, lampjes , relais, geluid, PWM, servo. maar het eerste stuk, het ontvangst gedeelte dus het monitoren van het DCC signaal en hoe je die signalen (codes) omzet naar de rest van het programma.
Ook heb ik het een beetje aan de kant gelegd omdat ik met de digitalisering van mijn baan bezig ben en dit later wel weer komt.
Mijn PIC link


Maar dit even ter zijde

[Automatic-rock]

Het constant kijken of er berichten zijn voor de PIC lijkt mij een typische interrupt taak
Maak ik ben er ook nog nooit aan toegekomen om een PIC met DCC te laten werken. Staat wel op mijn lijst om binnenkort eens mee te gaan spelen.

Vriendelijke groet,
Benno

[memen]

Misschien heb je hier wat aan:

Draadje op het forum van microchip:
http://www.microchip.com/forums/m297562.aspx
Het bestand wat in het draadje genoemd wordt (hier kun zien hoe je het dcc signaal zou kunnen analyseren.
http://www.microchip.com/forums/download.axd?file=0;627158

Volgens mij als je een iets grotere PIC neemt, met de CAN interface aan boord, kun je met die interface de data van het spoor lezen en hoef je dus niet continu te kijken of het spoor hoog of laag is. Die interface analyseert en zodra hij een hele byte heeft gevonden krijgt je PIC een interrupt.

Groeten,

Rauke

[gvandersel]

DCC lezen is vrij eenvoudig met twee interrupts:
- ingang (laaggaand) deze start een timer welke na 75 usec afloopt
- timer leest de ingang is deze hoog dan was het bit 0 is deze laag dan was het bit 1.
Schuif de gevonden waarde in een schuifregister en check dit tegen het protocol
Eerst 12 enen en dan de boodschap in bytes.
Dit geeft de minste overhead.

Groet,

Gerard van der Sel.

[Automatic-rock]

Op hoeveel Mhz draait een microcontroller van bijvoorbeeld een Lopi4 eigenlijk?

[Bart Sanders]

Hallo Frits,

Je verwijst naar jouw programma voor de PC-XT. Heb je daar ergens een draadje van

Ja hoor, in deze groep (electronica en analoog) en dan even zoeken naar MS-DOS, dan krijg je alle berichten rond mijn treinproject.

Overigens zitten we op dezelfde airwave, ik ga een AVR gebruiken voor de besturing van een oude FLM draaischijf, de 1780. Mooi oud spul en uitstekend geschikt om er - zonder de zaag er in te zeten - een microcontroller bestuurd geheel van te maken. Ook een draadje van, zoek op 1780 geloof ik.

Groet!

Bart

P.S.: er zijn tonnen aan goede boeken geschreven in gestructureerd programmeren - ook voor C - en in elk geval adviseer ik je het "bijbeltje" voor C-programming van Kernighan and Ritchie. Beiden van Bell Labs en de makers van C. Het allerhandigste handboekje voor C-programming dat ik ken. En exact.

[Automatic-rock]

Bedankt voor de tip van dat boekje! Die kende ik nog niet.
Ik heb gegoogled op "Kernighan and Ritchie" en ik kwam een pdf versie tegen.
Ik vraag me af of dat legaal is, maar het geeft wel gelegenheid om het vast door te neuzen 

Vriendelijke groet,
Benno

[Fritsprt]

Bart, bedankt voor je tip.  Heb het boek ook als pdf gedownload.
Nu maar weer lezen en experimenteren.