🚀 go-pugleaf

winkeltjes geven soms een antwoord:

tik "PIC" in:  http://www.electronique-diffusion.fr/ boeken ook nog..

hier ook:
http://www.selectronic.fr/

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, ...
http://shortwave.homelinux.org  Updated every month or so ....
Digital TV in Europe: http://dvbt.homelinux.org 

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: http://home.pacbell.net/theposts/picmicro/

Microchip PIC serial programmer software
This is Picprog, a Microchip PIC microcontroller programmer software
for a simple serial port device.
 Homepage: http://www.iki.fi/hyvatti/pic/picprog.html

etc

gewoon met "PIC" in synaptic, op zo'n 23500 pakketten...
-- 
--
Shortwave transmissions in English, Francais, Nederlands, Deutsch,
Suid-Afrikaans, Chinese, Dansk, Urdu, Cantonese, Greek, Spanish,
Portuguese, ...
http://shortwave.homelinux.org  Updated every month or so ....
Digital TV in Europe: http://dvbt.homelinux.org 

Kristoff Bonne schreef:
> Aan allen die zijn of zullen zijn, gegroet,

Heil!

> Ik was vorige weekend in de bib van Oostende aan het rondwandelen en
> vond daar in de afdeling "techniek" een boek over PIC controllers.
> 
> Gezien ik voor mijn thesis (ondertussen 15 jaar geleden) ik een 8751
> single-chip processor gebruikt heb, wou ik wel eens zien hoe de techniek
> in die tijd geevolueerd is.

Kijk eens rond op www.elmicro.de
Zelf speel ik met veel plezier met hun 68HCS12-development kit,
is o.a. gebruikt in mijn zelfbouw-GPS-project (lachen, gieren, brullen!)

KA

Kristoff Bonne <skypro.be@kristoff.bonne> wrote:

>Aan allen die zijn of zullen zijn, gegroet,
>
>
>Ik was vorige weekend in de bib van Oostende aan het rondwandelen en
>vond daar in de afdeling "techniek" een boek over PIC controllers.
>
>Gezien ik voor mijn thesis (ondertussen 15 jaar geleden) ik een 8751
>single-chip processor gebruikt heb, wou ik wel eens zien hoe de techniek
>in die tijd geevolueerd is.
>
>
>In het boek staan een aantal leuke projectjes, maar ik ben eigenlijk
>vooral geinteresseerd in sensoren, op voorwaarde dat die een draadloze
>verbinding hebben. Overal draden e.d. is ook niet alles.
>
>Dus, eventjes een paar vraagjes:
>
>- Wat is op dit moment de gemakkelijkste en goedkoopste oplossing om
>(bv.) een draadloze sensor informatie te doen uitsturen?
>433 MHz zendertjes? Iets via I2C gestuurd?
>
>Of zijn er andere mogelijkheden?
>
>
>- Ik vermoed dat -als men informatie van meerdere sensoren wil kunnen
>inlezen op het PC- het goedkoopst is om de sensoren hun informatie te
>laten uitsturen via 433 Mhz naar ��n centrale node, die dan de
>informatie ter beschikking stelt via ethernet? (of wifi?)
>
>- Bestaan er IP-stacks voor single-chip controllers? IPv6? (ik zit hier
>thuis met een IPv6 netwerk).
>De bedoeling is om die centrale node dan te kunnen "uitvragen" via IP?

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.

>- Wat is de beste oplossing om informatie in-te-lezen op een PC?
>Ethernet? USB? Wifi?

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

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Nico Coesel schreef:

( ... )

> 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.

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!

> 
>> - Wat is de beste oplossing om informatie in-te-lezen op een PC?
>> Ethernet? USB? Wifi?
> 
> Serieel via USB. Dan kun je je apparaat nog vanuit de USB poort voeden
> ook. Of bluetooth. Dat kan tegenwoordig ook vrij ver komen.

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

On Tue, 09 Sep 2008 19:08:55 +0000, Nico Coesel wrote:

