Svenska ElektronikForumet

Det här har inget med val av språk att göra.

Det gäller anpassning av applikationslogik till den plattform man kör på.
På "stora" datorer spelar det inte lika stor roll, rå-prestanda döljer
ofullkomligheter i applikationen. På mikrokontrollers kan man kanske
programmera på samma sätt, så länge som man inte vill/måste utnyttja
processorn fullt ut.

Jag menar, det är ju bara att kolla lite bakåt i forumet, det finns massor
av exempel där man har programmerat på med samma stil som på större
system, och (naturligtsvis) kört i diket ganska snabbt...

> Det är väl just det som är det fina i C,...

Det är just det som är nackdelen med C (eller BASIC eller Pascal) när man
ska gå över till att programmera mikrokontrolers. Självklart *går* det att
programmera PIC/AVR i C (t.ex), men inte utan att man vet vad man
håller på med.

> Sodjan är nog inte van det, som bara kör Asm...

Och diverse olika spåk på Windows.
Och Pascal, Fortran och Cobol på PDP11 och VMS minidatorer
Och COBOL, JCL m.m på IBM MVS mainframes.
Och SQL mot bl.a Sybase, Oracle, Rdb och DB2.
Under drygt 25 år nu.

Men, som sagt, det har inget med det här att göra...

Jag kör Borland C Builder 6, Visual Builder och Pascal på min PC och assembler och C på mikroprocessorer och visst är det likheter men definitivt stora skillnader också!

På en PC begär man minne i mängder, man räknar som besatt, det kvittar oftast om man går en massa omvägar för att uppnå en funktion osv.

På en mikroprocessor är jag förvånat över vad man kan åstadkomma med 6kB RAM och 64kB flash, på den pelletsbrännare jag har utvecklat styrningen till finns det 128kB flash men jag använder hälften och då är det lagt in 5 olika språk!

Det är definitivt ganska olika stilar i programmeringen men om något smittar av är det mikroprocessorna som smittar av på PC-programmeringen, jag tar bara vad jag behöver av minne, jag använder heltal om det går osv.

Och ja, jag programmerar även ett antal andra språk!

Vad C har av fördel (jo sodjan, det finns!) har jag nyligen upplevd:
Jag har portat styrningen av pelletsbrännaren så att hårdvaradelarna tas om hand av de dedikerade programfilerna men själva styrningen är samma fil.

Detta betyder att jag kan uppdatera styrningens program och sedan kompilera den dels i HEW (Renesas) och i SofTune (Fujitsu) och få ut "samma" program till 2 olika processorer och bara behöva underhålla ett enda program.

Anledningen till denna dubbelhet är att vi måste ha alternativ och underhålla äldre brännares elektronik.

Mitt i detta har jag dessutom designat programmeringsinterfacen så att den fungerar till båda processortyper och jag håller på att göra ett flashprogram som automatisk väljer rätt processor. Detta betyder att flashningen kan utföras av inte-helt-så-datorkunniga också.

> Och diverse olika spåk på Windows.
> Och Pascal, Fortran och Cobol på PDP11 och VMS minidatorer
> Och COBOL, JCL m.m på IBM MVS mainframes.
> Och SQL mot bl.a Sybase, Oracle, Rdb och DB2.
> Under drygt 25 år nu.
Vad kan detta ha med mikrokontroller att göra? Kodar du SQL för DB2 även på PIC?

Jag har gjort precis som trådförfattaren, skrivit C-kod på PC för senare användning i uC. Det fungerar mycket bra eftersom man självklart är medveten att koden ska köras där sedan. Det förutsätter givetvis att man kan hårdvaran, men det är väl knappast orimligt.

Jag tycker du ska sätta dig in i C istället, så ser du själv hur det funkar. Det framgår ganska tydligt i din kritik att du inte vet mycket om saken.

Det är inte heller så svart och vitt att alla mickroprocessorer alltid per default måste pressas till max, lika lite som att man alltid kan slösa med kraft hursomhelst i en PC.

> Alltså, en enskild funktion (t.ex writeDisplay) är ingen "applikation".

Öh, du menade väl tvärtom, funktionen writeDisplay ingår i det API som applikationen använder.

Nä, som sodjan skriver, det har inget med språket att göra, dock har C en styrka med sina define. Tillsamans med make så faller det mig på läppen.

MEN, ska man utnyttja processorn till bristningsgränsen, hela tiden, då är asm ofta ett måste, eller en extremt bra kompilator (kompilatorerna är rätt hyfsade idag och blir bättre).

