Nieuw project aanvangen

Ik begin met een leeg wit blad en een potlood. En dan begin ik volop te brainstormen, zo wat ideeen op papier zetten.

En dan ga ik op internet op zoek naar welke IC's, ... hiervoor bestaan en vergelijk ik een paar. En als ik dan gevonden heb wat ik denk dat het wordt begin ik aan de schema's.

Blokschema's teken ik meestal niet omdat mijn schakelingen daar ook niet ingewikkeld genoeg voor zijn .

Dat is bij ieder project toch anders.
In ieder geval moet je beginnen met je probleem. Wat wil ik maken?
Als het een project is waar je een microcontroller voor nodig hebt dan zou ik altijd beginnen met een flowchart.

Dan is het ontwerp tijd!:D schema's maken, googlen naar schema's, datasheets lezen en simuleren.

Eindontwerp testen (breadboard/testprint).
En dan je eindprint en evt inbouwen.

effe een vraagje tussendoor.
wat houd een flowchart precies in dan. kon het niet echt vinden.

timo

Kijk eens op google. Eventueel bij afbeeldingen. Het is een diagram waarin je kan zien wat (in dit geval) je programma eerst moet doen en wat er daarna moet gebeuren.

Het ligt vooral aan de complexiteit van het project en je eigen kennis en ervaring. Voor een simpel schakelingetje op een experimenteerboard teken ik met de hand even een schema, en de layout komt wel goed terwijl ik aan het solderen ben.

Flowcharts voor software teken ik eigenlijk nooit, ik heb de grote lijnen in m'n hoofd en de details werk ik uit terwijl ik de code aan het schrijven ben. Verder werk ik veel met textfiles met ongeordende gedachtes en aantekeningen.

Als je nog niet zoveel ervaring hebt, is het beter om iets meer structuur aan te brengen, voordat je begint met de implementatie. Eerst onderzoek doen, schema's en flowcharts tekenen, proberen op breadboard of iets dergelijks, en dan pas een print gaan tekenen en maken.

Bij mij gaat het meestal ook om microcontroller projecten, en begin het project te tekenen als 1 "Black Box". Vervolgens definieer ik mijn ingangs en uitgangs signalen (wat gaat er in, wat moet er uitkomen).

Dan uitwerken, zijn er "signal conditioners" nodig, ADC, opto-couplers aan de ingang, een ledje of relais aan de uitgang met transistoren?, ULN2803 ?.

De bediening uitwerken, ledjes, toetsen, LCD, RS232, enzovoort.

Vervolgens zoek ik er een processor bij, een ATTINY2313 ? , een AT89C51ED2 ?, een ATMEGA32/128 ?, meestal gebaseerd op hoeveelheid flash en aantal I/O lijnen (inderdaad GEEN PIC ). Snelheid in in de meeste van mijn projectjes niet zo'n issue. Bij kleine(re) processors en veel I/O grijp ik ook regelmatig naar I/O chips op I2C.

Dan inderdaad een Flowchart ( volgens mij heet dat een Programma Stroom Diagram in het Nederlands) met wat het programma moet doen, eventuele interrupts, timers etc.

Dit alles zet ik op papier.

Dan wordt het prototype in elkaar gesoldeerd , in 99.9% van de gevallen op gaatjesprint eerst en getest , de basisroutines voor LCD, I2C, keyboard, timers etc heb ik inmiddels al wel liggen.

Pas DAN begin ik aan het "echte" programma. Het "raamwerk" met de basisroutines ligt er dan al.

Als je nog niet zoveel ervaring hebt, is het beter om iets meer structuur aan te brengen

Mijn ervaring inmiddels is hoe MEER ervaring je hebt hoe MEER structuur je aan gaat brengen omdat je als gevolg van ongeorganiseerd werken vaak dingen over t hoofd ziet die later wel eens aleen OF heel moeilijk OF op een niet erg nette manier op kunt lossen en zo je neus stoot.

Oh ja, tools.

Voor documenten Word (wat een verassing ), voor blokschema's en flowcharts Visio.
Om snel even wat hardware te testen Bascom (is er voor AVR en 8051).
Voor de software meestal de Keil compiler omdat 8051 toch mijn voorkeur heeft, of GCC.
Voor de schema's en PCB's Protel 99SE en af en toe Altium Designer omdat Protel wat probleempjes heeft onder Vista .

Groeten , Bram

