pic vs. atmel microcontrollers

[Verwijderd]

Ik had laatst een hevige discussie met iemand die alleen maar atmel microcontrollers gebruikte. terwijl ik pic microcontrollers de beste vind. beide series lijken enorm veel op elkaar en zijn enorm populair. Maar toch waarom zou de atmel of de PIC beter zijn dan de andere?
Wij kwamen uiteindelijk tot de conclusie dat het ligt aan welke je geleerd hebt. met welke je de meeste ervaring hebt. Iemand betere redenen?

[Paulstartrek]

Op school heb ik assembler geleert met de 68HC11 van moterola en later nog wat met de atmel avr. en inderdaad waar je mee hebt gewerkt is voor jezelf de beste. pas als je beide evenveel heb gebruikt ga je verschillen zien en deze ook waarderen of juist niet waarderen. Ten opzichte van de 68hc11 is de atmel avr duidelijk de betere. over de pic doe ik geen uitspraak omdat ik hem niet ken.
Maar zijn alle microcontrollers niet (oppervlakkig) hetzelfde?

[LopeZ]

Move OH -> CE

Kan niet garanderen dat deze openblijft.

[TheGhostInc]

Dit is een beetje hetzelfde als, wat is beter:
Amd of Intel

De specificaties liggen vaak dicht bij elkaar, de verschillen zijn marginaal, en vaak is er maar weinig bekend over problemen met oscileren ed. Want dat is echt het enige lastige (soms) aan die dingen.
Daarnaast is de simpelste Atmel grappig als je de duurdere PIC's kijkt en visa versa.

Daarnaast ben ik echt weinig mensen tegen gekomen die beiden programmeren, maar probeer anders een lijst op te stellen van de functies van de verschillende series.
Dan kom je vanzelf de verschillen tegen.

(Voorbeeld, een P4 heeft lastigere klokchips nodig dan de Athlon, plus punt voor de Athlon)

Daarnaast is de prijs van de chips *ZEER* regio gebonden, in de VS zijn de prijzen echt anders dan hier. Ook zijn sommige chips gewoon perfect leverbaar, terwijl andere nooit ergens vermeld worden.

[Verwijderd]

Ach ja, ik ben ook fan van de PIC's. Ik gebruik er nu ook 1 voor mijn nieuwe baybus (software is nog in de beta fase). Atmels lijken me op het eerste gezicht wat moeilijker dan PIC's. Ik kan me vergissen hierin hoor, ik heb namelijk nooit Atmels geprogrammeerd. Maar de populaire 16F87x en 16F84 serie hebben een instructieset van slechts 35 opcodes. Ik weet niet wat de gemiddelde instructiesetgrootte van de atmel is???

[Verwijderd]

Haha, 68HC11 werk ik ook mee op de THRijswijk...maar andere heb ik nog niet gezien....volgens mij zijn de verschillen minimaal, en volgens mij ligt het er maar net aan of je goed ken programmeren met ASM, en niet aan de microcontroller

[Verwijderd]

Ik heb gewerkt met PIC's en dat beviel me niet:
- De manier hoe de IO-poorten aangestuurd worden (omslachtig)
- De geheugen verdeling (Code paging)
- De kloksnelheid(CISC).

Op dit moment komt er bij mij alleen Atmel binnen:
- IO poorten zijn simpel aan te sturen en doen ook wat ze moeten doen, geen I/O problemen
- Geheugen is lineair opgezet
- Extern geheugen erbij plakken is geen probleem
- De kloksnelheid (RISC)
- De controller is gemaakt vanuit het oogpunt dat er vooral in hogere talen geprogrameerd wordt (C, er zitten 32 registers hiervoor speciaal in de controller)
- Upgraden naar een grotere familie is geen probleem.

[morphje]

Verwijderd schreef op 06 February 2003 @ 18:11:
Haha, 68HC11 werk ik ook mee op de THRijswijk...maar andere heb ik nog niet gezien....volgens mij zijn de verschillen minimaal, en volgens mij ligt het er maar net aan of je goed ken programmeren met ASM, en niet aan de microcontroller

offtopic.
Mooi dan weet ik dus ook gelijk wat ik de minor microcontrollers te zien krijg. Dan weet ik dat ook weer. Ben ik wel blij om.

ontopic:
PIC kende ik niet tot voor kort geleden, het mooie vond ik dat er al een paar dwazen een linux achtif iets voor geschreven hadden en dat het zelfs een soort multithreading achtig iets ondersteunde

motorola is waar ik altijd mijn aandacht op gehouden heb. Vond ik altijd wel een lekker microgevalletje. Maar zoals als iemand zei, kijk wat je nodig heb en schrijf de verschillen/overeenkomsten op.

[Verwijderd]

De verschillen worden natuurlijk nog kleiner als je een fatsoenlijke C compiler gebruikt.

Al neem ik al aan dat jullie hier niet uitgaan van assembly?

[morphje]

Verwijderd schreef op 06 February 2003 @ 19:59:
De verschillen worden natuurlijk nog kleiner als je een fatsoenlijke C compiler gebruikt.

Al neem ik al aan dat jullie hier niet uitgaan van assembly?

persoonlijk wil ik heel graag uitgaan van assembly als basis. tenminste dat hoop ik te leren op school. True een c-compiler is makkelijker natuurlijk en een beetje normaal programmeren kan je zo vertalen naar fatsoenlijke binary code voor de microprocessor.
Daarintegen is het ook weer zo dat er grote verschillen zitten in dingen zoals poortaansturing zoals eerder genoemd. Is de GNU compiler niet zo fatsoenlijk met bepaalde flags dat de juiste code eruit gepoept word ?