De applikationer som skrivs av oss hobbyfolk vågar jag nästan påstå mycket sällan utnyttjar så mycket, händer det så är det oftast av andra orsaker som den blivit underdimensionerad (kanske den berömda snålheten som bedrar...).

> men inte utan att man vet vad man håller på med.
Det gör det aldrig... .

Applikationen ser jag som det övre lagret, inte implementationen mot hårdvaran (api).

Det är ohyfs att allokera minne utan stor eftertanke oavsett om det är på en uC eller på BamseDatorn Jätte. All minnesanvändning ska övervägas noga, oavsett vilket språk man använder.

> Det framgår ganska tydligt i din kritik att du inte vet mycket om saken.

Vilken "sak" ?
Jag vidhåller att hela frågan inte har något med något specifikt språk att göra,
utan precis det du säger, att man måste/bör veta var koden ska köras.
Det låter på dig som om jag kritiserar C generellt, vilket är fel.

Jag glömde förresten naturligtsvis C i listan, men skit samma...

Kritiken gäller lika väl för de som säger att de kan Visual-Basic så de
kommer inte att ha några problem alls med PICBasic (t.ex)...

> skrivit C-kod på PC för senare användning i uC.

Självklart går det, med en lämplig definition på "kod".
Att testa lite parametrar till sprintf() är en sak,
men tråden handlar om applikationer.
Och det jag talar om är övergripande design på applikationen, vilket
kan skillja ganska mycket. Hur många har skrivit interrupt-driva
C applikationer på t.ex en PC eller under Linux ?

> > Alltså, en enskild funktion (t.ex writeDisplay) är ingen "applikation".
>
> Öh, du menade väl tvärtom, funktionen writeDisplay ingår i det API
> som applikationen använder.

Nej, jag menade exakt det jag skrev.

Du nämnde LCD rutiner som exempel på sådant som kan vara plattformsspecifikt
(och "osynligt" från applikationen). Visst, men det är inte det som är frågan
här, utan det faktum att applikation *i sig* kan vara svår att göra plattformsoberoende.
Det var så jag tolkade dig i början av tråden.

> Hur många har skrivit interrupt-driva C applikationer på t.ex en PC eller under Linux ?
*Räcker upp handen*!
Fast det var ju mer device drivers då.

Fast du förstår ändå inte riktigt, man kan ju "simulera" det hela ganska långt. Hört talas om "signals" i POSIX? De flesta IO-anrop går att få asynkrona.

Jag talar givetvis inte om en "blink-a-led"-applikation, utan mer komplexa rutiner som med fördel provas ut i PC-miljö i första hand. Beräkningsalgoritmer förslagsvis.
Men även seriellt gränssnitt går bra att simulera genom signaler.

B.t.w. "PC eller under Linux" - Utesluter det ena, det andra?

OK, då är vi överens.

Beräkningsrutiner är enkla (inga I/O) och seriella rutiner är också rellativt enkelt att testa/simulera på valfri plattform.

Och ingen av dom har speciellt mycket med den övergripande applikationsdesignen att göra, vilket
var vad jag trodde att tråden handlade om.

Då kan vi stänga här...

> Nej, jag menade exakt det jag skrev.
Tolkade dej fel, Sodjan, writeDisplay funktionen tillhör helt riktigt inte applikationen.

> Hur många har skrivit interrupt-driva C applikationer på t.ex en PC eller under Linux ?

Jo, det har jag pysslat med i några år, samt till andra OS och hårdvara.
Här är det användbart med callbacks via API:t mot applikationen.

> utan det faktum att applikation *i sig* kan vara svår att göra plattformsoberoende.

Behöver inte alls vara det med rätt abstraktionsnivå vid är systemeringen, implementationen av varje funktion efter specifikation från systemeringen är programeringen, att få det på fil är ju bara kodknackande. En generell och bra implementation av ett api mot hårdvara är inte alltid lätt.


BTW, jag är inte trådförfattere, vi har väl kommit en heldel OT!

Men, visst är det härligt med en liten diskussion i design och programerings filosofi, eller?

sodjan: vilken debugger är det du syftar på för hundralappar?

PICkit2.
Sen har naturligtsvis "hundralappar" samma precision som "tusenlappar"...

Vad är det som skiljer det från ICD2
EDIT: mer än priset.

Enklare design.
Support för färre olika processorer.
Sannolikt inte lika "heavy duty".
Lite mer hobbybetonad.
Kolla själv...

Tack för snabb svaret.