C30 compiler

Discussies en opmerkingen over het Explorer-16 project

Postby harm_hop » Thu May 31, 2007 12:00 am

Lijkt me best interessant, jammer dat het de F en niet de H versie is, dat is een stap vooruit, anders is het verschil met bestaande controllers wellicht marginaal.
De F versie kost 100 pens minder dan 7 dollar bij DigiKey per 25 stuks, dus dat is te doen. Vooral als Elektuur los zo'n leuk verloopprintje levert waardoor je hem vanuit gaatjesboard kunt aansturen.

Georienteerd bij de site van microchip. Dat valt tegen.
De compiler werkt 60 dagen goed, daarna low level prutscompiler, waar je niks van kunt verwachten.

Hij kost ruim 600 dollar dus ga maar recht zitten, en reken maar na wat je dat gaat kosten met shipping costs, , minimum orderkosten, invoerrechten, btw etc etc. Er zit een assembler en een linker bij. Die kun je niet los kopen.

Bekijk je de mogelijkheid om in circuit te programmeren dan is dat uiterst summier omschreven, er zijn 5 inputs nodig + grd, data, klok en een programming voltage. Dat staat in de ruim 200 pagina spec sheet. Daar kan ik geen kaas van maken.

Wil je dus zelf aan de gang met die chip, dan zit je met handen en voeten aan de ontwikkelomgeving vast van microchip met hun compiler.

Ik wil graag in assembler werken, dat schijnt dan flink achterlijk te zijn, maar als het zo is dat je met een 8 bitter in assembler meer performance krijgt dan een 16 bitter met een C compiler en een gigantisch geheugen levert, dan pas ik daar voor.


Harm_Hop
harm_hop
 
Posts: 60
Joined: Thu Jan 02, 2014 3:27 pm

Postby luc21 » Thu May 31, 2007 12:00 am

Harm,

De optimalisatie van de compiler wordt na 60 dagen minder, voor de rest blijft ie gewoon werken. Niet ideaal natuurlijk, maar zeker geen 'low level prutscompiler'.
Wat jouw berekening betreft: wacht even op onze februari-editie, misschien dank je er dan anders over...
Assembler en linker zitten al sinds jaar en dag bij MPLAB, dat je gratis kunt downloaden van de site van Microchip.
luc21
 
Posts: 56
Joined: Thu Jan 02, 2014 10:40 am

Postby Guest » Thu May 31, 2007 12:00 am

ook nog maar even in te haken.

een programma geschreven in C kan bijna net zo snel zijn als een programma geschreven in Assembler

en die optimalizator is nou ook niet het meest spannende stukje programma werk van MC hoor

wat ze doen met de optimailisatie is dit:

je schrijft een programma en je laat het 'builden'door mplab die doet alles wat niet in de hoofdroutine hoeft te staan verplaatsen naar een subroutine die wordt aangeroepen door de hoofdroutine of door een andere subroutine.

let op C is een krachtige taal en met goed programmeer werk kun je een programma sneller laten werken dan een assemblerprogsel wat bagger geschreven is.

voorbeeldje.

ik heb een programma dat er voor zorgt dat een bepaalde pin continu moet knipperen behalve op het moment dat er een bepaalde pin hoog moet.
je kan dan elke keer die pin controleren je kan ook een intterupt laten genereren als de pin hoog wordt je kan dan in de code zo schrijven als de pin hoog wordt het progje uit de hoofdloop spring en naar een subroutine gaat en dat afmaakt en vervolgens weer terug naar de main gaat.

ik geef toe het voorbeeldje hierboven is een beetje bagger ik zal binnenkort even een Basicprogsel hier neerknallen waarbij ik laat zien wat ik bedoel.
Guest
 

Postby harm_hop » Thu May 31, 2007 12:00 am

Timmiee