[Benadski]

Ik ben begonnen met AVRs. PICs heb ik nooit gebruikt en lijken me veel ingewikkelder en trager. Het mooie van de RISC architektuur is dat je heel makkelijk kan berekenen hoe snel je code wordt uitgevoerd. Ook zijn de instrukties simpeler, een instruktie doet één ding en niet zoals bij de PICs een aantal dingen tegelijk. Dat spaart code omdat je nooit dingen hoeft te doen die niet nodig zijn.

Waarom ik niet meer van AVRs af wil:

Ze lopen vanaf 0.1Hz kloksnelheid en zijn vaak 20% overklokbaar. Sneller dan de meeste PICs
Heel makkelijk te programmeren met weinig externe hardware (alleen een paar weerstandjes)
De meeste software is gratis te downloaden
Gratis GNU C compiler met veel support
Zelfs een basic compiler is beschikbaar (bascom avr)!
De AVR is goedkoper.
Overzichtelijke struktuur en datasheets
Er zijn meer maar simpelere instrukties bij de AVR, dus meer mogelijkheden!
Ik heb ooit eens een STK500 gewonnen op avrfreaks.net

Nu zeg ik niet dat PICs niet goed zijn, maar AVRs hebben meer toekomst denk ik. Atmel brengt erg snel nieuwe en steeds snellere AVRs op de markt, ik weet niet hoe dit bij Microchip gaat?!

[Verwijderd]

Verwijderd schreef op 06 February 2003 @ 18:46:
Ik heb gewerkt met PIC's en dat beviel me niet:
- De manier hoe de IO-poorten aangestuurd worden (omslachtig)
- De geheugen verdeling (Code paging)
- De kloksnelheid(CISC).

Op dit moment komt er bij mij alleen Atmel binnen:
- IO poorten zijn simpel aan te sturen en doen ook wat ze moeten doen, geen I/O problemen
- Geheugen is lineair opgezet
- Extern geheugen erbij plakken is geen probleem
- De kloksnelheid (RISC)
- De controller is gemaakt vanuit het oogpunt dat er vooral in hogere talen geprogrameerd wordt (C, er zitten 32 registers hiervoor speciaal in de controller)
- Upgraden naar een grotere familie is geen probleem.

Als je er wel mee gewerkt hebt dan moet je weten dat I/O toch wel heeel simpel is bij de PIC's. Enige configuratie is de Tristate mode instellen, oftwel of je uitgangen of ingangen wil hebben. En dan kun je gewoon een waarde naar een poort schrijven(8bits) of een pin van een bepaalde poort veranderen met met slechts 1 instructie.

Dat over het lineaire geheugen ben ik met je eens. Dat sucks echt bij de PIC. Ik snap nog steeds niet waarom ze daarvoor hebben gekozen.

Kloksnelheid valt wel mee bij de PIC, de meeste kunnen wel tot 20 MHz draaien. Een volledige instructie wordt uitgevoerd in 4 klokpulsen (effectief dus 5 MHz), wat toch redelijk snel is voor een simpele controller. Meestal echt wel meer dan genoeg om andere snelle hardware bij te houden.

[Verwijderd]

Verwijderd schreef op 06 February 2003 @ 22:59:
[...]


Als je er wel mee gewerkt hebt dan moet je weten dat I/O toch wel heeel simpel is bij de PIC's. Enige configuratie is de Tristate mode instellen, oftwel of je uitgangen of ingangen wil hebben. En dan kun je gewoon een waarde naar een poort schrijven(8bits) of een pin van een bepaalde poort veranderen met met slechts 1 instructie.

Dat over het lineaire geheugen ben ik met je eens. Dat sucks echt bij de PIC. Ik snap nog steeds niet waarom ze daarvoor hebben gekozen.

Kloksnelheid valt wel mee bij de PIC, de meeste kunnen wel tot 20 MHz draaien. Een volledige instructie wordt uitgevoerd in 4 klokpulsen (effectief dus 5 MHz), wat toch redelijk snel is voor een simpele controller. Meestal echt wel meer dan genoeg om andere snelle hardware bij te houden.

Ik dacht dat die IO nog iets trickies had van dat als je een ingang hebt en je zet er intern een 1 op (dus zogenaamd als uitgang gebruiken), dan wordt de ingang een 1, maar het is ook al weer lang geleden dat ik er iets mee gedaan heb PS IO voor een AVR is ook heel simpel.
Wat betreft kloksnelheid, standaard werkt alles wel op 8 MHz (dus RISC 8 miljoen instructies), je hebt nu ook al van die MEGA's en die werken op 16 MHz en dat voor een microcontrollertje, dat is realtime data manipuleren. Een PIC moet je dan al op 64MHz laten draaien.

Mij bevalt AVR beter dan n PIC en ik heb een goedkope AVR bron.

[Sprite_tm]

Ik ben zelf begonnen met de PIC, namelijk de 16c84. (voorganger van de huidige 16F84) Ik heb daar een stel programmaatjes in geschreven enzo, beetje mee aangeklooid, je weet wel. En doen kwam ik de AVR tegen. Nouja, precies op dezelfde manier mee begonnen enzo, uiteindelijk kon ik het allebei even goed. Ik heb alleen de PIC laten liggen en ben met de AVR verder gegaan. Waarom?



- Microchip had in de tijd dat ik begon met programmeren slechts 1 chip met EEPROM-geheugen, de rest was allemaal EPROM, dus hetzij slechts 1 keer programmeerbaar, hetzij met een raampje (=duur) wat je om 't beest te wissen een paar minuten onder een UV-lamp moest leggen (had ik niet, paar minuten zijn me te lang)