> Kristoff Bonne <skypro.be@kristoff.bonne> wrote:
> 
>>Aan allen die zijn of zullen zijn, gegroet,
>>
>>
>>Ik was vorige weekend in de bib van Oostende aan het rondwandelen en
>>vond daar in de afdeling "techniek" een boek over PIC controllers.
>>
>>Gezien ik voor mijn thesis (ondertussen 15 jaar geleden) ik een 8751
>>single-chip processor gebruikt heb, wou ik wel eens zien hoe de techniek
>>in die tijd geevolueerd is.
>>
>>
>>In het boek staan een aantal leuke projectjes, maar ik ben eigenlijk
>>vooral geinteresseerd in sensoren, op voorwaarde dat die een draadloze
>>verbinding hebben. Overal draden e.d. is ook niet alles.
>>
>>Dus, eventjes een paar vraagjes:
>>
>>- Wat is op dit moment de gemakkelijkste en goedkoopste oplossing om
>>(bv.) een draadloze sensor informatie te doen uitsturen? 433 MHz
>>zendertjes? Iets via I2C gestuurd?
>>
>>Of zijn er andere mogelijkheden?
>>
>>
>>- Ik vermoed dat -als men informatie van meerdere sensoren wil kunnen
>>inlezen op het PC- het goedkoopst is om de sensoren hun informatie te
>>laten uitsturen via 433 Mhz naar één centrale node, die dan de
>>informatie ter beschikking stelt via ethernet? (of wifi?)
>>
>>- Bestaan er IP-stacks voor single-chip controllers? IPv6? (ik zit hier
>>thuis met een IPv6 netwerk).
>>De bedoeling is om die centrale node dan te kunnen "uitvragen" via IP?
> 
> 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.
> 
>>- Wat is de beste oplossing om informatie in-te-lezen op een PC?
>>Ethernet? USB? Wifi?
> 
> Serieel via USB. Dan kun je je apparaat nog vanuit de USB poort voeden
> ook. Of bluetooth. Dat kan tegenwoordig ook vrij ver komen.

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.

-- 
Groet, salut, Wim.

On Tue, 09 Sep 2008 19:08:55 GMT, nico@puntnl.niks (Nico Coesel) wrote:

>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.

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

-- 
Change is inevitable, except from a vending machine

B! wrote:

> On Tue, 09 Sep 2008 19:08:55 GMT, nico@puntnl.niks (Nico Coesel) wrote:
> 
>>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.
> 
> 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...

On Tue, 09 Sep 2008 22:07:46 +0200, jjg wrote:

> B! wrote:
> 
>> On Tue, 09 Sep 2008 19:08:55 GMT, nico@puntnl.niks (Nico Coesel) wrote:
>> 
>>>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.
>> 
>> 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...

Assembler en C, daar doen we het mee...

-- 
Groet, salut, Wim.

Hallo Nico en alle anderen.


Nico Coesel schreef:
(...)
> 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.

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).


>> - Wat is de beste oplossing om informatie in-te-lezen op een PC?
>> Ethernet? USB? Wifi?
> Serieel via USB. Dan kun je je apparaat nog vanuit de USB poort voeden
> ook. Of bluetooth. Dat kan tegenwoordig ook vrij ver komen.

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.

jan olieslagers <adelco_gene_zever@skynet.be> wrote:

>Nico Coesel schreef:
>
>( ... )
>
>> 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.
>
>Geef eens toe dat dat een hoogst persoonlijk standpunt is,
>niet enkel gebaseerd op technische aspecten?

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?

>Ik weet er genoeg die C als hoogst onfatsoenlijk beschouwen,

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

>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!

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.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Nico Coesel (nico@puntnl.niks) schreef:

[ grote knip ]

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

> Als je begint met een platform waarop je goed in C kunt programmeren (dus
> niet de PIC, 8051 of AVR),

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

[knip]

> En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H8)
> uitstekende GCC compilers beschikbaar voor niets. 

Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het
*werkt* voor veel targets, maar daar is het dan ook mee gezegd. Performance is
(op alle targets!) vrij bedroevend. De beschikbaarheid van gcc voor een bepaald
platform (waaronder AVR, overigens) is geen reden om andere beschikbare
C-compilers die vele malen beter presteren (Keil cq Tasking voor de 8051,
CodeVision AVR voor de AVR) te negeren.

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
32-bits x86.

