Aanschaf microcontroller etc.

Er zijn legio starterskitjes te vinden van de twee grootste spelers op de hobby-microcontroller markt: Microchip (PIC controllers) en Atmel (AVR controllers). Kijk eens rond bij de betere elektronica shops (behalve Conrad). Ik zelf heb veel ervaring met PICs, en ben nu bezig met een PIC24F 16-bitter met USB-OTG in C te programmeren.

Als je graag in C programmeerd, kan ik je de AVRs aanraden. In combinatie met de AVR-GCC compiler kom je onder linux al een heel eind. Als je windows gebruikt kom je aan je trekken met Winavr (wat ook gebruik maakt van de avr-gcc compiler). Leuke bordjes zijn overal te vinden, zoals bijvoorbeeld de AVR Butterfly. Er is echter voor elk wat wils, dus google er lekker op los

PICs in C programmeren is ook geen straf. MPLAB is gratis en kan de compiler (er is een gratis versie) integreren, en met een Pickit 3 of Microchip ontwikkelbord kun je programmeren, debuggen en testen vanuit de zelfde omgeving. Met de Pickit heb je ook meteen een logic analyzer.

PIC en AVR gaan redelijk gelijk op, eigenlijk. Daarom is de keus zo moeilijk.

Kijk eens op dez site heb daar ook mijn eigen project Robot sailboot mee gebouwd propeller is de intresantste http://www.parallax.com/

Als ik het dus goed begrijp heb ik nodig:

Een microcontroller, bijv. PIC 16F628A .
Een programmer, bijv. Wisp648 of Galva-Wisp.
Een IDE, geen idee welke, Proton misschien?!

Is dit een beetje degelijk, en goed te gebruiken voor simpele tot ingewikkelde progjes?

Ik denk dat ik eerst in basic ga programmeren, aangezien ik eerst een beetje 'kennis' wil maken met het principe. Later kan ik altijd nog naar ASM o.i.d. stappen.

Ps: Bedankt voor alle replies:)

Op 8 november 2010 22:32:40 schreef Fuzzbass:
[...]
PIC en AVR gaan redelijk gelijk op, eigenlijk.
[...]

Daarover zijn de meningen ernstig verdeeld

Als je er nog niks mee gedaan heb, raad ik je een developmentboardje aan. STK500, dragon, butterfly (google vertelt je wel meer : ) ) zijn (beetje afhankelijk van wat je uiteindelijk wilt) allemaal goed. Programmeren van die dingen is toch net even anders dan 'C op een PC', en als iets niet loopt, kan het vaak zowel een hardwarematige als een softwarematige oorzaak hebben. Voordeel van een developmentboard is dat je er vanuit kunt gaan dat de hardware wel op orde is, en dat je de fout in je software moet zoeken. Als je software dan doet wat je wilt, is de hardware zelf maken de volgende stap. Als je een AVR hebt en een programmer die wat met 'debug wire' kan, kun 'live' debuggen. Niet altijd bruikbaar omdat je timing 'stuk' gaat, maar zeker in den beginne soms erg handig. Kan net even meer dan een simulator - en je kijkt naar de echter hardware.

Verder kan ik je aanraden om met assembly te beginnen als je een controller wilt leren kennen. Programmeren kon ja al (schreef je), zeker een taal als basic is veel te afhankelijk van de runtime lib. Je leert Basic kennen, niet je controller. Alternatief is C, dat is in veel opzichten transparanter richting hardware, alhoewel het ook het nodige verbergt.
Als je snel wat in elkaar wilt frutten, is basic wellicht een goede keus.

Is "arduino" niet een mooie starterskit?

- programmer ingebouwd.
- programmas transporteerbaar naar losse chips als je projectje gaat inbouwen.
- ding kan als programmer gebruikt worden voor externe chips.
- mooie IDE om te programmeren.
- IDE verbergt wat suffe details waar je in de eerste instantie je niet mee bezig wilt houden.