- Bij een PIC moet je als je een bepaald iets wil uitvoeren, alles langs het W-register trekken. Dat betekent dat je wat extra cycles nodig hebt om de relevante data in het W-register te zetten, besides vind ik het lastiger programmeren. Bij de AVR kan je bij alle instructies de bovenste 16 registers gebruiken en bij degene waar je geen immediate gebruikt gewoon alle registers.

- Een AVR kan in 1 kloktik 1 instructie uitvoeren, een PIC (iig de 16C64) heeft 4 kloktikken nodig

- Nofi, maar ik heb het idee dat de PIC een beetje een kleine uC is die te veel opgeschaald is. Geen idee of dat waar is of of dat de reden is, maar ik zie verdacht veel bankswitching-achtige perikelen in de PIC-architectuur.... Lastig IMHO.



Voordelen PIC (bij lange na niet volledig, omdat ik ondertussen veel details over het beest vergeten ben)

- Was er eerder (vandaar dat ik er ook mee begonnen ben). Kan in theorie betekenen dat er ondertussen meer bugs uit de PIC gehaald zijn (proven technology) maar omdat het niet zo lang scheelt kan die bewering ook bullshit zijn.

- Was iig toen ik 'm gebruikte goedkoper dan de AVR



Anywayz, mijn verhaal leunt de AVR kant op, als iemand nog voor/nadelen wil toevoegen: Gil maar

Ow, ik programmeer btw alleen in assembly, dus ik weet niets van evt. hogere-talen-ondersteuning van beide processoren af.

[Lone Gunman]

de meeste pic's uit de 18f serie hebben wel lineaire memory adressering.
kloksnelheid valt idd wel mee, meeste types zijn 20 of 40 mhz, wat vertaalt naar 5 of 10 mhz effectief (wat je dan direct kunt vergelijken met de atmel-snelheden). Daarbij zijn pic's wel degelijk RISC waardoor het verschil tov atmels eigenlijk wel meevalt.

edit : nou het toch over microcontrollers gaat :
k wil voor een projectje een debugger + testbord setje gaan kopen. t is voor een medium-range mcu (16k flash, 2k+ ram, externe bus).
Merk microcontroller maakt me niet zoveel uit (atmel/pic/motorola/...)
Heeft iemand hier een dergelijke setup en wat zijn de ervaringen ermee ?
k heb zelf alleen ervaring op dat vlak met bdm van motorola, en dat werkt imo erg fijn. Zijn er voor atmels/pics ook dergelijke dingen beschikbaar die ongeveer dezelfde functionaliteit bieden en niet te duur zijn ? (max 250 euro)

[ Voor 48% gewijzigd door Lone Gunman op 07-02-2003 00:04 ]

[Verwijderd]

Kijk ook eens naar de ATmega serie van Atmel. Dat zijn ook AVRren, maar die hebben features die wel heeeeel lekker zijn (en niet veel duurder). Er zit er nu 1 in mijn Xtreme baybus, die heeft een bootloader (flashen via normale seriele poort), J-TAG debugging, I2C, USART en SPI enz enz

De AVR op zich heeft voordelen omdat hij prachtige timers heeft, die ook hardware-reload hebben (zodat je niet zit te kloten met altijd onprecieze software reloads zoals op de kleinere PICs).

Grootste voordelen van de AVR zjn wel dat er beregoede C-compilers voor zijn, inclusief een redelijk goede gratis Gnu-C compiler. upgraden/downgraden tussen types is EASY (ik ben opgeklommen van de AT90S8535 naar de ATmega163 naar de ATmega16 naar de ATmega32). Dit alles zonder enige hardware versleuteling en minimale software verbouwing!

De kleine instructieset van de PIC is ook al geen voordeel; dit betekent dat je veelal meerdere instructies achtereenvolgens moet aanroepen om iets gedaan te krijgen. De AVR heeft dit ook, maar die vreet maar 1 klok per instructie. Dit helpt trouwens ook de EMC straling wat lager te houden (je kunt performance halen op lagere klok). PICs hebben vaak varierende instructies per chiptype; AVR vrijwel niet.

De AVR is een register-based processor, zodat niet alle berekeningen door de accu getrokken hoeven te worden; vrijwel elke instructie kan op vrijwel elk register worden uitgevoerd. Tel daarbij nog een 2-cycle hardware-multiplier op (in de ATmega), en je hebt een beest van een controller

Ik heb ooit de eer gehad te spreken met een van de ontwikkelaars van de AVR (een Noor). De hadden voor deze AVR-chip gekeken naar de 8051 vanwege zijn succes, en naar de MC68000 vanwege de architectuur... Volgens mij hebben ze hiermee een absolute winnaar gemaakt!

Onderling is de concurrentie moordend met microchip (makers van de PIC). Ik weet nog goed dat de PIC er in 8-pins behuizing was en de AVR niet.... hahahaahh duurde niet lang of Atmel kwam ook met een 8-pins AVR, die gelijk belachelijk veel extra's had... hoe bedoel je elkaar beconcurreren.... Gelukkig hebben wij daar alleen voordeel voor: beregoede chips voor kleine prijzen

[Verwijderd]

Wat natuurlijk ook je voorkeur kan bepalen is welke microcontrollers je toevallig in huis hebt :

Voor toekomstige projecten (LCD controller, snelheidsregelaar, In System Programming, alarmsysteem, etc.)

[Lamborghini]