-- 
Martijn van Buul - pino@dohd.org 

Martijn van Buul <pino@dohd.org> wrote:

>Nico Coesel (nico@puntnl.niks) schreef:
>
>[ grote knip ]
>
>Tot hier was ik het roerend met je eens, maar:
>
>> Als je begint met een platform waarop je goed in C kunt programmeren (dus
>> niet de PIC, 8051 of AVR),
>
>Een AVR valt fantastisch in C te programmeren. Een 8051 in zekere zin
>ook, maar die wil je om andere redenen niet meer.

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.

>[knip]
>
>> En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H8)
>> uitstekende GCC compilers beschikbaar voor niets. 
>
>Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het
>*werkt* voor veel targets, maar daar is het dan ook mee gezegd. Performance is
>(op alle targets!) vrij bedroevend. De beschikbaarheid van gcc voor een bepaald
>platform (waaronder AVR, overigens) is geen reden om andere beschikbare
>C-compilers die vele malen beter presteren (Keil cq Tasking voor de 8051,
>CodeVision AVR voor de AVR) te negeren.

Met de 8051 en de AVR noem je 2 specifieke 8 bit platforms waarbij de
8051 nog eens zo krom is als een hoepel (been there, done that). Maar
voor 32 bit platforms presteert de GCC compiler zeer goed. Keil heeft
zelfs de pagina waarin ze hun ARM compiler vergeleken met GCC offline
gehaald omdat GCC in een echte test gehakt maakte van de Keil
compiler.

>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
>32-bits x86.

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.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Kristoff Bonne wrote:
> -  Ik heb hier nog een ontvangst-toestelletjes liggen die signalen van
> DCF-77 kan ontvangen en doorgeven aan een computer via de RS232 poort.
> Maar door problemen met interferentie heeft die nooit echt goed gewerkt.
> 
> Het zou misschien interessant zijn om daarvoor een PIC of single-chip
> processor te gebruiken, zodat ik die dan ver achteraan in de tuin kan
> leggen, ver weg van alle bronnen van interferentie in het huis.
> En dan de tijdsinformatie via draadloos door-te-sturen naar binnen.
> 
> 
> Wat is de beste oplossing om tijd-specifieke informatie draadloos te
> versturen?
> Kun je een 433 Mhz zendertje ook "pulsen" laten uitsturen (bv. net bij
> het begin van een minuut) of enkel "seriele bitpatronen"?
> 
> 
> 

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.

Nico Coesel (nico@puntnl.niks) schreef:
> Martijn van Buul <pino@dohd.org> wrote:
>
>>Nico Coesel (nico@puntnl.niks) schreef:
>>
>>[ grote knip ]
>>
>>Tot hier was ik het roerend met je eens, maar:
>>
>>> Als je begint met een platform waarop je goed in C kunt programmeren (dus
>>> niet de PIC, 8051 of AVR),
>>
>>Een AVR valt fantastisch in C te programmeren. Een 8051 in zekere zin
>>ook, maar die wil je om andere redenen niet meer.
>
> 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.

So? Het is wat minder handig, inderdaad, maar 
*juist omdat je in C programmeert* heb je er helemaal geen last van, omdat
de compiler dit soort details voor je oplost.

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?

>>[knip]
>>
>>> En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H8)
>>> uitstekende GCC compilers beschikbaar voor niets. 
>>
>>Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het
>>*werkt* voor veel targets, maar daar is het dan ook mee gezegd. Performance is
>>(op alle targets!) vrij bedroevend. De beschikbaarheid van gcc voor een bepaald
>>platform (waaronder AVR, overigens) is geen reden om andere beschikbare
>>C-compilers die vele malen beter presteren (Keil cq Tasking voor de 8051,
>>CodeVision AVR voor de AVR) te negeren.
>
> Met de 8051 en de AVR noem je 2 specifieke 8 bit platforms waarbij de
> 8051 nog eens zo krom is als een hoepel (been there, done that).

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.

