PICs en draadloze verbindingen

winkeltjes geven soms een antwoord:

tik "PIC" in:

hier ook:

en dan is er nog de conrad.de .fr .be .nl

--

-- Shortwave transmissions in English, Francais, Nederlands, Deutsch, Suid-Afrikaans, Chinese, Dansk, Urdu, Cantonese, Greek, Spanish, Portuguese, ...

Omdat je met je pollen van windows zou blijven: ik zie een hoop soft op mijn ubuntu oa:

Simulator for the Microchip PIC16C84 microcontroller Nitpic is an X-based simulator for the Microchip PIC family of microcontrollers. It currently supports only the PIC16C84. This is beta software.

The S-Lang programming library, shared library subset kit This is used to develop subsets of the S-Lang shared libraries for use on custom installation floppies and in embedded systems. Unless you're making one of those, you won't need this package.

command line utility to drive a PICSTART programmer picp is a utility enabling the use of Microchip PICSTART programmers or compatible programmers such as Warp-13 or JuPic, where you would normally be required to use Windows software. The PICSTART is a low-cost hardware PIC programmer for developing custom microcontroller applications. It is faster than MPLAB, it has a comprehensive command line interface, and full source is provided under the GPL. Homepage:

Microchip PIC serial programmer software This is Picprog, a Microchip PIC microcontroller programmer software for a simple serial port device. Homepage:

etc

gewoon met "PIC" in synaptic, op zo'n 23500 pakketten...

Heil!

Kijk eens rond op

KA

Ja, maar 1 advies: neem beslist geen PIC controller (tenzij het een PIC32 is)! Voor hetzelfde geld en moeite heb je een fatsoenlijke microcontroller met ARM cpu core die je fatsoenlijk in C kunt programmeren. De LPC2000 serie van NXP is erg goed bruikbaar.

Serieel via USB. Dan kun je je apparaat nog vanuit de USB poort voeden ook. Of bluetooth. Dat kan tegenwoordig ook vrij ver komen.

( ... )

Geef eens toe dat dat een hoogst persoonlijk standpunt is, niet enkel gebaseerd op technische aspecten? Ik weet er genoeg die C als hoogst onfatsoenlijk beschouwen, en eerlijk gezegd op een 68HCS12 is assembler amper lastiger dan C, zelfs zonder makro's. 't Is allemaal een kwestie van gewoonte en van smaak en van stijl, maar verkoop aub uw gewoontes en smaak niet als absolute waarheden!

Hier ga ik graag met u akkoord (ja, dat kan ik ook...) KA

Dag, ik ben ook al weer jaren uit, maar ik zou de PIC alleen overwegen in de dikste versies. Kijk vooral ook naar Atmel. En, natuurlijk, de moderne 8751 versies, met alles aan boord, maar fysiek wat groot, misschien.

Als Pascal-adept vind ik C verschrikkelijk. Ik zal er nooit aan wennen. Met veel plezier programmeer ik mijn PIC-processors met JAL.

Och, je hebt conversieprogramma's tussen C en Pascal. En verder ben ik het met je eens, maar gedane zaken nemen nu eenmaal geen keer...

Hallo Nico en alle anderen.

Nico Coesel schreef: (...)

Bedankt voor de info. (en ook aan alle anderen die geantwoord hebben).

De enige reden dat ik de PIC vermeldde, was gewoon omdat dat boek dat ik in de bib gevonden had ("PIC microcontrollers, 50 projecten voor beginners en experts" van Bert van Dam uit de Elektuur reeks) daarover ging. Ik heb niet echt een voorkeur voor één specifieke merk van microcontroller.

Het probleem voor mij is -als je nu een beetje begint rondsurfen om informatie te vinden- dat ik niet echt het bos door de bomen zie. Er zijn nu zoveel soorten microcontrollers.

Ik zoek dus -op de eerste plaats- iets waar dat ik als beginner nog eens mee kan experimenteren. Ik werk in de informatica/netwerk branche, dus als ik nu iets moet programeren in assembler, C of java of nog een nieuwe taal; dat maakt voor mij niet zoveel uit. (De meeste programmeertalen lijken toch veel op elkaar).

Wel, dat was eigenlijk mijn 2de vraag: een beetje praktische ervaring.

Dingen zoals het volgende:

Ik vermoed dat de meeste externe ICs wel via I2C zullen aangestuurd worden, dus zal het "fysisch" wel geen al te groot probleem zijn.

Maar wat ik me dan afvraag, al de lagen die daarboven liggen (bv. in dit geval de I2C communicatie, USB en de seriele communicatie), moet je die dan compleet zelf programeren, of bestaan er daar libraries voor?

En zijn die libraries dan "algemeen" voor alle ICs bruikbaar, of zijn ze beperkt tot één specifieke microcontroller en één specifiek IC?