Als je met PICs aan de gang gaat, wil ik je waarschuwen. D'r is welliswaar een microchip compiler beschikbaar, maar microchip doet raar over de header files (die zeggen de compiler waar bijvoorbeeld PORTA zit). Volgens microchip is dat "geheim" en mag je dat niet copieren. Dus als je ooit onder Linux met PICs aan de slag wil, begint de handleiding met: "download de developmentkit van de microchip website". Dan moet je daar headers uit gaan halen en copieren naar je systeem om de boel aan de praat te krijgen. Zo'n "kijk zo werkt het" handleiding is dan geshreven voor versie X van de Linux software en versie Y van de microchip software. En omdat de software op X.1 en Y.1 zit werkt die handleiding niet meer, en kan je de boel zelf gaan uitzoeken.

Ik ben ooit begonnen met PIC, daarna "heerlijk" op AVR overgestapt. Dat gedoe waren we toen kwijt. Toen ik jaaaaren later zag dat ik voor DSPPIC tegenwoordig ook een GCC compiler kon krijgen, heb ik een bordje gekocht met een DSPPIC er op. Maar de situatie met de headers is niet veranderd en ik heb het niet voor mekaar gekregen in de tijd die ik er voor over had om de compiler werkend te krijgen. Ik heb het opgegeven. Nooit meer Microchip processors voor mij (maar ze maken leuke ADCs en Opampjes).

P.S. ASM leren moet je gewoon NIET doen. Dat is onzin in deze tijd. Ik ben ooit begonnen met 8080 en daarna 8051 assembler. Daarna PIC. Nu ik met AVR werk heb ik daar nooit behoefte aan. Ik heb gisteren nog AVR assembler lopen posten hier op CO. Dat is door de compiler gemaakt. Ik kan het een beetje lezen, maar niet schrijven. Dat is precies genoeg om heel leuke dingen te kunnen maken.

[Bericht gewijzigd door rew op dinsdag 9 november 2010 09:06:53 (11%)]

Er zijn voor de kleine PIC's inmiddels alternatieven die wel volledig open zijn : SDCC support de meest gangbare 12F, 16F en 18F PICs inmiddels. Zie http://sdcc.sourceforge.net/ voor meer info.

Een mod van hier (KiF) heeft een aantal plus en minpunten naast elkaar gezet voor mensen die ermee willen beginnen:

http://www.kleinisfijn.nl/?page=picvsavr

Leuk om een keer door te lezen.

Veel met SDCC gewerkt, maar dan voor 8051. Vond het ding wel acceptabele assembly genereren. Geen idee hoe dat voor pic-dingen is...

Voor wat betreft die assembly ben ik het niet met rew eens. Als je een behoorlijke achtergrond hebt in assembly (zoals hij lijkt te hebben), kan ik mij goed voorstellen dat je dat niet nog en keer voor de volgende variant gaat leren. Echter, je ziet regelmatig 'broekies' van school komen, die in C(++) of java hele mooie dingen kunnen maar die je op een controller dan constructies ziet maken waarbij je denkt 'hoe verzin je het' of 'snap je zelf nou niet dat dit in alle mogelijke opzichten bagger inefficiënt is' (en nee, dat snappen ze niet, wat het zijn toch maar een paar regels code?). Ze zijn het gevoel met de onderliggende hardware volkomen kwijt (of liever: hebben het nooit gehad). f_e had er ooit nog eens een mooi verhaal over mbt. een sollicitant die iets met parity berekenen moest doen. Was wel lachwekkend.
Met wat ervaring erin, begrijp je dat een putc() 'goedkoop' is en een printf 'schreeuwend duur' (om maar een dwarsstraat te noemen).

Ik ben ooit begonnen met PIC, daarna "heerlijk" op AVR overgestapt.

Hey, dat ken ik ergens van

Ik heb code van een AVR om moeten zetten naar een PIC. De code kon opeens een resolutie aan van 640x480 real-time inlezen (RGB) ipv 320x160 (RGB)

En dat op een maar 2x zo snelle processor

AVR vs PIC. Is zo iets als Intel vs AMD.

De een heeft liever een intel de ander een AMD.

Wat code (C) komt het op hetzelfde neer, als je gewoon ANSI C schrijft werkt het zowel op AVR als op PIC. Het verschil zit hem vooral in de beschikbare tools en de community.