Ja, OK, ik ben benieuwd naar je programma, vooral in de wetenschap dat de C -compiler eerst de zaak omzet in assembler, en daar vervolgens pas de object van maakt.
Het lijkt me trouwens sterk dat een ervaren assemblerprogrammeur overtroffen wordt, en voor hobby maakt het niet uit dat je productie dan lager is, dat laatste valt trouwens erg mee als je bekijkt dat je veel code "re-usable" kunt schrijven. Ik denk dat de compactheid en snelheid die je met assembler kunt bereiken niet overtroffen kan worden. Dat is principieel, omdat de C compiler ook de broncode omzet in assembler en nooit met alle optimalisatiemogelijkheden rekening kan houden in de algoritmen.

Goed, voor commerciele doeleinden ben ik het direct met je eens, dezelfde broncode kan voor meerdere merken/typen processors worden gebruikt, is dus inm hoge mate portable, en een paar chips geheugen erbij wegen niet op tegen de extra arbeidsuren qua loonkosten voor kleinschalige toepassingen.

Ik heb wel wat kritiek, maar ik doe sowieso mee met het project Explorer-16 van Elektuur, want ik steun dat graag, ik vind dat ze verdraaid goed werk doen daar en ik kijk wel wat ik er wel mee kan wat met een 8-bitter krapaan of net niet meer lukt.

Vooral lijkt me moeilijk voor de redactie bij keuze van onderwerpen om iedereen tevreden te stellen, er zijn lieden die overal een printje van willen en het liefst kerstballen en stoomfluiten gepubliceerd zien, dus om voor dit soort prokjecten net als die fpga je nek uit te steken dat dwingt mijn respect af.

Dat geldt overigens niet voor die fraismachine, daar hebben ze zelf geen werk aan en die claimt een resolutie van 25 micrometer, dat zal best kunnen maar er wordt niets gezegd over de reproduceerbaarheid als je met de kop een stuk wegloopt en weer terugkomt. Die Ferm hobbydremel die erin zit is ook een uitgesproken B-merk, waarvan de radiale speling op de as het apparaat daarmee al tot de B(agger)-klasse veroordeelt. Daar zou ik dus zeker niet aan meedoen.

Groet en bedankt voor jullie antwoord

Harm_Hop
harm_hop
 
Posts: 60
Joined: Thu Jan 02, 2014 3:27 pm

Postby Guest » Thu May 31, 2007 12:00 am

ik ben het met je eens dat een ervaren ASM programmeur niet of nauwelijks kan worden overtroffen.

het feit blijft dat C een snellere manier van programmeren is dat ben ik met je eens dat de code voor de meeste programmeurs makkelijker te begrijpen is en universeler is dat geef ik ook toe.

het feit blijft dat als je goed kan programmeren dat je de optimalisatie nauwelijks nodig heeft de ASM file blijft groter dan dat je de source gelijk in ASM schrijft.

dat wil niet zeggen dat je programma niet net zo snel kan werken.
als jij zorgt voor een mainroutine die steeds controleert op veranderingen en bij een verandering naar een subroutine gaat dan kan jou programma net zo snel werken.

dat jij wat meer programmeer ruimte nodig hebt wil niet altijd zeggen dat jou programma slechter is dan dat programma dat minder geheugen nodig heeft.

[voorbeeldje(even heel snel in elkaar geflanst)]

;mainroutine
while 1=1
if pinb.2 =1 then
goto sub1 else
if pinb.3 = 1 then
goto sub2
endif
wend.

sub1:
Hserout "pinb.1 is aan"
return

sub2:
Hserout "pinb.2 is aan"

end
[/voorbeeld]
het is een beetje slecht voorbeeld maar het geeft je een idee van hoe ik heb bedoel zodra ik weer thuis ben en de pc tot mijn beschikking heb dan zal ik een goed voorbeeld opzoeken.
Guest
 

Postby harm_hop » Thu May 31, 2007 12:00 am

Timmiee

Bedankt voor het antwoord.
Dat voorbeeld dat u geeft is zonder probleem optimaal in assembly te schrijven. De C compiler zal er ook geen moeite voor hoeven doen vermoed ik.