Benadski schreef op 06 February 2003 @ 20:55:
Ik ben begonnen met AVRs. PICs heb ik nooit gebruikt en lijken me veel ingewikkelder en trager. Het mooie van de RISC architektuur is dat je heel makkelijk kan berekenen hoe snel je code wordt uitgevoerd. Ook zijn de instrukties simpeler, een instruktie doet één ding en niet zoals bij de PICs een aantal dingen tegelijk. Dat spaart code omdat je nooit dingen hoeft te doen die niet nodig zijn.

PIC zijn ook RISC en doen ook maar 1 ding tegelijk. Je moet niet oordelen over zaken waar je niks vanaf weet

Verwijderd schreef op 06 February 2003 @ 18:46:
Ik heb gewerkt met PIC's en dat beviel me niet:
- De manier hoe de IO-poorten aangestuurd worden (omslachtig)

Op dit moment komt er bij mij alleen Atmel binnen:
- IO poorten zijn simpel aan te sturen en doen ook wat ze moeten doen, geen I/O problemen

IO bij een PIC en een AVR is vrijwel identiek aan te sturen.

Ik ken Motorola, Atmel's en Microchip's. Allemaal leuke beestjes en allemaal hun eigen voordelen en nadelen. Het is, zoals al eerder is geroepen, hetzelfde als de keuze voor AMD of Intel.

AVR's zijn alleen op dit moment goedkoper tov PIC's als je dezelfde features wilt. En AVR heeft bij vele kleintjes al heel wat leuks eringebakken. Alleen PIC heeft weer het voordeel dat die wat makkelijker is om mee te beginnen. 1 Register en een kleine instructieset, alleen dan wel weer het gezeur met de banking.

[ Voor 48% gewijzigd door Lamborghini op 07-02-2003 23:09 ]

[Verwijderd]

Maarja, banking komt pas om de hoek kijken vaak bij moeilijkere zaken als USART, Interrupts, timers ed.
Voor simpele routines en IO hoef je er normaal niet eens aan te denken (alleen tristate van pinnen bepalen moet wel in een andere bank).

En wat er ook voor prestatie of mogelijkheden verschillen er zijn tussen de 2, het is altijd afhankelijk van de geprogrammeerde instructies. Een super microcontroller met brakke code is altijd slechter dan een simpele microcontroller met goed geoptimaliseerde code.

Dat merk je dan ook vaak bij microcontrollers die worden geprogrammeerd in een hogere taal: tis allemaal wel lekker makkelijk om te programmeren, maar je haalt bij lange na niet de optimale prestaties uit de controller.

Ik ben zelf dus bezig met een project met een PIC en het zal je verbazen hoe verbluffend goed deze PIC werkt en wat ie allemaal kan, ondanks dat ie maar 2K Flash geheugen heeft. Puur en alleen omdat je in ASM de beste optimalisaties kan schrijven. In een hogere programmeer taal zou ik waarschijnlijk nog niet eens een kwart erin krijgen van wat ik er nu in heb zitten.

PIC zijn ook RISC en doen ook maar 1 ding tegelijk. Je moet niet oordelen over zaken waar je niks vanaf weet

Klopt een PIC is idd een RISC

[Lamborghini]

Verwijderd schreef op 07 februari 2003 @ 23:53:
Ik ben zelf dus bezig met een project met een PIC en het zal je verbazen hoe verbluffend goed deze PIC werkt en wat ie allemaal kan, ondanks dat ie maar 2K Flash geheugen heeft. Puur en alleen omdat je in ASM de beste optimalisaties kan schrijven. In een hogere programmeer taal zou ik waarschijnlijk nog niet eens een kwart erin krijgen van wat ik er nu in heb zitten.

Helemaal mee eens. Als je hetzelfde in C had geschreven zat die zo vol Daarom is kennis van assembler ook eigenlijk een must vind ik zelf, en zo moeilijk is het nou ook weer niet die asm.

[Verwijderd]

Lamborghini schreef op 08 February 2003 @ 12:15:
[...]

Helemaal mee eens. Als je hetzelfde in C had geschreven zat die zo vol Daarom is kennis van assembler ook eigenlijk een must vind ik zelf, en zo moeilijk is het nou ook weer niet die asm.

Dat is niet helemaal waar, natuurlijk is het mogelijk dat je meer code maakt, maar van de andere kant is het ook goed mogelijk dat de C code compacter is (denk er wel aan dat je eigen assembly code nooit optimaal uitgewerkt is, omdat je niet alles kunt overzien vanaf een bepaalde code groote).

Even voor de AVR sprekend:
1) Dit is een controller geoptimaliseerd voor de taal C met 32 interne dataregisters voor alles en nog wat direkt te gebruiken.
2) Gebruik je nu een goede C compiler (bijvoorbeeld IAR), dan krijg je een zeer effectieve compacte code, die je niet zo eenvoudig zelf in assembly had kunnen schrijven.
3) Ik heb het dan wel over code van zo een 4 tot 12KByte, dus niet iets simpels, maar iets complex met 16 bits integers, delingen/vermenigvuldigingen, interne regelaars, communicatie met de buitenwereld.
4) C is beter in het uiten van wat je wilt. Hoe snel kun je een idee in code omzetten? Assembly is daar moeilijker in.
5) Hoe snel kun jij iets wat in Assembly geschreven is weer omschrijven omdat iets toch anders moest, met C is dat veel eenvoudiger (en ben je zekerder dat je het goed gedaan hebt).
5) Ik heb de assembly code bekeken van een C programma en zo compact en ingenieus had ik het zelf nooit voor mekaar kunnen krijgen, het pointeren en meerdere malen gebruiken van code.

