Fördelarna med PIC är enligt min uppfattning att de har bättre datablad och bredare utbud av kretsar,
Är det inte konstigt så säg !!??
Är AVR något att ha egentligen?
Jag har nog hittat något...
Jag har inte testkört. Jag har inte prylar tillgängliga men jag skall.
Jag har inte kommit längre än komma-igångstadiet. Jag har ett LED-exempel jag har fått någostans ifrån och ett uart-exempel som jag fått någon annanstans ifrån. LED-exemplet funkar fint. Samma exempel med modifierat blinkmösnster funkar fint. Uart-exemplet funkar fint men det gör att processorn förlorar kontakten med draken. För gott.
Och det kan ju inte ha med koden att göra. Permanenta ändringar kan man ju bara göra med fuse-bits. Och dom kan man ju inte ställa från programmet. Kollat upp det. Dubbelkollat. Right?
Wrong!!
Jag har inte testkört. Jag har inte prylar tillgängliga men jag skall.
Jag har inte kommit längre än komma-igångstadiet. Jag har ett LED-exempel jag har fått någostans ifrån och ett uart-exempel som jag fått någon annanstans ifrån. LED-exemplet funkar fint. Samma exempel med modifierat blinkmösnster funkar fint. Uart-exemplet funkar fint men det gör att processorn förlorar kontakten med draken. För gott.
Och det kan ju inte ha med koden att göra. Permanenta ändringar kan man ju bara göra med fuse-bits. Och dom kan man ju inte ställa från programmet. Kollat upp det. Dubbelkollat. Right?
Wrong!!
Jodå. Mitt uart-exempel kopplar bort allt som inte är uart. Ingen elektronik for dummies här inte. Man måste läsa *hela* databladet.The debugWIRE system shares system clock with the SPI module. Thus the PRSPI bit in the
PRR register must not be set when debugging. Setting the PRSPI bit will disable the clock to the
debugWIRE module and may lead to lockup of the device.
I mitt universum är din uppfattning helt uppåt väggarna! :-)sodjan skrev:> Fördelarna med AVR är enligt min uppfattning att de har bättre datablad och bredare utbud av kretsar,
Fördelarna med PIC är enligt min uppfattning att de har bättre datablad och bredare utbud av kretsar,
Är det inte konstigt så säg !!?? :-) :-)
Angående växlingen mellan DebugWire / ISP så får jag nog i så fall ta tillbaka min kritik om dess "välkända knölighet". Hade läst ett antal inlägg från folk som använt DW och tillsammans konstaterat att det var klumpigt att växla hela tiden, vilket jag tolkade som att man var tvungen att programmera via ISP. jälv har jag varken drake eller ICE, utan använder den där nya, fancy grejjen som kallas serieport för debuggning...
Uppenbarligen ska man knipa ihop truten tills man testat saker själv. Det var väl en nyhet? :-) Ber om ursäkt till alla AVR-älskare där ute.
Sen vet ju alla att de som kör med obskyrast processor/operativsystem/kompilator alltid vinner i nördpenismätartävlingar, så nu ska jag direkt byta till... en egentillverkad microcontrollerserie tillverkad av gamla tuggumin och gem som jag ska programmera via ZigBee på mitt hemknackade operativsystem som bara funkar på moddade gameboy orginal med gula chassin.
angående prestanda PIC kontra AVR så hade vi en tråd om detta för ett tag sen där vi tittade på benchmarks från free-RTOS (http://www.freertos.org/PC/)
sammanfattning: en PIC18 på 40MHz är snabbar än en Atmega323 på 8MHz.
(när jag påpekade att en modernare AVR kan klockas i 20MHz ville ingen fortsätta den diskussionen).
sammanfattning: en PIC18 på 40MHz är snabbar än en Atmega323 på 8MHz.
(när jag påpekade att en modernare AVR kan klockas i 20MHz ville ingen fortsätta den diskussionen).
Jag har provkört med debugwire och efter modifikation av programmet har jag lyckats köra mitt uart-exempel, det som alltid brickat AVRen tidigare, utan att det hände denhär gången.
Det står i manualen att man inte får skriva i PRR när man använder debugwire och det gjorde jag.
Alltså DET VAR MIN SBS!! Erkänner. Manualen rular.
Men min adokat påpekar att det alltså är på det sättet att en helt oskyldig och 100% korrekt registerskrivning när man använder parallellportssprogrammering *dödar* processorn när man programmerar med Dragon eller JTAGICE mkII (dvs använder debugwire som prog. i/f). Permanent. Den åtalade har inte micklat med fuse eller lock bits och hade inte den minsta tanke på att själva programmet skulle kunna bricka processorn.
Om detta kan räknas som förmildrande omständigheter är det upp till juryn att avgöra.
Det står i manualen att man inte får skriva i PRR när man använder debugwire och det gjorde jag.
Alltså DET VAR MIN SBS!! Erkänner. Manualen rular.
Men min adokat påpekar att det alltså är på det sättet att en helt oskyldig och 100% korrekt registerskrivning när man använder parallellportssprogrammering *dödar* processorn när man programmerar med Dragon eller JTAGICE mkII (dvs använder debugwire som prog. i/f). Permanent. Den åtalade har inte micklat med fuse eller lock bits och hade inte den minsta tanke på att själva programmet skulle kunna bricka processorn.
Om detta kan räknas som förmildrande omständigheter är det upp till juryn att avgöra.
sodjan, måste du klaga på allt folk skriver även när du inte har något vettigt att säga?sodjan skrev:> PIC utför 1 instruktion var fjärde klockcykel,
Eller ibland 8 (d.v.s 2 instruktions cykler, dubbel-ords instruktioner på PIC18).
> hopp tar 2 i PIC osv
2 vadå ?
Hopp tar 2 *instruktions* cykler (eller 3, då en "skip" följs av en dubbel-ords instruktion på PIC18).
Skärpning!
