nån som e haj på PIC o assembler

[TomasL]

Skriva ett C-program för en mikrokontroller är ju i princip samma sak som till en PC, dock är det betydligt enklare att skriva för mikrokontrollern än för PC'n.

ATt det skulle vara svårt eller att man måste ha några förkunskaper är inte sant, går alldeles utmärkt att som nybörjare starta med C på uC, betydligt enklare än med asm.

[labmaster]

Det är mycket brus i teljemos tråd. Inte helt ovanligt att trådar brusar ibland . Nästan alltid skall det tävlas om vem som har mest rätt och inte sällan uppstår en massa principdiskussioner om detaljer.

Saken är den att teljemo är newbee inom hårdvarunära programutveckling och har inte heller någon större kunskap om programspråket C. Det är detta jag har som utgångspunkt när jag skriver i denna tråd.

Härmed vill jag klargöra följande:

• När jag skriver i denna tråd har jag ett enda fokus, nämligen den att dela med mig av mina erfarenheter till TS
• Är inte beredd att bedriva principdiskussioner med någon i denna tråd
• Jag tycker att TomasL hittills har varit en tillgång för TS i hans inlärningsprocess och är övertygad om att det även blir så i fortsättningen
• Ställer jag en eller flera frågor till TS gör jag det för att det finns en anledning
• TS kan använda den hårdvara han redan har med diverse små kompletteringar
• Det finns ingen anledning att TS skall använda någon annan utvecklingsplattform än den han redan har. Exempelvis att istället använda sin PC som "target"
• Vill någon fler haka på tråden med syfte att bygga på kunskap på samma sätt som TS så är det bara att vara med
• Det finns flera som kan vara en tillgång för TS kunskapsprocess men då under förutsättning att TS får pedagogiska förklaringingar utan för många alternativa lösningssätt. Det gäller med andra ord att utgå från att TS är newbee och inte expert med mångårig erferenhet
• Att TS eller övriga som vill vara med och bygga kunskap får möjlighet att tänka själv utan att det presenteras för mycket färdiga kodexempel

Om någon tycker att ovanstående klargörande har hög "dryghetsfaktor" så beror det förmodligen på någon slags kortslutning i hjärnkontoret hos den som gör en sådan värdering. Jag är dock medveten om att denna typ av "rakt på sak" kan vara lite frustrerande men infaller denna känsla så stäng tråden en stund och återkom lite senare.

[TomasL]

He He, nä mitt lilla sidospår var väl egentligen menat som en kommentar till inlägget med fotot på TS länkar till Kjell&Co's PicDem2, vilket jag personligen tycker är lite onödig, med tanke på vad annat man kan få.

[Batman]

OCh PIC32 med en betydligt smartare PMP-port, USB2GO, MII, 32Bitar, DMA osv.
Interna AD är ändå skit, när det gäller upplösning och stabilitet mm.

Ok, får revidera till fortfarande fler fast några bättre och några sämre. PMP har jag inte använt, men den finns för PIC24 också. USB klarar samma sak för PIC24 och PIC32, båda är max full speed, båda klarar host/device och usb otg. Ethernet MAC är en fördel för PIC32. Vad menar du med 32Bitar?
AD är bättre skit på PIC24 i alla fall.
Ville bara visa på att det inte är självklart att PIC32 är bästa valet i alla fall. Jag antar för de fall du jobbar med är PIC32 ett bättre val. Men PIC32 har några svagheter på vissa områden. En annan svaghet är sleepförbrukning,

[TomasL]

Vad menar du med 32Bitar

Att PIC24 är 16 bitar och PIC32 är en 32 bitars processor.
Naturligtvis handlar det alltid om vad man vill uppnå, för egen del använder jag externa omvandlare för att få den precision jag vill ha, 16-bitars PMP använder jag för att prata med Hårddisk/CF och display mm.
Ethernet kör vi iofs via extern kontroller och 40MHz SPI-lina, i övrigt kör vi 2 isolerade RS485, 1 st RS232, 3 ytterligare SPI-linor, två I2C-linor samt några entrådare

[sodjan]

> TS kan använda den hårdvara han redan har...

Visst är det så. Bara att köra på med de "lessons" och det övriga
materialet/dokumentation som finns till PICkit2 Starter Kit.

Resten i tråden är, som du säger, mest brus som bara stör bilden...

Om man inte är intresserad av själva mikrokontrollertekniken utan
bara vill slänga ihop snabba lösningar, så kanske en Arduino är bättre.

[Batman]

Skriva ett C-program för en mikrokontroller är ju i princip samma sak som till en PC, dock är det betydligt enklare att skriva för mikrokontrollern än för PC'n.

ATt det skulle vara svårt eller att man måste ha några förkunskaper är inte sant, går alldeles utmärkt att som nybörjare starta med C på uC, betydligt enklare än med asm.

Det jag har i baktanken är att många nybörjarfrågor jag sett på Microchips forum ofta är rena C frågor som inte har något med PIC att göra. Vissa saker kan vara lite klurigare på PIC, t.ex. när int är 16 bitar och ens uträkningar inte kanske blir som man tänk sig (ex. vad är 256*256).

[TomasL]