PS ik gebruik C en Assembly tegelijkertijd, C voor de complexe en veranderlijke dingen (16 tot 32 bit signed vermenigvuldigen/delen/optellen/aftrekken), Assembly voor iets wat precies gedefinieerd moet zijn (bijvoorbeeld een softwarematige I2C implementatie)

[Verwijderd]

Lone Gunman schreef op 06 februari 2003 @ 23:54:
edit : nou het toch over microcontrollers gaat :
k wil voor een projectje een debugger + testbord setje gaan kopen. t is voor een medium-range mcu (16k flash, 2k+ ram, externe bus).
Merk microcontroller maakt me niet zoveel uit (atmel/pic/motorola/...)
Heeft iemand hier een dergelijke setup en wat zijn de ervaringen ermee ?
k heb zelf alleen ervaring op dat vlak met bdm van motorola, en dat werkt imo erg fijn. Zijn er voor atmels/pics ook dergelijke dingen beschikbaar die ongeveer dezelfde functionaliteit bieden en niet te duur zijn ? (max 250 euro)

Bij Conrad kan je een STK500 kopen en een atmega163, dat heb ik gebruikt om via een walkie talkie data door te zenden naar een bestuurbaar karretje. Er zit bovendien meteen een analoog-naar-digitaal converter bij, waarmee je dus traploos het gas en de stand van het stuur kan regelen, om een voorbeeld te noemen wat allemaal mogelijk is
Die hebben 16kb flash en 1kb SRAM, je hebt nog wel andere met 4kb sram en 128 kb flash
Bij conrad:
ATMEGA32: DIL40 bestel nummer: 15 40 81-44 €24.95 <--duur
die hebben 32kb flash en 2kb ram
STK500: bestel nummer: 15 39 88-44 €200.34 <===heel duur

Destijds had ik die STK500 voor 150 euro, en een heleboel at90s2313 chippies erbij (15 29 78-44 ala €6.48), ik heb helaas wel een paar van die dingen gedeeltelijk stuk gemaakt.
En verder als je 4kb in assembly vol typt ben je al wel weer een paar daagjes verder, dus het is echt zat wat er in zit. Alleen het SRAM had zo af en toe wel wat meer gemogen van mij.

Die STK500 heeft een aantal IC-voetjes waar je direct een atmel op plugt, en vervolgens kan je met een bandkabeltje op de gewenste poort ledjes/knoppen aansluiten die ook op de STK500 zitten. Verder kan je de komplete chip voeden en programmeren via 6 kabeltjes, erg makelijk om in-system even snel een waarde te veranderen

EDIT: Wat ik vergeten was: Als je een Subroutine werkend wil uitvoeren moet je eerst de Stackpointer naar het ram geheugen laten wijzen anders doet ie het niet

[ Voor 5% gewijzigd door Verwijderd op 08-02-2003 13:31 ]

[Lamborghini]

Verwijderd schreef op 08 February 2003 @ 12:44:
[...]


Dat is niet helemaal waar, natuurlijk is het mogelijk dat je meer code maakt, maar van de andere kant is het ook goed mogelijk dat de C code compacter is (denk er wel aan dat je eigen assembly code nooit optimaal uitgewerkt is, omdat je niet alles kunt overzien vanaf een bepaalde code groote).

Even voor de AVR sprekend:
..
..

Heb je gelijk in. Een hogere programmeertal is er natuurlijk ook niet voor niks gekomen
Ik heb ook wel eens C code in assembly moeten optimaliseren omdat de compiler er een trage routine van had gemaakt die veel sneller kon. Maar voor complexe routines gaat dat niet meer op en kun je het beter aan de compiler over laten. (je jouw toch compiler schrijver zijn, whoe)


En wat je zei over C en asm door elkaar op die manier is idd het beste.

[ Voor 20% gewijzigd door Lamborghini op 08-02-2003 16:47 ]

[-DarkShadow-]

ls er nog een huiskamer zou zijn, dan zou het daarnaartoe mogen. Zoals eerder gezegd is dit bijna hetzelfde als AMD vs Intel.

[ Voor 89% gewijzigd door -DarkShadow- op 08-02-2003 19:25 . Reden: AVR is beter ]

[Verwijderd]

Lamborghini schreef op 08 February 2003 @ 16:44:
[...]

Heb je gelijk in. Een hogere programmeertal is er natuurlijk ook niet voor niks gekomen
Ik heb ook wel eens C code in assembly moeten optimaliseren omdat de compiler er een trage routine van had gemaakt die veel sneller kon. Maar voor complexe routines gaat dat niet meer op en kun je het beter aan de compiler over laten. (je jouw toch compiler schrijver zijn, whoe)


En wat je zei over C en asm door elkaar op die manier is idd het beste.

Woah, dat vind ik knap, uitgepruttelde asm code bewerken. Volgens mij is dat een onmogelijke taak.

PS. -DarkShadow- ik vind je ook een beetje jammer.

[Verwijderd]

pic uber atmel

want die zijn goedkoop en passen goed in ps(x)

[Lone Gunman]