[Bericht gewijzigd door bprosman op woensdag 11 juni 2008 11:00:57 (10%)

-ik noteer wat het moet doen
-welke gebruiker interface er moet zijn
-welke ingangen en uitgangen er moeten zijn
-ik verdeel het probleem in basisblokken
-ik gebruik openoffice draw voor eens een flowchart of blokschema te tekenen, dit is een goed, gratis, gebruiksvriendelijk en veelzijdig tekenprogramma.
-als het schema zo ongeveer in orde bouw je eens een prototype
-ik test zowat in de meeste gevallen de opbouwende deelschakelingen appart
-maak verbeteringen door baantjes door te knippen, om te leiden, een tweede printje met verbetering er tussen te brengen, enzovoort tot je het gewenste resultaat hebt
-als uw prototype op punt staat en uitvoerig getest is, teken je de definitieve schema's en printen met alle wijzigingen er in vervat

Als er me nog wat invalt, zal ik het erbij zetten.

beperk verder zo veel mogelijk het gebruik van simulatieprogramma's waar je kan en werk in plaats daarvan zoveel mogelijk op experimenteerprinten, breadboards, gaatjesprinten en meet echte elektronische signalen.

Simulatieprogramma's geven nooit een 100% waarheidsgetrouw beeld van de realiteit.

je vertrekt vanuit het standpunt "dit wil ik maken"
en dan bekijk je hoe het er praktisch moet uitzien
hoofdzaken van bijzaken scheiden: wat moet het toestel zeker kunnen, wat is enkel leuk dat het kan.

deze eisen gooi je in een blokschema

dat bekijk je dan vanuit zoveel mogelijke denksporen.

vervolgens kies de beste methodes eruit en zoek je op IC's die 1 of meerdere functies kunnen uitvoeren.

bij µc maak je ook al een flowchart.

en dan bouw je het ontwerp van hard en software rond je IC's

rest je enkel nog te testen en praktisch te realiseren

Jullie werken allemaal behoorlijk gestructureerd..

Hier is het vaak een kwestie van

1. leuk schema / idee vinden
2. schema aanpassen / maken / datasheets van de gebruikte onderdelen zoeken en gebruiken
3. Alvast een beetje naar de software kijken met betrekking op pinbezetting indien van toepassing
4. Layout fabriceren
5. Software afmaken indien nodig (flowchart? Dus niet..)
6. Hardware fabriceren
7. Testen en waarschijnlijk een tweede versie fabriceren

Ergens daartussen hoort nog bestellen van rommel en behuizing maken.

Soms gaat het ook helemaal anders, ligt er maar net aan waar ik zin in heb.

Testen en waarschijnlijk een tweede versie fabriceren

Dat proberen gestructureerde mensen te voorkomen

Op 11 juni 2008 10:42:54 schreef SparkyGSX:
Flowcharts voor software teken ik eigenlijk nooit, ik heb de grote lijnen in m'n hoofd en de details werk ik uit terwijl ik de code aan het schrijven ben....

Als je nog niet zoveel ervaring hebt, is het beter om iets meer structuur aan te brengen..

Hier snap ik niks van. Juist als je wat ervaring hebt weet je dat het van belang is structuur aan te brengen. Een flink PLC programma bv schrijven "uit je hoofd" is een garantie voor een ongehoorde puinhoop en slecht werkende programma's.
Dus zonder onaardig te willen doen zou ik bijna concluderen dat je zelf ook nog wat ervaring mist. Daar moet ik eerlijkheidshalve aan toevoegen dat ik zelf bij een hobby PIC of propellor project meestal ook maar wat aanklooi.

(ik vat het niet onaardig op)

Ik programmeer intussen al een jaartje of 12, in het begin natuurlijk vanwege compleet gebrek aan kennis, ervaring en jonge leeftijd (was toen 13) zeer amateuristisch.

Intussen werk ik, naast mijn studie, al 7 jaar in de industriële automatisering, waar ik het aantal projecten al niet meer kan tellen. Bij al die projecten is er nog nooit een geweest die mislukt is.

Voor de PLC's houd ik er een zeer onorthodoxe methode op na, die al vele jaren prefect werkt; ik schrijf voor elk stukje van een proces een eenvoudige state machine, die op zo weinig mogelijk plaatsen onderling communiceren. Dus geen massa's merkertjes waar je never nooit meer uit gaat komen. Elk van die state machines is zo eenvoudig dat je ze uit het hoofd kunt schrijven, en gezamenlijk besturen ze de hele machine. Over de uitgangen denk ik niet eens na voordat ik bij de machine sta; dan vul ik een paar tabellen met bitmaskers (eentje voor elke state van elke state machine).

Op deze manier is het programma opgebouwd uit een aantal kleine, grotendeels onafhankelijke blokjes, waardoor alles simpel blijft.

Sommige mensen hebben een strakke structuur nodig om iets voor elkaar te kunnen krijgen, en anderen kunnen het zonder uitvoerige planning toch gestructureerd oplossen. Natuurlijk kom je jezelf af en toe tegen, maar ook als je alles strak plant zie je wel eens dingen over het hoofd.

Ik hang vooral ook de KIF methode aan.

Of ik begin met een brainstorm, veel datasheet lezen als er een speciale functie IC nodig is en dan gewoon onderdelen op een breadboard prikken.
Op internet wat principe schakelingen opzoeken in datasheets indien nodig en on-the-fly de software voor bijv. een pic inmekaar bakken.

Software flowcharts ben ik nog nooit aan toe gekomen voor microcontroller projectjes.

Waar GJ een sterk punt heeft t.a.v. bijvoorbeeld PLC toepassingen, moeten we ons realiseren dat er een groot verschil is met professionele electronica en hobbywerk.
Bij mij komen veel projecten ook niet helemaal af bijvoorbeeld...(of blijven on-ingebouwd) dat gaat professioneel ook ff niet lukken zegmaar.

Sommige mensen hebben een strakke structuur nodig om iets voor elkaar te kunnen krijgen

Waarbij er nog een wereld van verschil zit tussen een werkend programma wat iets voor elkaar krijgt en een gestructureerd programma wat over 10 jaar ook nog te begrijpen is.

Groeten, Bram

Ik treed GJ_ bij in zijn mening.

De topcistarter heb ik hier regelmatig zien langskomen en daardoor weet ik dat deze man professioneel bezig is met elektronica. Van GJ_ weet ik ook dat hij professioneel bezig is met industriële automatisering.
Ikzelf ben ook professioneel bezig met elektronica en automatisering, dus als je mijn mening vraagt, geef ik zeker en vast een zo gestructureerd mogelijke werkwijze als advies.

Zeker als je moet samenwerken met andere mensen als een team aan een groter geheel, kan je je eigen "schrijf en soldeer het maar uit het hoofd", de natte vingermethode en de "op het goedkomen uit" werkwijze absoluut niet gebruiken.

Ik geloof daarom ook, dat in dat opzicht, de werkwijze van een hobbyproject ontwerpen hier niet zo goed opgaat.

Bovendien, als je t vanuit je school of beroep gestructureerd aangeleerd hebt of krijgt kun je dat voor een hobbyproject altijd (wat) los(ser) laten. Andersom is een stuk moeilijker.

met andere mensen als een team aan een groter geheel

Ook voor jezelf als je t na jaren nog eens terug moet lezen. Bovendien aantekeningen/documentatie bewaren scheelt een hoop opnieuw uitgevonden wielen en door ezels beschadigde stenen.

Volgende (off-topic) probleem is hoe bewaar/classificeer je oude documentatie/aantekeningen/datasheets en vooral hoe zoek je ze weer terug.

Groeten, Bram

[Bericht gewijzigd door bprosman op woensdag 11 juni 2008 12:57:24 (14%)

Ik ben al 15 jaar C/C++ programmeur en maak behoorlijk gestructureerde programma's waar ik aan de oudste al 14 jaar gewerkt heb. Klanten uitbreidingen, nieuwe protocollen; het houdt nooit op. Ik heb echter nog nooit een flowchart gemaakt buiten dan tijdens mijn opleiding omdat het moest en toen heb ik ook eerst het programma geschreven en toen de flowchart gemaakt, moest natuurlijk andersom. Kreeg wel het compliment dat mijn programma precies deed wat er in de flowchart stond en een 9 als eindcijfer

Als ik van mijn programma (die van 14 jaar) flowcharts moest gaan maken werden dat er vele tienduizenden. Daarbij is het een behoorlijk dynamisch geheel met threads/multitasking enzo, maak daar maar eens een flowchart van.

Kwa elektronica ga ik ook lekker experimenteren, breadboard meeps en als ik klaar ben en het werkt maak ik er een print voor. Het moet wel hobby blijven...

aan de oudste al 14 jaar gewerkt heb. Klanten uitbreidingen, nieuwe protocollen; het houdt nooit op. Ik heb echter nog nooit een flowchart gemaakt

Maar je maakt me ook niet wijs dat het programma niet op een andere manier gedocumenteerd is.

flowcharts moest gaan maken

Achteraf documenteren komt meestal ook niet zoveel van. Vandaar dat voor mijn beroep ik liever heb dat ze hier bij wijze van spreken 12 revisies van een document maken dan alles opleveren en "achteraf wel even" documenteren.

Maar ook nu begin ik off-topic te raken.

@sparkyGSX
Die statemachine methode van jou is prima voor de wat eenvoudiger besturingen, dat doe ik zelf ook. Een machine opdelen in kleine hapklare brokjes maakt eea lekker overzichtelijk.
Dit werkt goed voor bijvoorbeeld vulsluitmachines. Al programmerende kun je dan de documentatie bijwerken.

Voor grotere systemen is dat echter geen optie en evenmin voor systemen die met komplexe stappenprogramma? werken. Als je dan niet uitgaat van een goed uitgewerkte tekening met alle stappen loop je vast. Dat er al programmerende nog het een en ander aan versleuteld moet worden is bijna regel. En zeker dan heb je je tekeningen hard nodig.

Zeven jaar ervaring maakt overigens weinig indruk, ik weet me nog wel te herrineren hoe ik er voor stond na zeven jaar. Kom over twintig jaar nog maar eens terug;-)

Van alle projecten heb ik een of meer stofmappen met alles erin: schema's, kladjes, flowcharts, bijsluiters van fotocellen, bestelbonnen enz enz. Op de PC heb ik ook per project een directorie met alle tekeningen, software enz enz. Software versie zijn genummert met het projectnummer gevolgt door _00 voor het origineel en daarna opgenummert. Hier zit ook altijd een bestand versie.txt bij waar alle wijzigingen in beschreven staan.

Iedereen hier moet op deze manier werken en iedereen programmeerd hier op dezelfde manier. Wie er een beproefde eigen methode op na wil houden mag dat elders gaan doen.

[Bericht gewijzigd door GJ_ op woensdag 11 juni 2008 13:10:29 (27%)

Waar je intresse naar rijkt
Ik ben geinteresseerd in Audio en HF, dus als ik thuis daar wat oude rommel van heb liggen.. dan bedenk ik wat voor schakelingen ik er van of voor kan maken.

@bprosman:

Maar je maakt me ook niet wijs dat het programma niet op een andere manier gedocumenteerd is.

Nee, het is volledig niet gedocumenteerd... Maar de code is wel zo geschreven dat het uitstekend leesbaar is ook door mensen die het programma nog nooit gezien hebben. Dus de naam van een class of functie geeft exact aan wat hij doet. Variabelen hebben een sprekende naam dus niet for( i=0; i<m; i++) maar for( nRecordIndex = 0; nRecordIndex < nMaxRecord; nRecordIndex++) enzo. Zelfdocumenterende code noemen ze dat (selfexplanatory code). Zou je het moeten gaan documenteren dan is de documentatie een aantal malen groter dan de code en dat is al enkele miljoenen regels...

Dus de naam van een class of functie geeft exact aan wat hij doet.

Dat is een gewoonte die zou een programmeur minstens vanaf zn geboorte moeten hebben.

Nee, het is volledig niet gedocumenteerd...

waar ik aan de oudste al 14 jaar gewerkt heb.

Dan hoop ik in ieder geval dat je HEEL voorzichtig rijdt en dat ze je ontzettend goed in de watten leggen.

Groeten, Bram

Op 11 juni 2008 12:47:30 schreef bprosman:
[...]Waarbij er nog een wereld van verschil zit tussen een werkend programma wat iets voor elkaar krijgt en een gestructureerd programma wat over 10 jaar ook nog te begrijpen is.

Groeten, Bram

Absoluut, daarom schrijf ik bij elk stuk software (of ander deel van een project) een duidelijke uitleg van hoe en vooral waarom het in elkaar steekt, en welke voorzieningen reeds zijn getroffen voor toekomstige uitbreidingen.

Ik ben echter van mening dat het aanhouden van strakke regels zeker geen garantie geeft voor een gestructureerd eindresultaat, en andersom evenmin.

Ik ken genoeg mensen die met een heleboel regeltjes, schema's, technische specificaties en weet ik wat nog steeds een enorme berg spaghetti kunnen schrijven, en mijn persoonlijke ervaring is dat je zonder al die dingen toch zeer heldere, gestructureerde code kunt schrijven, als dat maar altijd je doel is.

@GJ_: natuurlijk, 7 jaar is nog niet bijzonder veel ervaring, maar als ik kom ook niet meer vers van de schoolbanken (al zit ik er af en toe nog, ben nog met een 2de opleiding bezig).

EDIT:
Overigens ben ik tegen zo'n directory structuur voor versies; daarvoor zijn versiebeheersystemen (CVS, subversion e.d.) uitgevonden.

Ik ga er wel altijd vanuit dat degene die mijn code leest, minstens evenveel kennis heeft van de programmeertaal. Ik ga echt niet de werking van standaard libraries documenteren in mijn programma. Iemand die alleen het boek "C voor dummies" in de kast heeft staan, hoeft niet te verwachten dat hij er iets van snapt, of iets aan kan passen.

[Bericht gewijzigd door SparkyGSX op woensdag 11 juni 2008 13:47:11 (17%)

@bprosman:

Dan hoop ik in ieder geval dat je HEEL voorzichtig rijdt en dat ze je ontzettend goed in de watten leggen

Dat deden ze dus niet dus ik heb net een nieuwe baas die ontzettend blij is met mijn vaardigheden en ervaring en me wel in de watten legt

Maar gauw weer ON-TOPIC...