Dus, als je een bepaald IC gekozen heb, hoe weet je dan welke ICs je moet kopen (voor pakweg USB, bluetooth, 27/40/433/867 Mhz, ...) zodat je libraries kunt gebruiken daarvoor?

Of, omgekeerd, welke microcontroller / kit kun je gebruiken zodat je zeker bent dat je gemakkelijk ICs kunt vinden, EN waar dat er libraries voor beschikbaar zijn?

Bon, zaken zoals dat dus.

Cheerio! Kr. Bonne.

Prutsen in assembly, C compiler niet gratis, een harvard architectuur waarop je niet met standaard C bibliotheken uit de voeten kunt (het loopt al spaak bij de functie strcpy) en je hebt een ingewikkelde programmer nodig. Genoeg technische aspecten om niet voor een PIC te kiezen?

Is dat vanwege technische aspecten of te beroerd zijn om iets nieuws te leren?

Misschien is C niet ieders hobby, maar C is wel DE standaard programmeertaal voor microcontrollers en embedded systemen in het algemeen. Velen blijven bij assembly hangen omdat ze dat na veel zwoegen eindelijk door hebben. Maar als ze de tijd die ze steken in het schrijven van je programma nu eens steken in het leren van C dan zouden ze veel meer kunnen doen met hun tijd. Als je begint met een platform waarop je goed in C kunt programmeren (dus niet de PIC, 8051 of AVR), dan pluk je daar vrij snel de vruchten van. Ik heb genoeg afstudeerders voorbij zien komen die dat hebben bewezen.

En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H8) uitstekende GCC compilers beschikbaar voor niets. Met het eveneens gratis Eclipse heb je binnen no-time een ontwikkelomgeving opgetuigd waar menige commerciele microcontroller IDE in de verste verte niet aan kan tippen.

Bluetooth kun je via een RS232 poort aansturen. De werking komt enigzins overeen met een modem. Ik denk dat dat een hele eenvoudige oplossing is. Bovendien kun je de verbinding eerst testen met een PC.

Meestal beperken de libraries zich tot 1 specifieke reeks microcontrollers.

Dat is puzzelen totdat het allemaal in elkaar past voor een redelijke prijs.

Zoeken... Bij NXP (voorheen Philips) kun je voor hun microcontrollers alle documentatie en libraries van de website plukken. Wat je je bij het kiezen van een microcontroller moet afvragen:

- welke IO heb ik nodig?

- hoeveel geheugen? (ruim kiezen)

- hoe kom ik aan de software om een programma te maken?

- hoe krijg ik mijn programma in de controller?

- waar vind ik voorbeeldprogramma's / libraries

Tot hier was ik het roerend met je eens, maar:

Een AVR valt fantastisch in C te programmeren. Een 8051 in zekere zin ook, maar die wil je om andere redenen niet meer.

Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het

Gcc is *zo* brak, dat een alle-remmen-los release build van gcc, met maximale optimalisaties, vaak *langzamer* is dan een debug build van msvc. Om maar eens een zijstraat te noemen. En dat is dan op een mainstream platform als