it_is_i : kun je ook direct debuggen met die stk500 ? dus geheugen/vars bekijken, breakpoints setten etc ? k heb namelijk een beetje rondgekeken op de site van atmel, en zover ik kan zien heb naast de stk500 een in circuit emulator nodig. Voor de mega serie kom je dan uit bij de avr jtag ice of de ice30 (afhankelijk van welke mega's).
Weet iemand hoeveel deze emulators kosten of een (nederlandse) zaak die deze verkoopt ? Waarschijnlijk komen deze dingen ver boven m'n budget uit... emulators zijn doorgaans nogal prijzig

[-DarkShadow-]

Verwijderd schreef op 08 February 2003 @ 18:49:
[...]


Woah, dat vind ik knap, uitgepruttelde asm code bewerken. Volgens mij is dat een onmogelijke taak.

Doen wel meer mensen hoor. Als je ASM kent, dan is het vaak verstandig om de code van de Compiler eens door te nemen, misschien zie je in een oogopslag iets wat compacter kan.

[Verwijderd]

Verwijderd schreef op 06 February 2003 @ 18:11:
Haha, 68HC11 werk ik ook mee op de THRijswijk...

hey ik ook!

[Verwijderd]

-DarkShadow- schreef op 08 February 2003 @ 19:27:
[...]

Doen wel meer mensen hoor. Als je ASM kent, dan is het vaak verstandig om de code van de Compiler eens door te nemen, misschien zie je in een oogopslag iets wat compacter kan.

Je kijkt ook soms in assembly omdat je denkt dat de compiler maar iets heeft aangerotzooid (foutje bedankt).

Code die gegenereerd wordt in C kan ook soms omslachtig zijn (als je de assembly bekijkt), is wel vaak je eigen schuld omdat je bv bagger C geschreven hebt, je leert er wel van om te kijken naar de gemaakt code. Een compiler zet om en gaat niet jouw methode/implementatie omschrijven zodat het compacter/beter wordt.

Denk wel aan hoe de compiler je C code omgezet heeft, of voor snelheid of voor zo weinig mogelijk code (of er tussen in), dan zal als je voor snelheid gekozen hebt , de code altijd kleiner te maken zijn.

PS ben toch nog altijd voor AVR

[Lamborghini]

Verwijderd schreef op 08 February 2003 @ 20:10:
[...]
hey ik ook!

Ik zou nog niet te hard juichen. Dat is nog "maar" een 8 bits controller. In je 3e jaar krijg je een 32-bits microprocessor voor je kiezen en dat is net ff wat moeilijker kan ik je vertellen

[Verwijderd]

Verwijderd schreef op 08 February 2003 @ 18:49:
[...]


Woah, dat vind ik knap, uitgepruttelde asm code bewerken. Volgens mij is dat een onmogelijke taak.

PS. -DarkShadow- ik vind je ook een beetje jammer.

Woah? Wist je dat er specifiek post-processors bestaan die door een c-compiler uitgepoepte assembly aanpakken? En vergis je niet, dat kan VEEL schelen. Veel C-compilers (vooral de goedkopere ) plakken standaard stukjes assembly aan elkaar. En op die manier wordt er wel eens onhandig data verplaatst van register naar register, om de output van het ene te matchen naar de input van het volgende stukje standaard code. Een post processor vreet al die nutteloze moves eruit (en nog wat ander grut) zodat optimalisaties van 10-25% niet onmogelijk zijn.

Gebruik je een echt goede compiler (zoals de IAR voor de AVR) dan optimaliseer je bijna niets meer weg met zo'n processor.

[Verwijderd]

Lamborghini schreef op 09 February 2003 @ 00:26:
[...]

Ik zou nog niet te hard juichen. Dat is nog "maar" een 8 bits controller. In je 3e jaar krijg je een 32-bits microprocessor voor je kiezen en dat is net ff wat moeilijker kan ik je vertellen

Toen ik op de TH Rijswijk zat hadden we nog de 68HC09

de 32-bitters, zijn dat nog steeds de 68000's ???

[Verwijderd]

Verwijderd schreef op 08 februari 2003 @ 18:58:
pic uber atmel

want die zijn goedkoop en passen goed in ps(x)

Hmmm, ik denk dat als je een PIC naast een AVR zet met dezelfde mogelijheden de AVR toch goedkoper is eigenlijk...

[Verwijderd]

Verwijderd schreef op 08 February 2003 @ 12:44:
[...]
*KNIP*

3) Ik heb het dan wel over code van zo een 4 tot 12KByte, dus niet iets simpels, maar iets complex met 16 bits integers, delingen/vermenigvuldigingen, interne regelaars, communicatie met de buitenwereld.

*KNIP*

Inderdaad, dit is naast de onderhoudbaarheid en portbaarheid HET grote voordeel van C. Ga in assembly op een 8-bitter maar eens een integer divide maken, nog leuker een stukje floating point calculatie..... De kans dat je daar in assembly een fout maakt is heel groot, je debugged je rot keer op keer weer, in C is dit allemaal piece-of-koek... En nauwelijks nog verbeterbaar (als je een goede compiler gebruikt dan)

[Verwijderd]

Lamborghini schreef op 09 February 2003 @ 00:26:
[...]

Ik zou nog niet te hard juichen. Dat is nog "maar" een 8 bits controller. In je 3e jaar krijg je een 32-bits microprocessor voor je kiezen en dat is net ff wat moeilijker kan ik je vertellen

Als je een 32-bitter net zo gebruikt als een 8-bitter, dan is het even moeilijk, soms zelfs gemakkelijker, omdat je registers/alu groter is.

Moeilijke bij een 32-bitter is puur dat deze meer mogelijkheden heeft en vaak niet alles onder een dak heeft zoals een 8-bitter (AVR bv), waarbij je dan natuurlijk al die mogelijkheden ook gaat gebruiken, zoals bijvoorbeeld bij een 68000 zn meerlagen trap-systeem.

Een Assembly programma maken voor een Intel x86 processor is helemaal niet zo moeilijk en je kunt ook heel wat realiseren, maar ga je een stap verder richting protected mode dan wordt het opeens een heel stuk moeilijker.