Ik ben pro-Microchip. Niet omdat ik iets tegen Atmel heb maar meer omdat ik ervaring heb met microchip devices, de community, website en datasheets.
Ik vind zelf de datasheets van Atmel (veel) minder prettig werken en de community kan ik ook niet lekker behappen.

Een ander voordeel wat ik vind van Microchip is het aanbod aan processoren.

Atmel heeft, weinig devices, dus weinig keus, waardoor de keus voor een microcontroller makkelijker is, maar je zal ook eerder meer krijgen dan dat je zou willen hebben (en dus meer betaald)

Microchip heeft een veel grotere scala aan microcontrollers, de een heeft die peripheral en de ander heeft weer een ander. Dit maakt de keuze maken vaak wat minder makkelijk omdat je goed moet zoeken welke microcontroller voldoet aan jouw eisen. Maar het voordeel wat je er bij hebt is dat je dan wel een uC hebt die bij jouw project past en waarbij je dus niet betaald voor features die je nooit niet zal gebruiken.

Daarbij, mocht je ooit met 16-bits uCs gaan werken, dan heeft wederom microchip (voor de hobbyist) een makkelijkere keuze. Sowieso heeft Atmel geen *true* 16-bits controller, en de kleinste variant komt in een 44-pins TQFP (SMD) verpakking.
Waarbij microchip 16-bits controllers verkoopt in DIP.

Ik heb zelf altijd al sterk het gevoel gehad dat Atmel meer op de professionele markt richt en microchip zich ook richt op de hobbyisten markt.

Wat mij opvalt is dat er telkens gepraat wordt over dat PIC+Linux niet gaat en AVR+Linux wel. Ik snap die discussie/tips niet echt, want ik zie nergens dat de OP iets doet met linux en zijn dus de tips dat PIC op linux een *Hel* is zijn volledig overbodig.

Zie:

Op 9 november 2010 09:03:22 schreef rew:Als je met PICs aan de gang gaat, wil ik je waarschuwen. D'r is welliswaar een microchip compiler beschikbaar, maar microchip doet raar over de header files .... Ik ben ooit begonnen met PIC, daarna "heerlijk" op AVR overgestapt. Dat gedoe waren we toen kwijt..

Kies wat je wil, maar luister niet naar ongerelateerde onzin verhaaltjes

also:
PICVSAVRWARS!!! LET THE GAMES COMMENCE, hehe

Waarbij microchip 16-bits controllers verkoopt in DIP

Waarschijnlijk gevoedt door uitspraken van een voormalig project manager bij ons : "Als je applicatie niet performed moet je er meer hardware tegenaan gooien" .

Groeten, Bram

AVR vs PIC. Is zo iets als Intel vs AMD.

Die vergelijking gaat redelijk mank. Ze draaien redelijk dezelfde software. Om nou een microchip-ding AVR software te laten draaien... Ik zie het niet gebeuren... Moet toch altijd wel een beetje lachen als ik hoor dat er anno 2010 nog steeds controllers gemaakt worden die hun registers in banks hebben en niet flat memory... (da's overigens anders dan de bankswitching van een 8051. Daar is over nagedacht, hoef je niet te gebruiken, maar wel verdomde handig als je er gebruik van maakt)

Atmel heeft, weinig devices, dus weinig keus, waardoor de keus voor een microcontroller makkelijker is, maar je zal ook eerder meer krijgen dan dat je zou willen hebben (en dus meer betaald

Meer betaalt dan nodig, maar nog steeds goedkoper dan een microchip ding!

Waarbij microchip 16-bits controllers verkoopt in DIP.

DIP is dood...

community kan ik ook niet lekker behappen.

Als het je om communitie gaat, neem je een 8051 core... Veel, veel meer gebruikers, veeeeeeeeeeeeeel meer tools.

Als je echt power wil pak je een 32 bits ARM, bv de stm32discovery (32Bits 128Kb flash 5Kb ram) van ST:

http://www.st.com/internet/evalboard/product/250863.jsp

Ondermeer te bestellen bij Farnell voor € 10,54 (excl BTW & verzenden)

Er zit een programmer en debugger via USB al op, en ook standaard 12bits ADC en DAC met DMA. Vergelijk dat eens met PIC of AVR boardjes ...

Te programmeren in C met de gratis Atollic compiler (geen code limiet) en ook met enige moeite onder linux (GNU-ARM).

Op 9 november 2010 11:45:48 schreef Daan Timmer:
Wat mij opvalt is dat er telkens gepraat wordt over dat PIC+Linux niet gaat en AVR+Linux wel. Ik snap die discussie/tips niet echt, want ik zie nergens dat de OP iets doet met linux en zijn dus de tips dat PIC op linux een *Hel* is zijn volledig overbodig.

Er staat nergens welk OS de TS gebruikt, dus kan je hem maar beter waarschuwen voor dit soort obstakels.

@Roland, leuk dingetje :-] (Als je idd power nodig hebt )

@Tommyboy, mijn reactie slaat op een tussen post van de OP.

Op 9 november 2010 08:35:51 schreef Eztys:
Een IDE, geen idee welke, Proton misschien?!

Hierbij ga ik er vanuit dat hij het nodige research gedaan heeft en dus weet dat Proton onder windows draait. Daaruit haal ik dan weer dat hij dus Windows gebruikt en geen linux

Scherp;)

