Svenska ElektronikForumet

Jag såg ett bra svar på den här frågan i en annan(identisk) tråd. Jag tror att det varsodjansom var författaren.

Frågan: Vad ska jag välja, PIC eller AVR?

Svaret: Det som dina kompisar kör.

Det känns som det bästa svaret. Uppenbarligen klarar båda familjerna av att göra i stort sett vad som önskas, men om du inte vet vilken du ska välja så är dina kompisar en viktig ingrediens. Det blir ju dom som får hjälpa dig igång, dom som du kommer att fråga när du kör fast. Så välj den processorfamilj som du har störst chans att få hjälp med.

Sedan att ställa den här frågan på forumet kan liknas vid att gå in mitt på plan inför en match mellan AIK och Djurgården och fråga publiken vilket av fotbollslagen som är bäst. Det troliga är att du kommer att bli stenad av båda supporterlagen.

Svaret på som brukar ges på trådens fråga brukar hursomhelst vara bättre än svaren på frågan "windows eler Linux" som kan komma upp i andra forum.

bengt-re: Om du har rätt så kommer jag att få lära mig det den hårda vägen. Kan du komma med fler exempel? Vad kan man inte göra i C? Interrupthantering iofs... Det känns som att det du varnar för är mer användningen av libbar...

JJ skrev:Anväder man C spelar det roll eftersom det mej veterligen inte finns några ANSI-kompatibla kompilatorer för PIC.

Jodå, WIZ-C är i princip ANSI-C (så nära det nu går).

Det finns inga C-kompilatorer överhuvudtaget, som är helt ANSI, oavsett plattform (även x86 osv), alla har sina egenheter.

Bengt-re:
Naturligtvis måste man veta vad man gör, och läsa databladen, oavsett om bygger i C ASM eller nått annat.
Men visst går det mesta att göra i C.
Interrupthantering går aldeles utmärkt, blir lika kompakt som om man gjorde det i ASM.
Serieportar också, både HW och SW, samma gäller I2C osv.
Det enda jag på rak arm kan komma på är väldigt tighta fördröjningar samt NOPar, där får man använda inline eller ren asm i c-koden.

Just C vs ASM har varit uppe på tapeten ett antal gånger på avrfreaks och olika program har skrivna i båda språken har jämförts, resultaten har oftast visat på att C ger lika kompakt och snabb kod som asm om man bara vet vad man gör. Man kan göra dålig kod oavsett språk, och man kan göra bra kod i båda....
Det handlar mest om att förstå processorn och anpassa koden därefter, och just för att få förståelse för uppbyggnaden är ASM såklart bättre då det är "närmre" hårdvaran.

> ELLER VAD TYCKER DU SODJAN

Tja, vad ska man tycka...

Kanske att jag har den största respekt för de som ändå orkar
att försöka ta en sådan här tråd på allvar (en gång till).

Vad tycker du själv, förresten? Om AVR vs. PIC ? Är det något
speciellt som du undrar över ? Något speciellt behov ?

> om inte sodjan lär sig sortera bort sådant han inte vill läsa...

Jag har för över ett år sedan efterlyst en funktion "markera tråd som ointressant"
just för att slippa att sådana här trådar ständigt får ämnen att markeras
som "nya inlägg"...

Jag tycker att *forumet* ska sortera bort sådant som jag har sagt att jag
inte vill läsa. Och oavsett det, så förbehåller jag mig i alla fall rätten
att både läsa och svara på precis vad jag vill.

Och slutligen, när det gäller själva valet AVR vs. PIC, så är det på gränsen
till fullständigt betydelselöst ur *tekniskt* avseende, enligt min mening.
Så länge det gäller vanliga "hobby" behov...

Tack för lite relevantare svar.
/John

Ingen orsak !
Och GOD JUL förresten !!

Säger inte att det inte fungerar med C på små uC, men det befriar INTE användaren ifrån att lära sig sin uC begränsningar och möjligheter. Sen tillför det en del osäkerheter då man inte har koll på exempelvis hur mycket av stacken som utnyttjas och tyvärr hanterar PIC inte stackoverflow på något lysande sätt (fast det gör väl iofs ingen uC ?...).