Och att göra den multiplikationen i ASM.
Javisst finns det fallgropar som i allting, men jag påstår att de är mindre och enklare att hantera i C än i asm.

[labmaster]

>Visst är det så. Bara att köra på med de "lessons" och det övriga materialet/dokumentation som finns till PICkit2 Starter Kit.

Toppen Sodjan fortsätter du så här hamnar du på min tillgångslista . Det är kanonbra att TS får tips om var han skall läsa. Du länkade ju till PICkit2 Starter Kit så jag får väl skumma igenom dessa också. Behöver TS specifik hjälp med hur han skall tolka datablad och detaljer i CPU:n kanske du kan hjälpa till ty jag är dåligt inläst på detaljerna i PICarna. Det har ju framgått tidigare.

PS. Jag har PM:at teljemo, han vill lära sig C och den plattform han har. Arduino och andra plattformar är således inte aktuella DS.

[Batman]

Ok det börjar bli sent. Jag borde inte ha haft med det sista om asm i quote. Jag tänkte mer på saker som blir olika för PC och PIC som (long foo = 256*256;).

[TomasL]

Här är en länk till en första inledande grundkurs i C http://www.fored.co.uk/html/LearnC.zip.
DOck är det ett par saker man skall vara medveten om, den är anpassad till WIZ-C så namn på portar mm är annorlunda (det skiljer alltid mellan olika kompilatorer vad periferienheterna kallas).
Alla exempel är naturligtvis baserade på deras egen kompilator/IDE och deras egna utvecklingskort, men det det finns ett antal mycket bra exempel med detaljerade rad-för-radbeskrivning, samt en liten uppslagsdel i slutet.

PS, zipfilen innehåller tydligen nått setup-program, har inte en susning vad som installeras, förmodligen är det exempelprojekt och sånt, det är PDFen som jag tänker på, så man behöver inte installera nånting.

[sodjan]

Problemet med programmering av en PIC (eller AVR eller någon annan mikrokontroller)
har inte alls så mycket med val av språk att göra som det kan verka här. Det har till största
delen att göra med att förstå hur en PIC/AVR/whatever *fungerar* över huvudtaget.

När man väl vet hur processorn fungerar så blir programmeringen genomförbar
oavsett vilket språk man har valt. Om man *inte* vet hur processorn fungerar
så blir programmeringen i stort sätt omöjlig helt oavsett val av språk.

Personligen är jag av uppfattningen att man *initialt* lär sig hur processorn
fungerar i grunden snabbare och mer "rätt" via ASM. Men det finns olika
uppfattningar om det...

> Behöver TS specifik hjälp med hur han skall tolka datablad och detaljer i CPU:n kanske du kan hjälpa till...

Den utrustning TS har är ju en av de vanligaste för introduktion till PIC idag, så det finns
säkert många som har möjlighet att hjälpa till med de initiala problemen.

Och, man jag kanske feltolkar dig, det är ju inte så att man kan strunta i databladen
bara för att man kör C.

Hur som helst, eftersom det finns 8 (10?, minns inte) färdiga exempel som fungerar direkt
mot den aktuella hårdvaran så finns det liten anledning att leta efter något annat redan.

> Och att göra den multiplikationen i ASM.

Nu så är ju en multiplikation med just 256 *oerhört* enkel att göra i ASM...

[TomasL]

Jag tänkte mer på saker som blir olika för PC och PIC som (long foo = 256*256;).

Och det blir olika mellan olika PC's också, en "long" är sannolikt olika lång i en gammal orginal IBM-PC jämfört med dagens moderna maskiner.

Det är väl troligen en av de mest missförstådda "features" i C gissar jag (det där med längden på olika typer).

Och, man jag kanske feltolkar dig, det är ju inte så att man kan strunta i databladen
bara för att man kör C.

Så länge man inte vill komma åt någon periiferienhet, så behöver man inte läsa databladet, men det blir ju lite meningslöst då
Nä, man behöver läsa databladet lika mycket oavsett vilket språk man använder.

Nu så är ju en multiplikation med just 256 *oerhört* enkel att göra i ASM...

Jovisst är det det en bunt vänsterkift i ett antal 8-bitars variabler, typ.
Men det kräver lite mer skrivande än just 256x256, eller 256 << 8

[labmaster]

> Och, man jag kanske feltolkar dig...

Om det är mig du kanske feltolkat så är svaret JA. Man måste alltid läsa databladet om man skall hålla på med hårdvarunära programutveckling där det inte finns något operativsystem som tar hand om hårdvaran.

Tror bestämt att jag redan har berättat för TS att han skall läsa manualen för utvecklingsplattformen och att han skall studera databladet ordentligt. Det har väl försvunnit i allt brus Sodjan .

[Batman]

Jag tänkte mer på saker som blir olika för PC och PIC som (long foo = 256*256;).

Och det blir olika mellan olika PC's också, en "long" är sannolikt olika lång i en gammal orginal IBM-PC jämfört med dagens moderna maskiner.

Det är väl troligen en av de mest missförstådda "features" i C gissar jag (det där med längden på olika typer).

Det blir samma(65536) på alla 32 bitars uP och större med minst 32 bitars int, på 16 bitars uP och mindre med 16 bitars int blir det 0.