[Lamborghini]

Verwijderd schreef op 09 February 2003 @ 01:29:
[...]
de 32-bitters, zijn dat nog steeds de 68000's ???

Yep

Verwijderd schreef op 09 February 2003 @ 02:45:
[...]
Moeilijke bij een 32-bitter is puur dat deze meer mogelijkheden heeft en vaak niet alles onder een dak heeft zoals een 8-bitter (AVR bv), waarbij je dan natuurlijk al die mogelijkheden ook gaat gebruiken, zoals bijvoorbeeld bij een 68000 zn meerlagen trap-systeem.

Idd, en omdat het een processor en geen controller is moet je heel wat meer aansturen. Ook heb je dat gezeur met data adressering op even adressen, en de instructieset is een stuk groter.

Je kunt ook niet zomaar iets aansluiten aan dat ding. Je moet eerst de timing bestuderen en uitrekenen alvorens zomaar wat aan te sluiten. En externe signalen generenen voor bijvoorbeeld interrupt levels is ook redelijk complex vergeleken met een 8 bit µcontrollertje.

[Verwijderd]

Aangezien ik hiervoor geen nieuw topic wil openen en hier de juiste kenners zitten, de volgende vraag:

Ben momenteel bezig met een 68000 based board:


Weet er iemand hoe ik gemakkelijk een D/A convertor kan adresseren aan de proc?
Kheb ook een MAX232 erop zitten. < serieel! 'tmoet zijn de 6821 PIA

Bedoeling is om melodietjes in de EEPROM te stockeren en die te laten weergeven.

[ Voor 5% gewijzigd door Verwijderd op 10-02-2003 06:40 ]

[miniK0bo]

zou iemand me kunnen uitleggen wat 32bits nou precies inhoudt en wat je met een 32bits microcontroller beter/sneller kan doen dan met een 8bits microcontroller?

[Verwijderd]

miniK0bo schreef op 09 February 2003 @ 22:48:
zou iemand me kunnen uitleggen wat 32bits nou precies inhoudt en wat je met een 32bits microcontroller beter/sneller kan doen dan met een 8bits microcontroller?

Met x bits moet je vooral kijken naar de interne registers, die zijn dan namelijk x groot, ook is de alu (de mathematische eenheid) intern ook x groot etc. Kort door de bocht is een 32 bitter een schaalvergroting van een 8 bitter.

timdeh een 68000 had toch de IO space in het geheugenbereik, die D/A zou je dus direct kunnen aansluiten, zie de betere 68000 boeken en hoe je daar periferie kunt aansluiten (sorrie ben geen 68000-specialist, moet IK ook de boeken voor nakijken). Is volgens mij allemaal hetzelfde voor de 6800 en 68000 serie hoe je zoiets doet, niet moeilijk dus.

PS wat heeft een MAX232 hiermee te maken?
PSS dus je gaat de inhoud vanuit EEPROM in het RAM zetten en van daar uit dan die DAC aansturen.
PSSS van dat printje, heb je daar ook een foto van de achterkant ?(dat moet wel een spagetti zijn die achterkant)

[ Voor 40% gewijzigd door Verwijderd op 09-02-2003 23:06 ]

[Verwijderd]

een paar webcam pics; tis niet echt een spaghetti :




De adresdecodering zit in een GAL16V8C, maar die heb ik niet geschreven. Dus weet ik ook niet exact hoe ik een DAC moet adresseren rechtstreeks.

Wat wel mogelijk is, is de PIA (parallel, dual 8bit) gebruiken om een DAC aan te spreken.

[Lamborghini]

miniK0bo schreef op 09 February 2003 @ 22:48:
zou iemand me kunnen uitleggen wat 32bits nou precies inhoudt en wat je met een 32bits microcontroller beter/sneller kan doen dan met een 8bits microcontroller?

Voor het geval je de uitleg van CrazyPro niet volgt. Een 32 bits processor heeft breedere datacomponenten en kan dus in dezelfde tijd meer bits bewerken.

[Verwijderd]

Lamborghini schreef op 10 februari 2003 @ 11:46:
[...]

Voor het geval je de uitleg van CrazyPro niet volgt. Een 32 bits processor heeft breedere datacomponenten en kan dus in dezelfde tijd meer bits bewerken.

Leuke uitleg, maar duidelijker bredere datacomponenten in dezelfde tijd meer bits verwerken dat kan beter als jij het duidelijker wil uitleggen.

[Verwijderd]

@Lamborghini

32 bit:
- De motorola 68000 is 32bit intern en 16bit extern:
databus 16bit uitwending = 16 draden
adresbus 24bit= 24draden (ik hou geen rekening met UDS/LDS ~ A0)
32bit intern = als je het geheugenmodel bekijkt, zie je dat adres/dataregisters maximum 32bit kunnen zijn.

Dit betekent dus dat op de databus maximum 16bit tegelijk kan komen, dus wil de cpu 32bit ophalen, zal hij min 2 cycli erover doen (zonder opcode in rekening te brengen).
Intern kan hij dus per cycli 32bit tegelijk behandelen. M.a.w een 68000 kan ook gerust met 128bit rekenen, maar dat zal meer cycli vergen van de cpu > trager.

Misschien een gemakkelijker model waarmee je kunt werken om de verklaring van 32bit te zoeken.

[Lamborghini]

Verwijderd schreef op 10 februari 2003 @ 14:27:
[...]
Leuke uitleg, maar duidelijker bredere datacomponenten in dezelfde tijd meer bits verwerken dat kan beter als jij het duidelijker wil uitleggen.