Er bestaat een hele nette software USB stack voor de Atmel AVR. Gebruikt bitbanging om een low-speed USB1.1 device (Da's dus 1.5 mbit/s) te spelen.

Verder babbelt iedere microcontroller die een kip voor z'n neus waard is standaard RS-232.

Ik ben bang dat het dan hoe dan ook dun gezaaid gaat worden.

Maak eens een programma waarin je met strcpy en strcat een constante en niet constante character array naar een niet constant character array wilt kopieren. Dat gaat niet op een harvard architectuur zonder bijzondere (trage) pointer acrobatiek omdat de processor aan de pointer zelf niet kan zien in welke geheugen de data moet worden opgehaald/weggeschreven.

Met de 8051 en de AVR noem je 2 specifieke 8 bit platforms waarbij de

Dat lijkt me erg sterk. Dit soort stellingen komen meestal van mensen die van de ene compiler wel goed weten hoe die werkt en van de andere compiler totaal niet. 1 ding weet ik zeker: er zit veel meer tijd en energie in GCC dan in iedere andere compiler. Als GCC veel slechter presteert dan een commerciele compiler dan doe je of iets heel erg fout of je hebt heel erg veel geld betaald voor de commerciele compiler.

Ik zou je aanraden om die DCF-77 ontvanger te vervangen door een RDS of een GPS ontvanger. Uit ervaring weet ik dat die een stuk beter ontvangst hebben tegenwoordig dan DCF.

So? Het is wat minder handig, inderdaad, maar

Je ondergraaft je eigen stelling. Je wil juist een taal als C gebruiken om allerlei details over je processor te verbergen. Of wou je beweren dat MIPS lekker fijn in assembly programmeert?

Ik pak de 2 platformen die jij eerder al aan de kant had geschoven omdat je ze niet in C zou kunnen programmeren. Wat baarlijke onzin is.

En geloof me, ik ken de 8051. Heb jarenlang op de 8-bit microcontroller sales support van een bepaalde voormalige gloeilampenfabrikant in het zuiden des lands gewerkt. Je mag drie keer raden welke CPU.

En toch zie ik het keer op keer. Inmiddels weet ik hoe ik mijn C zo moet schrijven dat zelfs het stomste kindje uit de klas (Wist je overigens dat GCC een afkorting is? Staat voor GCC Can't Compile) het een beetje snapt. En zelfs dan. GCC is stom. En het ergste is nog dat het er van uitgaat dat ik *OOK* stom ben.

Veel meer tijd ja - waaronder heel veel verprutste tijd. Tijd verprutst aan het toevoegen van zinloze warnings omdat er zoetwaterprogrammeurs zijn die te stom zijn om te weten dat && boven || gaat.

Of de commerciele compiler is voor een specifieke architectuur geschreven, ipv voor zoveel mogelijk achitecturen tegelijkertijd.

Intel's icc bestaat niet voor niets, bijvoorbeeld.

Als je dat fundamentele verschil weigert te accepteren, vraag ik me af wie er nou degene is die oogkleppen op heeft.

Maar weet je wat de belangrijkste reden is waarom OP misschien beter af is met een simpele AVR? Heeft helemaal niets met architecturen, C-compilers of wat dan ook te maken, maar met een hele simpele reden:

Een Atmel AVR komt in een fijne DIL behuizing, en is gemakkelijk op een stuk gaatjesbord te solderen. Kom daar maar eens mee, met je 48 pins LQFP "low pin count" ARM. Of MIPS. Of H8. Zeker zo vriendelijk voor een hobbyist.

Dat kun je niet 1:1 vergelijken. DCF is erg gevoeling voor storingen van monitoren en tl-buizen, maar het signaal dringt wel behoorlijk goed door in gebouwen. Dat kun je van GPS niet zeggen: voor een fatsoenlijke GPS ontvangst heb je vrij zicht naar boven nodig. In een gebouw waar niet te veel storing is kan DCF best beter werken dan GPS.

RDS heb ik geen ervaring mee als tijdstandaard. Je bent afhankelijk van het kwaliteitsbesef van de technici van de zender, vrees ik.

Maar wel ten koste van performance en tegenwoordig koop je voor hetzelfde geld een veel snellere en betere microcontroller die al die truukerij niet nodig heeft. Waarom zou je nog met paard en wagen op weg gaan als je voor hetzelfde of minder geld een auto hebt?

bepaald

Het kan wel, maar je doet jezelf tekort en je loopt een keer tegen de grens aan en dan zeg je 'had ik maar...'. Been there, done that -hier spreekt ervaring-. Probeer eens functie pointers op een 8051. De Keil

Wie heeft er niet met de 8051 gewerkt, maar wat mij betreft mag het ding begraven worden.

Ik dacht dat GCC stond voor Gnu compiler collection, maar weer wat geleerd.

En dat is maar goed ook. Ook de gevorderde programmeur maakt stomme fouten.

Ik noem dat handig want dergelijke programmeurs komen bij bosjes van school. Programmeer maar lekker simpel want dan kan iemand anders het project later nog van je overnemen.

Dan snap je de opzet van GCC niet. Iedere architectuur heeft juist zijn eigen back-end met specifieke optimalisaties. Een GCC versie heeft altijd nog wel een dozijn platform specifieke opties. Alleen de voorkant is hetzelfde. Wel zo prettig als je code wilt porteren van de ene naar de andere compiler. Dan kom je erachter dat C niet altijd C is.

Kijk en vergelijk en je ziet dat GCC zich doorgaans in de top van de compilers voor een bepaalde architectuur bevind.

Eitje en je hebt er geeneens speciaal gereedschap voor nodig (hint: hoe dunner de soldeerbout, hoe lastiger je het voor jezelf maakt). Flux, een schone punt en desoldeerlitze voor de ongelukjes. Bovendien zijn er heel veel kant & klare bordjes tekoop die je zo in je project zet. Kan het nog makkelijker?

Dat klopt maar aangezien OP toch van plan was om de DCF aan de andere kant van zijn tuin te hangen leken ze me beide wel mogelijk. Wij merken trouwens op dat in computerruimtes waar vroeger de DCF ontvangst goed was de laatste jaren het ontvangst erop achteruit is gegaan... Een gevolg van meer storingen? In nieuwe installaties kiezen we er dan ook altijd voor om de internet tijd te gebruiken.