Svenska ElektronikForumet

Jo, jag håller på att byta språk! (Hör några ropa "Äntligen!")

Jag kommer åtminstone köra med assembler till mina större projekt. Det var detta problem som gav mig tillräckligt med motivation att börja lära mig asm ordentligt.

Visst, det går att göra det mesta i MikroBasic, men i större koder (mina brukar vara runt 400-700 rader) så blir det tillslut så mycket specialknep att det blir skumma bieffekter. Önskar att det inte var så, men tyvärr...


De största fördelarna som jag ser med språkbytet:
*Man får bättre koll på vad som *egentligen* händer.
*Kraftfullare.
*MPLAB-IDE är gratis!
*Sparar minne på PIC-kretsen. (Ska jämföra ordentligt sedan.)

Sedan är det en intressant utmaning att byta språk.
När jag kört med MikroBasic så har jag i princip aldrig använt de inbygda rutinerna, så jag har ändå kunnat lära mig ordentligt hur en PIC fungerar. Det finns ju de här som säger att man måste lära sig assembler för att förstå det, men då jämför man nog med om man bara skulle ha använt MikroBasic's egna rutiner. Annars är det ju ett krav att kunna PIC'en ordentligt för att göra lite mer avancerade grejjer. Det märks tydligt nu att jag får mycket "gratis" iochmed sättet jag programmerat MikroBasic. Det jag däremot måste lära mig ordentligt är asm-instruktionerna.
Tillbaka till databladet alltså.


Till slut några ord till mina MikroBasic-vänner:
Jag kommer inte sluta med MikroBasic totalt. Det är ett för roligt språk för att jag ska kunna låta bli. Har man programmerat Basic i ca 19 år så går det ju inte att överge det!

ahhhhhhg, blir det bara jag kvar som kör basic?

Kan det kanske finnas en anledning till att ingen annan kör detta "språk"????

Styrprogrammet jag har utvecklat till en pelletsbrännare har ca: 7K+ rader, det är C och det fungerar alldeles utmärkt, det finns tusen++ i olika svenska hem.

Det är inte för att det är C att det är "enkelt" att ändra det, det är mest för att jag håller an hård struktur och tydliga namn på funktioner.

I mitt tycke är det löjligt att köra med icke-engelska namn på funktioner, man kan ju inte använda ä, ö eller å ändå så lcd_vanta (har LCD vantar?) ville jag konsekvent kalla LCD_Wait osv.

*ler*

Vi blir alla klokare.... Hade kompilatorerna varit bättre så är det ju väldigt skönt att kunna använda C, pascal, delphi eller basic för att det går ju fortare att skriva program och de blir mer lättlästa, men när man ändå fyller halva programmet med inline-asm så känns det som att det är lika lätt att skriva allt i asm.

Skall ge mig på PIC18 vad det lider (har jag sagt i ett år...) och då får det banne mig bli C...

Äntligen!
Istället för att köra asm för stora projekt och basic för små skulle jag
istället rekommendera att använda asm till små projekt. Till stora projekt
använder man med fördel c eller c som gluelogic och asm-moduler för
standardgrejer som t.ex. lcd-rutiner. Lite beroende på vilken mcu man
använder och vilka prestandakrav som finns. Jag tror inte att du har något
att förlora på att överge basic helt och hållet.

Hmm, Basic, det var länge sedan... . Vad jag minns från ABC80, Ti-99 och C64 var det väl mest peek och poke för att få upp maskinkoden i minnet, ett j-a peekande och pokande.

En fördel med C som ingen nämnt är att mha bra struktur så går det att byta hw-implementationen mot en implementation i Linux för testkörning.
Detta är mycket bra vid felsökning. Detta blir enklare om man dessutom använder Make, det är bara att skicka med en eller flera flaggor så bygger man för olika cpu:er, miljöer, etc. .

/Ulf

Det allra bästa med MPLAB är att man kan installera MCC18.

Ulf:
Peek och poke var länge sedan. Jag hade ingen C64, men däremot en Vic20 som jag fortfarande har kvar. Egentligen är det konstigt att man (eller iallafall jag) mindes alla nummer. Den enda dokumentation jag hade var den medföljande Basic-boken. Alla poke-adresser fick jag fram genom att lista spel och ändra lite här och var. Sedan köpte jag C64-tidningar och översatte koderna. Det var tider det!