> Maar voor 32 bit platforms presteert de GCC compiler zeer goed.

*proest*.

>>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
>>32-bits x86.
>
> 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. 

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.

> 1 ding weet ik zeker: er zit veel meer tijd en energie in GCC dan in iedere
> andere compiler.

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.

> 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.

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.

-- 
Martijn van Buul - pino@dohd.org 

wimpunk <bkcfscpmcuin@spammotel.com> wrote:
> 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.

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.

Martijn van Buul <pino@dohd.org> wrote:

>Nico Coesel (nico@puntnl.niks) schreef:
>> Martijn van Buul <pino@dohd.org> wrote:
>>
>>>Nico Coesel (nico@puntnl.niks) schreef:
>>>
>>>[ grote knip ]
>>>
>>>Tot hier was ik het roerend met je eens, maar:
>>>
>>>> Als je begint met een platform waarop je goed in C kunt programmeren (dus
>>>> niet de PIC, 8051 of AVR),
>>>
>>>Een AVR valt fantastisch in C te programmeren. Een 8051 in zekere zin
>>>ook, maar die wil je om andere redenen niet meer.
>>
>> 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.
>
>So? Het is wat minder handig, inderdaad, maar 
>*juist omdat je in C programmeert* heb je er helemaal geen last van, omdat
>de compiler dit soort details voor je oplost.

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?

>>>[knip]
>>>
>>>> En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H8)
>>>> uitstekende GCC compilers beschikbaar voor niets. 
>>>
>>>Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het
>>>*werkt* voor veel targets, maar daar is het dan ook mee gezegd. Performance is
>>>(op alle targets!) vrij bedroevend. De beschikbaarheid van gcc voor een bepaald
>>>platform (waaronder AVR, overigens) is geen reden om andere beschikbare
>>>C-compilers die vele malen beter presteren (Keil cq Tasking voor de 8051,
>>>CodeVision AVR voor de AVR) te negeren.
>>
>> Met de 8051 en de AVR noem je 2 specifieke 8 bit platforms waarbij de
>> 8051 nog eens zo krom is als een hoepel (been there, done that).
>
>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.

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
8051 compiler ondersteund dat alleen met constante functie pointers.
En zo zijn er nog wel meer dingen die je als je begint niet kunt
overzien, maar waar je wel flink last kunt krijgen. Vandaar mijn
advies om niet met 8051, PIC of AVR te beginnen ook al lijkt de DIL
behuizing zo aantrekkelijk. Dat zijn valkuilen die je uiteindelijk
flink veel tijd gaan kosten.

>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.

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

>> Maar voor 32 bit platforms presteert de GCC compiler zeer goed.
>
>*proest*.
>
>>>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
>>>32-bits x86.
>>
>> 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. 
>
>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.

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

>En zelfs dan. GCC is stom. En het ergste is nog dat het er van uitgaat
>dat ik *OOK* stom ben.

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

>> 1 ding weet ik zeker: er zit veel meer tijd en energie in GCC dan in iedere
>> andere compiler.
>
>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.

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.

>> 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.
>
>Of de commerciele compiler is voor een specifieke architectuur geschreven, ipv
>voor zoveel mogelijk achitecturen tegelijkertijd. 

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.

>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.

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

>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.

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?

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Rob wrote:
> wimpunk <bkcfscpmcuin@spammotel.com> wrote:
>> 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.
> 
> 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.

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.

On Mon, 08 Sep 2008 22:27:48 +0200, Kristoff Bonne wrote:

> Aan allen die zijn of zullen zijn, gegroet,
> 
>
> 
> -  Ik heb hier nog een ontvangst-toestelletjes liggen die signalen van
> DCF-77 kan ontvangen en doorgeven aan een computer via de RS232 poort.
> Maar door problemen met interferentie heeft die nooit echt goed gewerkt.
> 
> Het zou misschien interessant zijn om daarvoor een PIC of single-chip
> processor te gebruiken, zodat ik die dan ver achteraan in de tuin kan
> leggen, ver weg van alle bronnen van interferentie in het huis. En dan
> de tijdsinformatie via draadloos door-te-sturen naar binnen.
> 
> 
> Wat is de beste oplossing om tijd-specifieke informatie draadloos te
> versturen?
> Kun je een 433 Mhz zendertje ook "pulsen" laten uitsturen (bv. net bij
> het begin van een minuut) of enkel "seriele bitpatronen"?
> 
> 
> 
> 
> Ik weet het, veel vragen in één keer; maar ik ben dus 15 jaar
> "weggeweest". Ik moet dus nogal veel terug "inhalen". :-)
> 