Självklart fungerar högnivå på uC och jag använder det själv ibland, men det blir ett tomrum ibland mellan eventuell kompilator dokumantation och databladet - så vissa saker GÅR inte att lista ut hur de kommer att lösas av kompilatorn och ibland innebär denna osäkehet svårfunna problem. "Ren" kod brukar fungera bekymmerlöst, men så fort man kommer in på lite mer avancerade funktioner som flyttalsdelar, lookup-tables, lcd-driv funktioner och liknande så ökar risken för "skumma" fel. Och kör man inlineasaambler så är det inte helt enkelt att lista ut vilka register som används till vad och spciellt om man vill ha tillgång till exepelvis flyttalsdelar beräknade i C i den delen av programmet där man tvingas köra asm. Vill man för att "lösa" problemet lägga upp delar i asm som exempelvis en lookuptable så är det inte alla C-komilatorer som stödjer ORG-direkviv i asm-koden och man har inte en aning om var sin tabell hamnar och computed goto i PIC16 kräver att man vet var tabellen hamnar - skall sedan indatat till tabellen komma ifrån en separat fil så är det än mindre självklart hur dessa includes hanteras - visst kan man kompilera och läsa asm-koden, men då känns det nästan som man hellre kan skriva allt i asm ifrån början för då får man välkommenterad asm att rota i istället....

Finns iofs alltid en enkel lösning - kör renesas istället så får du en kraftfullare uC som går bättre med C.... Dessutom rätt billig !

Hmm, då har jag tur, som använder en hyffsat väldokumenterad C-kompilator, som dessutom stöder tabeller i programminne utan några konstigheter.

Dessutom stöder rena assemblerfiler också, som problemfritt länkas in.

Har i princip full kontroll var både lokala och övergripande variabler samt även returvärden och parametrar hamnar, och kan i princip styra om de skall hamna i stack eller nån annanstans.

Men jag håller med dig man MÅSTE kunna hårdvaran fullständigt, på samma sätt som om man skall göra program till windows eller linux måste ha full kännedom om API'na mm.

Vilken kompilator kör du och vilka uC ?

WIZ-C och fn 18F8622 bla. (började med 18F452 en gång i tiden)

Litet tillägg.

Om jag skall göra en lookup-table i C så gör jag så här till exempel i mitt C-program
På samma sätt kan jag skriva kompletta funktioner som assemblermoduler direkt i C-programmet,
under förutsättninga att jag använder mig av de riktlinjer för anrop, retur, minne och stack som anges i manualen vilken är väldigt tydlig.

Lätt som en plätt tycker jag.
[/code]

Bara en lite nyfiken fråga...
Har du några alternativ till "forced absolute" ?
Jag antar att all annan (C) kod allokeras automatiskt.
Kan du inte då tabellen att bli relokerbar ?

Jodå det finns ett antal alternativ, här är hela hjälptexten

MODULE “Name” [def] [Address]

Identifies the start of a module for the linker, if not supplied then the whole file is taken as global. Name is the name of the module supplied in inverted commas and is optional. Name is purely provided for user reference in the listing file and may be duplicated, it has no effect on the link. def is the block definition described below.

ENDMODULE Identifies the end of a module
CBLOCK def
Identifies the start of a RAM module for the linker.
def Defines the MODULE, or RAM block as follows, one or more keywords may be provided on the line

ABSOLUTE keyword which flags that block is fixed in memory.
PAGE keyword which identifies that block should be in a specific page.
GLOBAL keyword to show that all block identifiers are global.
FORCED keyword (for Modules only) to force the linker to include the block, even if it is never referenced.
PREFERRED If this keyword is supplied with PAGE or ABSOLUTE, then it tells the linker to obey the PAGE or ABSOLUTE command if possible, but to locate the block elsewhere if this is not possible. Without this keyword the linker will create an error if it cannot locate the block as requested.

TEMP If this key word is supplied (for RAM modules only) then the RAM area is placed in temporary memory. This temporary memory is located in page 0 – Access RAM for the 18 series.