Pheer: Med små projekt tänkte jag inte främst på de koder som måste vara små pga minnet. Snarare tänkte jag på de fall där det går fortare att nå resultatet med MikroBasic. T.ex diverse expriment, lysdiod/fläkt-styrning, mm. Kort sagt: Projekt som inte kräver >400 rader Basickod.
Nu kanske någon invänder med att det kräver mindre kod och går fortare med assembler. Mjo, möjligen, men jag knappar basic lika fort som jag skriver ett inlägg.

Däremot kommer jag fortsätta hålla mig till QBasic när det gäller datorprogram. Körde lite VisualBasic förr, men allt eftersom versionssiffrorna blivit högre och högre så har VB blivit mer likt Pascal. Jag känner knappt igen mig längre.

Det arbetsamma med ett program tyckerjag är att hitta lösningen på uppgiften, inte att krafsa tangenter. När det kommit så långt att det är dags för det så brukar kodningen gå väldigt snabbt och lätt. Det går fint att skriva stora program i asm, bara det är välplanerat och man håller struktur på det. Samt framför allt kommenterar. Kommentera även det som känns självklart idag, om ett halvår är det inte självklart längre.

Det är inte självklart ens när man kommit till slutet av programmet... ASM måste måste måste kommenteras - gammal kod blir totalt oanvändbar annars.

Håller med om med noggranna förberedelser så går det rätt fort att skriva assambler även om man inte kan alla finesser och gör allt så snyggt som det går. Är det välkommenterat så kan man snygga koden i efterhand om det finns någon mening med det..

Jag kan bara instämma helt med Marta: det knöliga är inte själva skrivande av programinstruktioner, det är att klura ut lösningen först. Efter den är klar är resten rent slitgöra.

bengt-re: det är väl inte bara ASM-kod som ska kommenteras? Det ska väl ALL kod eller hur? Visst kan man med rätt moduluppbyggnjng skära ner kommenteringen till att beskriva modulernas funktion men den måste likaväl finnas.

grym skrev:ahhhhhhg, blir det bara jag kvar som kör basic?

nää jag ger inte upp.

Jag kör Picbasic / proton dev suite.

Funkar till typ allt.

/Tripp

Håll isär kodning och programering (SW-Design)!

Och visst gör vi väl alla fina systemeringar så vi tillslut får ett rejält förråd med lib som vi kan återanvända... ?!

Gången borde väl egentligen vara som följer:
1 Analys och systemering
2 Välja programspråk
3 Strukturera med enbart kommentarer
4 Koda
5 Kompilera

men oftast blir det bara 12345 på en gång, eller?

Programspråk kan ju vara självdokumenterande i olika grad,
asm kräver som regel en hel del kommentarer utöver själva koden medans tex C kan vara i stort sett dess motsats, om variabel-, funktions-namn etc väljs med omsorg.

Icecap: Visst ska man kommentera ordentligt! En annan kommer inte ihåg det som jag kodade igår!

Nu är det många år sedan jag pillade med asm, det jag kommer ihåg att jag hade problem med var generalisering av funktioner.

typedef void* var mypek; är ju rätt trevligt egentligen!

/Ulf

"typedef void* var mypek; är ju rätt trevligt egentligen!"

Möjligen i C, men inte i assembler...

Skulle nog kunna påstå att en välskriven c-kompilator kan generera lika bra kod som assembler, men om inte så nära nog. Tänk på all tid man sparar och bättre överskådlighet. Jag vet att många säger ush c är helt obegripligt. Nej det är det inte. Alla språk jag jobbat med har haft en viss inlärningströskel som man måste komma över bara.

Styrkan hos c för microprossesorer är pekare och jag hatar dem fortfarande men f-n så användbara.

Själv använder jag CC5X från www.bknd.com det finns en gratisversion, begränsad givetvis, som talar vänlig om för dig om du köpt full versionen hade koden blivit 4% mindre. Villigt måste jag erkänna att jag inte provat något annat språk för PIC än JAL, det var där det började.