Svenska ElektronikForumet

> men jag funderar på att använda en PIC18F25K80

Ja, det är en modell utan stöd i PK2 men i PK3, så vitt jag kan se.
Kolla Readme katalogen i MPLAB installationen.
Speciellt filen "device support.htm".

Har läst igenom denna tråd, skummat bitvis om hur olika "familjer" Avr, Arduino, Microscip, Stamp m.m hantererar problemet med att göra saker samtidigt. Jag är nog att betrakta som nybörjare när det gäller programmering och vill som många andra snabbt få saker att hända. Sekventiellt programflöde gentemot parallell processing är i min värld den stora skillnaden. Att hålla reda på interupt (programavbrott) är pest för en nybörjare. Jag tycker jag det är nog svårt med felsökning ändå. Parallax som har nämts här tidigare är inte bara BS2 stamp. Det är framförallt Propeller. Som dessutom snart kommer med Propeller 2. Propeller programeras nativt i "Spin" som är ett C liknande programspråk. Men kan även programmeras i +50 andra språk och dialekter. Propeller har 8st 80 Mhz"cogar" gemesamt runt en minnes "hub" Varje enskild cog har bl.a videokapcitet. Sann parallel processing. Huruvida användarna är fler eller färre vet jag inte. Men vad jag vet är att deras forum är mycket aktivt och det finns ett "objektbibliotek" med rutiner för nästan allt, som dessutom kontinuerligt fylls på.

Så: "Det där med "samtidigt" har vi rett ut redan" som någon sa, Till det säger jag nog, nja...

> ...hantererar problemet med att göra saker samtidigt.

Nej. Diskusionen handlar/handlade om definitionan av "samtidigt".
Jag retar mig oerhört på de som inte fattar att det är väldigt
viktigt att ha klart för sig vad man egentligen menar när man
säger att något ska hända samtidigt. I 99 fall av 100 så visar
det sig att det faktiskt inte alls behöver vara samtidigt...

> Sekventiellt programflöde gentemot parallell processing är i min värld den stora skillnaden.

Udda värld du lever i...
Nej, det som är viktigt är en klar förståelse av det aktuella problemet
som applikationan ska lösa och en tydligt kravspec. Inget annat. Om man
inte fattar vad man håller på med så hjälper inte parallell processering.

> Att hålla reda på interupt (programavbrott) är pest för en nybörjare.

Då får man se till att göra stadiet "nybörjare" så kort som möjligt !

Generellt sett är inte interrupt något problem alls och oftast/alltid
en integrerad och nödvändig del av nästan alla mikrokontroller projekt.

Visst, om man ser ett behov av just de saker som utmärker en Propeller
så kan man väl använda dom, men att man inte fixar att lära sig att hantera
något så rellativt trivialt som interrupt på en AVR/PIC är en dålig anledning.

Ibland pratar man om och förbi varandra. Och kanske gör man det hellre än bra om man är ny i sammanhanget. Jag håller absolut med dig Sodjan om att det är uppgiften som styr. Allt annat är egentligen oviktigt. Sekventiellt eller parallellt.

Vet inte varför men plötsligt ser jag en syn, jag ser Törnrosa framför mig och det är julafton. Törnrosa skall gå på bal men har dessvärre ingen klänning. Goda råd dyra. Vad göra? Då skyndar mössen till hjälp med sax nål och tråd... Mäter, klipper, syr provar, ja resten vet ni. Mössen jobbar alla tillsammans men ändå oberoende. Var och en löser sin uppgift parallellt utan att vänta in...

Kanske en udda jämförelse men jag vill ändå ha sagt att det har gått relativt bra för mig lära mig programmera en Propeller. Jag är trots allt 60+, kanske inte som en dans, som för mössen på Julafton. Men ändå över förväntan. Jag trodde i min enfald att det berodde på att jag slapp att tänka på avbrottsrutiner. Men som sagt jag är nybörjare så vad vet jag...

offtopic: det känns väldigt komiskt på något sätt att jag tittade på Törnrosa igår med min son

OnTopic:
Jag tror inte att det har varit lättare för dig att programmera propeller bara för att du har sluppit avbrottsrutiner. Jag har tittat lite på propeller, för jag gillar sättet det beskrivs på att den jobbar, men jag tycker språket verkar svårt för en nybörjare. Jag har testat Pic med assembler men nu fastnat för arduino. Jag tror helt enkelt att det som är lättast för dig själv är det "du bestämmer dig för att tycka är lättast" är lättast just för dig. Alla har olika förutsättningar och olika sätt att tänka.

askungen!

haha.. sant... askungen.... och jag som såg både askungen och Törnrosa igår (min son va sjuk så vi hade filmdag) reagerade inte ens

> Jag trodde i min enfald att det berodde på att jag slapp att tänka på avbrottsrutiner.

Jag tror varken det var p.g.a enfald eller p.g.a avsaknaden av avbrottsrutiner...

Som alltid finns det trösklar. Om man råkar ha ett exempel eller liknande som
gör att det man just då ville göra blev väldigt enkelt, så upplevs det ju just så.
Vi vet ju inte vad du gjorde med propellern så vi kan inte bedöma det.

Det här med avbrott i t.ex AVR/PIC är inte svårt, bara man kommer över just
*den* tröskeln. Det är inget speciellt med just det och det finns många andra
liknande trösklar med ungefär samma höjd. Det är så väldigt personligt och
beroende på vad man gör just för tillfället vilken tröskel man fastnar på. Det
kan lika gärna vara ADC, I2C eller något annat som just avbrottshanteringen.

> Allt annat är egentligen oviktigt. Sekventiellt eller parallellt.

Poängen är att det inte är varken eller. Var går gränsen mellan sekvensiellt och parallellt ?
Om man switchar uppgift varje sekund, är det då "samtidigt" ?
Eller om man byter uppgift varje millisekund, skulle det upplevas som "samtidigt" ?
Även fast det ju aldrig sker mer än en sak vid varje givet ögonblick ?

Hela problemet har, som jag har sagt, med definitionen av "samtidigt" att göra !
Och när något säger "det ska ske samtidigt" utan att *tänka* innan...

Gränsen mellan sekvensiellt och parallellt i ett synkront (klockat) system är ju väldigt enkel att säga. Sker det samma klockcykel är det parallellt, sker det på varandra följande klockcykler är det sekvensiellt.

Om man däremot _behöver_ göra parallell processing eller klarar sig med sekvensiell, eller nån form av tidsuppdelad multiplexing (cooperative el. preemtive, interruptdriven eller inte) är ju en annan fråga.

Ponera att man vill sampla en signal, FFT behandla den, och generera videosignal för att visa resultatet. I det fallet kan 3 st parallella processorer vara av nytta om man vill undvika extremt höga klockfrekvenser.

Ett skäl är bl.a att man slipper ta hänsyn till att t.ex videogenereringen behöver avbrytas mitt i pixelströmmen för att sampla, eller FFT beräkna. Just videogenerering brukar vara knepigt med en processor eftersom pixelgenerering kräver alla klockcykler används efter varann utan avbrott och att det sker synkront. Slipper man avbryta, slipper man också slösa klockcykler på att spara vart man var innan (context switch - push/pop).
Microchips support för BSD/Linux mijö är dessvärre skrallt jämfört med Atmel AVR:s.

Men om man kan klara sig med en vanlig AVR/PIC mikrokontroller så kan man få lågt pris och enkla kapslingar vilket ofta är en stor fördel.

Fast om priset och chipskapselns komplexitet blir alltför högt kan man lika gärna köra FPGA rakt av. Då är 300 Msps i 20 kanaler inget stort problem heller..