Dat je met assembler een betere optimalisatie kunt bereiken kan ik wel een voorbeeld van geven: Stel dat je een rij inputgetallen (data input)hebt en die moet je vermenigvuldigen in C met 24, dan zal C naar ik aanneem een general purpose multiplication routine aanroepen met twee parms, namelijk 24 en de input. Kan best dat die routine op zichzelf optimaal is, maar dat kan hij niet voor elke multiplier zijn. Die multiplier is hier fixed 24, dat herkent de assemblerprogrammeur als zijnde 16 plus 8, die zal dus het inputgetal drie bits naar links schuiven (asl), copieren naar een register, nog een positie naar links schuiven en dan het register optellen bij de accumulator. Eventueel een swap nibbles in plaats van 4 pos naar links.
Het lijkt me sterk dat als je de geoptimaliseerde C-output in assembler gaat bekijken dat die dat doet. De optimalisatiemogelijkheden zijn namelijk voor elke multiplier anders.

Nu is dit ook weer geen goed voorbeeld want onderhavige chip heeft single cycle 16 bit hardware multiplication aan boord, maar het adstrueert wel mijn twijfels over optimalisatie door compilers.

Nu is het vaak zo dat het gros van de programmatuur niet snel hoeft, alleen bepaalde tijdkritische stukken. Men laat dan een profiler meelopen die aangeeft waar de trage delen zitten, en die kun je dan uit de C compiler in assembler bekijken en optimaliseren met de hand. Wel oppassen dat de procedure die je aanhoudt zo is dat je niet bij elke wijziging elders in je programma en hercompilatie dat moet herhalen uiteraard.

Je kunt ook op een andere wijze vastlopen, als een C compiler zelf timers kan toewijzen en interruptroutines daarvoor kun je timers of interrupts tekort komen, terwijl je in de assembly praktijk vaak een timer voor meerdere doeleinden gecombineerd kunt gebruiken.

Profilers kosten ook weer voor een hobbyist onverantwoordelijk veel, ik los zoiets doorgaans op door een paar instructies op te nemen die een uitgangspen hoog en weer laag maken aan het begin en einde van een stukje code of een interruptroutine, dan kan ik als de zaak draait met de scope op die uitgangspen zien hoe lang het programma erover doet.

Enfin, we zien verder wel.

Hartelijk dank voor het antwoord van hr llemmens en u en vriendelijke groet

Harm_Hop
harm_hop
 
Posts: 60
Joined: Thu Jan 02, 2014 3:27 pm

Postby Guest » Thu May 31, 2007 12:00 am

ik weet wel dat ASM in de praktijk de voorkeur heeft als het om tijdskritische delen gaat maar de meeste c(r)ompilers hebben wel een inline-assembler mogelijkheid dus kan je tijdsgevoelige onderdelen in ASM doen wanneer dit nodig mocht zijn.

maar Basic en C hebben de voorkeur asl het gaat om eenvoud en snel programmeren. daarbij komt de programma's in basic en C meestal universeler zijn.

ik gaf zelf al aaan het is een slecht voorbeeld.

hogere programmeertalen zijn nu eenmaaal makkelijker om mee te programmeren de meeste functie's is el een code voor