Die 77 KHz onvangertjes zijn nogal gevoelig voor storingen.
Lichtdimmers, wasmachines, stofzuigers, induktiekookplaten, alles.

- Die RS232-kabel kan je makkelijk verlengen tot 20 M of zo; hou hem in 
ieder geval weg bij alles waarvan je *weet* dat het stoort (CRT, dimmers)

- ik heb de mijne afgechermd met _zilverpapier_. (Hij is nogal hoog-ohmig)

- een ferrietkraal rond de kabel.

- de software is vaak nogal recht door zee: als er per 1-minuut cyclus 
*een* puls teveel of teweinig wordt gedetekteerd, wordt de hele minuut 
verworpen.

Hier (Utrecht) werkt een simpele DCF ontvanger prima. (10-20 brakke 
minuten per etmaal, voor NTP maakt dat weinig uit, hij sloft toch wel door)

HTH,
AvK

Wim,

wimpunk schreef:
>> -  Ik heb hier nog een ontvangst-toestelletjes liggen die signalen van
>> DCF-77 kan ontvangen en doorgeven aan een computer via de RS232 poort.
>> Maar door problemen met interferentie heeft die nooit echt goed gewerkt.
>>
>> Het zou misschien interessant zijn om daarvoor een PIC of single-chip
>> processor te gebruiken, zodat ik die dan ver achteraan in de tuin kan
>> leggen, ver weg van alle bronnen van interferentie in het huis.
>> En dan de tijdsinformatie via draadloos door-te-sturen naar binnen.
>> Wat is de beste oplossing om tijd-specifieke informatie draadloos te
>> versturen?
>> Kun je een 433 Mhz zendertje ook "pulsen" laten uitsturen (bv. net bij
>> het begin van een minuut) of enkel "seriele bitpatronen"?

> 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.

Dat weet ik, maar dat is nu ook niet echt het probleem.

Voor mij is het meer te doen om het project zelf van nog eens iets te
maken, dan het echt "gebruik". Uiteindelijk, met NTP kun je
vandaag-de-dag toch gewoon syncroniseren over het net.

Ik heb nu ��nmaal gewoon het ding liggen, dus ik wil het nu eens gebruiken.
Ik kan het inderdaad ook gewoon aan een PC aansluiten (via de seriele
poort), met een lange seriele kabel om het weg te houden van de
storingsbronnen en -mits een speciale patch op de source van NTP- kan ik
het zelf gebruiken als referentie voor mijn computer als stratum 0 clock.
Maar dat is nu ��nmaal niet zo leuk.

Het is een toestelletje waar dat je eigenlijk gewoon de pulsen vanuit de
DCF-zender omzet naar een signaal-niveau op een lijn (die normaal
aangesloten wordt op de seriele poort van de computer). Dus het is iets
waar dat ik zelf de timing moet voor voorzien, zelf de DCF-77 codes
decoderen, dan op ��n of andere manier de tijd "naar buiten krijgen",
liefst op een manier die gemakkelijk uit-te-lezen is door een computer
(liefst over het internet), zodat die dan als referentie kan dienen voor
 een NTP-server.


Waar ik aan denk. Kan men niet gewoon de ruwe signalen die de module
ontvangt overbrengen naar een 433 Mhz zendertje, dus pulsen van 100 of
200 ms uitzenden op 433 Mhz. Dat is dan heel gemakkelijk te ontvangen op
een 10-tal meter afstand en dan zo terug de seriele poort van een
computer in-te-sturen.
En 433 Mhz UHF zal veel minder gestoord worden dan 77 Khz LW!


Cheerio! Kr. Bonne.