Op 17 maart 2010 19:46:11 schreef plantrekker:
Jep, pluk het ontwikkelbord maar kaal, wat heb je dan nog over? Net wat ik zo prettig vind, een kale controller (met wat ontkoppeling etc)
Ik heb mijn ontwikkelbordje sneller geconfigureerd dan jij je bordje bakt en bestukt. Een goed bordje heeft overigens ook een programmer ingebakken.
Ik heb mijn breadboard opstelling sneller klaar dan dat jij er blokken op aansluit die er niet op voorzien zijn. Gaan we zo door?
Wat maakt mij het uit of mijn programmer nu op of naast mijn bord zit.
Als iedereen meewerkt kan dit ja/nee spelletje stoppen.
Ach ja, ik doe en heb beiden gedaan. Ontwikkelen op de STK500 en op een breadbordje. Als ik met de hardware aan de slag ga om hardware conceptjes uit te werken -> breadboard (UC wel programmeren in de STK500, programmeren op breadboard is zeer foutgevoelig, contact dender van draadjes etc).
Wanneer ik hoofdzakelijk op software wil focussen, gaat 'ie in de STK500, my grafisch LCD'tje er aan gekoppeld met een 16 pins ribbon kabeltje. Geen brakke breadboard verbindingen, een gamele hardware opstelling zal het probleem niet zijn als de software niet (goed) blijkt te werken.
Zal de ervaring wel zijn.
Ieder... z'n eigen voorkeur, is dat wellicht wat ?
Op 17 maart 2010 20:24:23 schreef Simpson_Jr:
Ieder... z'n eigen voorkeur, is dat wellicht wat ?
Precies! Het wordt alleen anders als er een mening over iets wordt gegeven waarbij de argumentering slaat als een piep op een drumstel wat hier het geval was. De mening is prima, ieder heeft die. Een onderbouwing is echter geen mening maar een feitelijk iets (onderbouwen = steunen met behulp van feiten). Dat is waar ik op in ging.
Op 17 maart 2010 20:13:55 schreef MagicBox:
programmeren op breadboard is zeer foutgevoelig
Dan blink ik daar in uit, nog nooit problemen mee gehad.
Wanneer ik hoofdzakelijk op software wil focussen, gaat 'ie in de STK500
En dat is nu net waar ik het niet over heb, ik hamer al de hele tijd op de hardware afhankelijkheid.
Ik heb het ook beide gedaan, zowel met de PIC (niet lang, snel naar de AVR overgestapt) als met de ARM (STM32F10x). Op het ontwikkelbord van de ARM zat een TFT schem, SD, smartcard etc. Snel vanalles op het scherm getoverd, sd lezen. Kan ik nadien zelf zo'n applicatie bouwen? Neen, omdat het transparant is zou ik het direct allemaal moeten weten zonder in de datasheet te kijken. Maar ja het werkt dus who cares?
Met mijn headerbordje met enkel ontkoppeling dat ik aansluit op mijn breadboard daarentegen wel, weet perfect waar ik mee bezig ben en vorm mijn schema in een wip om hoe ik het wil om alles te kunnen verifiëren wat ik in de datasheet van de chip zelf lees.
Dat zal ook wel ervaring zijn.
Op 17 maart 2010 20:33:41 schreef plantrekker:
Kan ik nadien zelf zo'n applicatie bouwen? Neen, omdat het transparant is zou ik het direct allemaal moeten weten zonder in de datasheet te kijken.
Dat vat ik niet, ontwikkelbordjes zijn volledig gedocumenteerd. Mijn STK is dat, mijn CycloneIII starter kit is dat. zelfs de printlayout files zitten er bij als ik een 12-layer PCBtje zou willen maken.
PICs/AVRs op breadbordjes gaat nog wel. Met de grotere varianten en FPGAs kun je breadboard ontwikkelen wel vergeten.
Edit: Ik zag die ninja-edit wel waar je eerst zei dat je geen datasheets mocht inzien van iemand? Mijn reply sloeg juist op dat weg-geedit'e deel.
[Bericht gewijzigd door MagicBox op woensdag 17 maart 2010 20:45:28 (12%)
Op 17 maart 2010 20:43:50 schreef MagicBox:
Ik zag die ninja-edit wel waar je eerst zei dat je geen datasheets mocht inzien van iemand? Mijn reply sloeg juist op dat weg-geedit'e deel.
Ging over Henry die zei dat je geen datasheet moet opentrekken om aanpassingen te doen aan een goed ontwikkelbord, omdat die transparant is.
Maar 't ging mij daar niet over. Doen is nog wat anders dan zien. Bij een ontwikkelbord EN DAT IS MIJN MENING zie ik alleen en doe ik niet.
PICs/AVRs op breadbordjes gaat nog wel. Met de grotere varianten en FPGAs kun je breadboard ontwikkelen wel vergeten.
Tja en een elektrische huisinstallatie zal ook niet lukken op een breadboard. We hebben het hier over een µC.
Op 17 maart 2010 13:38:16 schreef LED-Maniak:
328 direct aan usb voor de bootloader? Ik neem aan met iets er tussen aka FT232 oid?
Nee, http://www.obdev.at/products/vusb/usbasploader.html
Deze werkt wel niet out of the box voor atmega328p, hij compiled, maar doet niets. Er zit een bugje in de usb driver, als je wil kan ik mijn versie wel eens diffen tegen het origineel en zeggen wat het is.
Zou ik wel waarderen, heb er nl ook wel 's mee gespeeld. De .hex + fuses vindt ik ook ok.
Heel graag uranium, vind het bijzonder interessant.
Zip file met sources en dergelijke, fuses staan in de file 'Makefile'. Er zit een .hex bij maar je zult wss toch moeten hercompileren omdat je waarschijnlijk andere settings wilt.
http://www.dump.no/files/cddc7e648a9a/atmega328p.zip
Verder moet je om het in linux te gebruiken zonder root te zijn hetvolgende doen op de terminal:
code:
sudo -i
echo 'SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",SYSFS{idVendor}=="dead", SYSFS{idProduct}=="beef", MODE="0666"'>/etc/udev/rules.d/70-avr.rules
/etc/init.d/udev restart
Opletten dat je het commando zeker juist ingeeft, als er een fout staat in die udev config wil udev niet opstarten en dan worden veel devices niet meer herkend. Geen probleem, zolang je niet reboot want dan ziet hij nite meer genoeg om nog te booten -> live linux booten vanop netwerk 
code:
avrdude -p m328p -c usbasp
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e950f
avrdude: safemode: Fuses OK
avrdude done. Thank you.