Het was niet mijn bedoeling om jouw uitleg niet nuttig te verklaren hoor.
De mijne was gewoon een korte andere verwoording van de jouwe.

Verwijderd schreef op 10 February 2003 @ 14:50:
@Lamborghini

32 bit:
- De motorola 68000 is 32bit intern en 16bit extern:
databus 16bit uitwending = 16 draden
adresbus 24bit= 24draden (ik hou geen rekening met UDS/LDS ~ A0)
32bit intern = als je het geheugenmodel bekijkt, zie je dat adres/dataregisters maximum 32bit kunnen zijn.

Dit betekent dus dat op de databus maximum 16bit tegelijk kan komen, dus wil de cpu 32bit ophalen, zal hij min 2 cycli erover doen (zonder opcode in rekening te brengen).
Intern kan hij dus per cycli 32bit tegelijk behandelen. M.a.w een 68000 kan ook gerust met 128bit rekenen, maar dat zal meer cycli vergen van de cpu > trager.

Misschien een gemakkelijker model waarmee je kunt werken om de verklaring van 32bit te zoeken.

I know, ik ken die interne hardware en externe signalen van de 68000 (en de 68020 en 68040).

Nog over die aansturing van de DAC via de GAL16V8C. Je kunt kijken welke datalijnen de GAL ingaan. Maar dan nog weet je niet welke combinatie van signalen die gebruikt bij het selecteren van zijn uitgang. Heb je geen documentatie ofzo waar je dat in op kan zoeken over dat bord wat je hebt?
Je kunt je beter meteen gaan richten op die PIA, omdat dat wel gaat werken.

[ Voor 32% gewijzigd door Lamborghini op 10-02-2003 17:11 ]

[Verwijderd]

Lamborghini schreef op 10 February 2003 @ 17:03:
[...]

Het was niet mijn bedoeling om jouw uitleg niet nuttig te verklaren hoor.
De mijne was gewoon een korte andere verwoording van de jouwe.

Was ook niet mijn weerwoord op jou, dacht alleen dat de 32-bit noob er op die manier niet meer van ging begrijpen, maar proberen kunnen we altijd

[...]

I know, ik ken die interne hardware en externe signalen van de 68000 (en de 68020 en 68040).

Nog over die aansturing van de DAC via de GAL16V8C. Je kunt kijken welke datalijnen de GAL ingaan. Maar dan nog weet je niet welke combinatie van signalen die gebruikt bij het selecteren van zijn uitgang. Heb je geen documentatie ofzo waar je dat in op kan zoeken over dat bord wat je hebt?
Je kunt je beter meteen gaan richten op die PIA, omdat dat wel gaat werken.

Die GAL16V8C zal spedifiek gemaakt zijn voor de verdere IO die je er in hebt zitten, het is wat ik me zo kan denken een simpele adres decoder (chip select), zodat je periferie in een bepaald adres-domein geplaatst kan worden.

Wil je die DAC gaan gebruiken, dan moet je een aparte adresdecoder maken, die kan specifiek zijn op een bepaald adres (alleen op dat adres kun je de data van de DAC teruglezen), of je neemt het ruimer (kun je met een AND-poort IC maken) en dan zeg je dat als adreslijn A17, A16, A15, etc. en de Write actief zijn, dan schrijf je naar de DAC (en dat is weer een gebied waar geen geheugen of andere periferie zit).

[ Voor 2% gewijzigd door Verwijderd op 10-02-2003 18:52 . Reden: hffadfhasghijghhasjhfjhdfhasgshsigh ]

[ND863]

Verwijderd schreef op 10 February 2003 @ 06:49:
een paar webcam pics; tis niet echt een spaghetti :

[afbeelding]
[afbeelding]

De adresdecodering zit in een GAL16V8C, maar die heb ik niet geschreven. Dus weet ik ook niet exact hoe ik een DAC moet adresseren rechtstreeks.

Wat wel mogelijk is, is de PIA (parallel, dual 8bit) gebruiken om een DAC aan te spreken.

[off topic]
Mag ik aan je vragen hoe jij kleine stukjes kabels de uiteindjes eraf stript, zonder dat de hele kabel met deuken cq vouwen ligt?

[Benadski]

ND schreef op 10 februari 2003 @ 19:19:
[...]

[off topic]
Mag ik aan je vragen hoe jij kleine stukjes kabels de uiteindjes eraf stript, zonder dat de hele kabel met deuken cq vouwen ligt?

Ik doe het altijd zo:

Eerst stip ik een heel stuk, dan strip ik nog eens, maar dan afgemeten op de lengte die ik wil van het isoleer stuk. Strip voorzichtig zodat het plastic nog om de kabel zit, schuif het daarna naar het uiteinde en knip het af! Je hebt dan een net gestript klein draadje!

[Verwijderd]

@ND:
Eerst alle IC-voeten bevestigd met voldoende soldeersel.

ik ontmantel niets Er zit nu al tegen de 24meter draad op die ik op volgende manier bevestig: uiteinde aan een pin solderen. Vervolgens de 2e pin zoeken en dan de draad tegen de pin drukken, soldeerbout ertegen (isolatie smelt) en zo heb ik een verbinding gemaakt. Dan knip je de draad door.
Indien ik draden zou afknippen op maat, zou het onbegonnen werk zijn

[ Voor 8% gewijzigd door Verwijderd op 10-02-2003 19:35 ]

[miniK0bo]

ja lekker gezond al dat smeulende plastic, dan knip ik alles wel een beetje op maat