een lcd aansturen in ASM moet je alle pinnen van de lcd hoog en laag maken in je programma.
in basic gaat dit zo: print "text" of als je op een bepaald wilt beginnen: print 2,1 "text"(hij zal nu op de 2e regel gaan typen.

verder heeft iedereen een voorkeur voor een Taal en als ik een beetje goed kan gokken ga jij voor assembler.
ik ben een van de mensen die de ballen niet snapt van asm en dus om die reden van Basic houd. dit neemt niet weg dat ik weet dat ASM belangrijk is om te kennen als je bijvoorbeeld hele snelle communicatie nodig hebt dan kan Basic nog weleens te kort schieten omdat het programma te langzaam is.

wat is een profiler?(moet ik dat vergelijken met een ICD[in circuit debugger])
Guest
 

Postby harm_hop » Thu May 31, 2007 12:00 am

Ik heb een "programma" gemaakt in C en dat luidt:
int main()
{
while(1);
}

In assembler is dat ongeveer evenkort, namelijk
main sjmp main

Project wizard gebruikt, die blijkt lang niet volledig want de build wijst erop dat er geen linker script is, na wat gezoek dat erbij gezet. Had die wizard kunnen weten want je moet als eerste het chiptypenummer opgeven.

Als je dan zo'n file opzoekt met suffix gld, dan is er een drukknop ÓPEN'. Wil ik helemaal niet ik wil hem in het project window ertussen hebben. Slepen gaat niet. Ja dan moet je op open drukken, dan opent hij niet maar wordt in het projectwindow gezet.

Je lacht je kapot, hij maakt een hex file van 4 kilobyte.
Dat is in principe dus ruwweg 2 kilobyte code.

Ja, en vervolgens geprobeerd met #include stdio.h en #include stdlib.h en dan
int main()
{
printf("Hallo wereld");
}

Dat kost je in assembler ook amper niks.
Met de stringroutine mee 30 bytes schat ik.

Raad eens: Hex file van 42 kilobyte.
Die vergelijking is overigens niet geheel eerlijk want om een LCD aan te sturen of een UART heb je ook pakweg 100 bytes nodig.
Het is me wat met C gaat geen zee te hoog, dat is duidelijk.
harm_hop
 
Posts: 60
Joined: Thu Jan 02, 2014 3:27 pm

Postby luc21 » Thu May 31, 2007 12:00 am

Harm,

Welke libraries heb je allemaal gelinkt? Dat vreet geheugen inderdaad, maar waar maak je je druk over als het toch in het geheugen past? Niemand houdt je overigens tegen om in assembler te blijven werken, veel succes! Ik ben benieuwd wanneer jij hier een versie van de sprekende thermometer in assembler presenteert. Niet stiekem de code uit C disassembleren he!
luc21
 
Posts: 56
Joined: Thu Jan 02, 2014 10:40 am

Postby harm_hop » Thu May 31, 2007 12:00 am

Ja, een sprekende thermometer is geen probleem. Ik heb hier met een atmel 89s8252 een sprekende DCF77 klok die ook de datum en het jaar en de maand kan zeggen. Een ander model bevat verjaardagen en huwelijksfeesten van de familie compleet met leeftijd, ze worden pas geschrapt als ze de 100 passeren.... De chipcorder IPS2560 , 28 pens DIL chip, die eraan hangt kun je met woorden vullen (via je geluidskaart) die per stuk adresseerbaar zijn. Neemt een minuut tekst op. Neem je veertig als woord, dan kun je het adres op veertig zetten maar ook op tig. Dat is handig voor vijftig t/m negentig, omdat vijf t/m negen er uiteraard ook inzitten. Hij telt je dus de oren van de kop als ik een telroutine in de 8252 zet. (zit er als test in).

Het is begonnen met een leerklok voor een kleuter, "zijn naam"Kijk op de klok, het is nu ... Instelbaar met een 4DILswitch op hele uren halve uren erbij, kwartieren erbij, en de vierde stap vijf en tien voor en over (half). De volgende instellingen tot 15 geven dan digitale tijd (drieentwintig uur en vijftien minuten), dag datum en jaar vol uitgesproken etc. Een LDR zorgt ervoor dat de klok zwijgt als het donker is.

Ga je echter met adaptive differential PCM aan de gang dan reduceer je een 16 bits monster (nergens voor nodig bij spraak) tot 8 bits. Heb je dus 8 kilobyte per seconde nodig oftewel 480 kilobyte per minuut. Dat is met een kanon op een mug schieten.

Harm
harm_hop
 
Posts: 60
Joined: Thu Jan 02, 2014 3:27 pm


Return to 2007-01 t/m 04 Explorer-16

Who is online

Users browsing this forum: No registered users and 2 guests