> Een microcontroller, bijv. PIC 16F628A .

(als je voor PIC wilt gaan, doe ik ook, maar er is nix mis met AVR)

Neem een wat modernere, 16F648A als je een 18-pinner wil hebben, anders 16F887 of 16F886. Of een 18F.

> Een programmer, bijv. Wisp648 of Galva-Wisp.

of pickit2, pickit3, of welke andere porgger ook, *behalve* serieele poort proggers zonder intelligentie.

> Een IDE, geen idee welke, Proton misschien?!

Proton als je graag basic wil, maar kijk eens naar Jal of MPLAB + hiTechC. Maar een IDE heb je niet echt nodig, een editor + compiler + progger software werk ook prima.

> Is dit een beetje degelijk, en goed te gebruiken voor simpele tot ingewikkelde progjes?

ja

> Ik denk dat ik eerst in basic ga programmeren, aangezien ik eerst een beetje 'kennis' wil maken met het principe. Later kan ik altijd nog naar ASM o.i.d. stappen.

Als je 'het in je hebt' om later naar asm te stappen dan zou ik eerder voor c of Jal gaan dan voor basic.

Jongens, er zijn niet zoveel verschillen. Er zijn geen slechte controlers, alleen de een heeft liever PIC en de ander liever AVR.

Het is net als moeders en dochters, de een houd van de dochter en de ander van de moeder. geef mij de eerste maar.

Of ARM, 8051, FPGA, MSP430 enz... De wereld is veel groter dan PIC of AVR.

Op 9 november 2010 15:18:31 schreef Roland van Leusden:
Of ARM, 8051, FPGA, MSP430 enz... De wereld is veel groter dan PIC of AVR.

Maar de wereld van goed verkrijgbare DIP chips is toch wel voornamelijk PIC en AVR.

Mi beperk je je toch wel behoorlijk als je alleen maar uC in dip verpakking wilt gebruiken. Voor non-dip zijn er adapterbordjes en anders nog kant en klare bordjes zoals die van ST, TI (launchpad), Freescale (SpYder Discovery Kit), Atmel (Butterfly) enz voor prijzen waar je zelf helemaal niets voor maakt.

Op 9 november 2010 15:51:37 schreef Roland van Leusden:
Mi beperk je je toch wel behoorlijk als je alleen maar uC in dip verpakking wilt gebruiken.

Klopt. Maar voor de minder eisende toepassingen voldoen die PIC en AVR prima. Niet-dip is nu eenmaal een hobbel, voor sommigen een minscuul hobbeltje, voor anderen een enorme berg. Als je 'meer' nodg hebt dan zou ik meteen voor een 32-bitter gaan, mijn keuze zou dan een cortex zijn (of evt een LPC ARM7, omdat daar al veel meer over te vinden is).

Maar met de STM32 kun je nu wel een Harley winnen...

http://www.ebv.com/en/products/stm32-design-contest.html

Inzendingen tot 15 September 2011