Nieuw project aanvangen


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.

bprosman

Golden Member

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

De jongere generatie loopt veel te vaak zijn PIC achterna.

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.

It is so simple to be happy, but it is so difficult to be simple
bprosman

Golden Member

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 11 juni 2008 12:57:24 (14%)]

De jongere generatie loopt veel te vaak zijn PIC achterna.

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

bprosman

Golden Member

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.

De jongere generatie loopt veel te vaak zijn PIC achterna.
GJ_

Moderator

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

bprosman

Golden Member

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

De jongere generatie loopt veel te vaak zijn PIC achterna.

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 11 juni 2008 13:47:11 (17%)]

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

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

bprosman

Golden Member

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,

Klopt maar ik blijf bij het feit dat het gemakkelijker is gestructureerd werken tijdelijk los te laten om zo af en toe "meters te maken" dan iemand die zn hele leven ongestructureerd bezig is te laten documenteren.

Dat deden ze dus niet dus ik heb net een nieuwe baas die ontzettend blij is

*slaat een kruisje voor diegene die je oude project over moet nemen*

Groeten, Bram

[Bericht gewijzigd door bprosman op 11 juni 2008 13:44:34 (19%)]

De jongere generatie loopt veel te vaak zijn PIC achterna.

@GJ:
Lekker veel strucktuur, dat werkt voor anderen maar ook voor jezelf lekkerder dan een spinneweb/wirwar boel:)

Een atx voeding is geen labvoeding, en je kunt er geen auto mee starten ook

Voor zij die een digitale voorbereiding maken, kunnen jullie eens een voorbeeld posten?

bprosman

Golden Member

Ik kan je om copyright redenen helaas geen document posten maar hier staat een link die aardig gestructureerd te werk gaat :

http://www.airborn.com.au/method/index.html
http://www.airborn.com.au/spec/index.html

Groeten , Bram

De jongere generatie loopt veel te vaak zijn PIC achterna.
GJ_

Moderator

Het kan natuurlijk zijn dat ik iets over het hoofd gezien heb maar gaat het om een bepaalt soort project of is het meer in het algemeen? Een printje voor de hobby vereist toch een wat andere aanpak dan een komplete machine.

Overigens ben je bij die machine (bij bedrijfsmatig gebruik) zelfs verplicht om uitgebreid te documenteren.

Henry S.

Moderator

-hersenscheten, ontstaan op de meest vreemde momenten, ook in het kleinste kamertje ;)
-kladje met eisen
-veel bestaat al dus het archief door en online zoeken, zoeken, en zoeken
-bestaande ontwerpen vergelijken indien aanwezig, anders 'from scratch'.
-datasheets doorneuzen, en meteen controleren op beschikbaarheid.
-ruwe tekening op papier
-indien nodig de eerste bestellingen
-breadboarden of op gaatjesprint ideen uitwerken
-tekening aanpassen tot het aan de eisen voldoet (of op de plank gooien wegens tijdgebrek/onvolkomenheden, de hersenscheten werken door dus vaak later een vervolg)
-eventuele bestellingen plaatsen
-net schema + layout (als het de moeite waard is natuurlijk)
-daarbij aan de behuizing denkend!
-print(en) bouwen & testen
-eventueel finetunen
-inbouwen, gebruiken
-en vervolgens weer die verrekte hersenscheten... versie 2... (of niet ;)).
-Documentie: Alle aantekeningen bij elkaar in een map houden, maar dat blijft er vaak bij...

73's de PA2HS - ik ben een radiohead, De 2019 CO labvoeding.

Op 11 juni 2008 18:01:28 schreef GJ_:
Het kan natuurlijk zijn dat ik iets over het hoofd gezien heb maar gaat het om een bepaalt soort project of is het meer in het algemeen? Een printje voor de hobby vereist toch een wat andere aanpak dan een komplete machine.

Overigens ben je bij die machine (bij bedrijfsmatig gebruik) zelfs verplicht om uitgebreid te documenteren.

Meer in het algemeen, geen hobbyprintje..

ik pas over het algemeen voor projecten 2 manieren toe, een is die zoals henry zo'n beetje beschrijft, eerst alles bedenken, vervolgens ontwerpen, testen, uiteindelijke ontwerp maken, onderdelen bestellen e.d. en dat maken. Echter, als je niet de tijd of het geld hebt om de meest geschikte onderdelen te kopen pas ik een andere methode doe, de engelse "wing it" methode :). Daarbij bedenk ik iets, vervolgens loop ik 1 van mijn werkplekken binnen, zoek geschikte dingen uit en begin met bouwen, stukje bij beetje. Soms ontkom je er dan niet aan om iets te kopen, maar met creatief denken kom je ver.
Uiteindelijk staat er dan iets wat jij hebt gemaakt, enigzins aan je eisen voldoet en werkt. Veelal zien je eerste projecten er niet zo best uit en zullen misschien niet eens (goed) werken, maar naarmate je verder komt zul je beter worden en gaat het er steeds beter uitzien. Echter is dit "on the fly" maken van projecten niet echt geschikt voor iets buiten hobbymatige dingen, en als je wat meer geld hebt is het beter om alles van tevoren te ontwerpen.

Overigens is het wel ontzettend leerzaam en erg leuk :).

Take a parachute, and jump!
GJ_

Moderator

In het geval van een eenvoudige machine:
1)met alle partijen bekijken wat het doel van de machine is
2)een grof plan maken (met de bijbehorende calculatie en planning)
3)samen met de WTB mensen een uitgewerkt plan maken:
-hoeveel initiatoren
-actuatoren
-enz
-en uiteraard de exacte werking min of meer vastleggen.
-veiligheid, voorschotje op TDC, wie gaat de CE verklaring ondertekenen enz.

vanaf hier zijn er twee parallele processen: ET en WTB waarbij uiteraard veel overleg is (dagelijk met veel koffie)

ET:
4)schakelkast enigineeren
5)schema's tekenen
6)materiaal bestellen (sommige delen al eerder ivm levertijden)
7)bouwen
8)programmeren

WTB:
4)engineering
5)tekenen (3D)
6)materiaal bestellen
7)fabricage
8)montage

Hier zit je zo'n beetje op het punt dat e.e.a weer samen gaat vallen

9)aansluiten
10)proefdraaien
11)aanpassen/wijzigen
12)de nog onbehandelde delen coaten, hardverchromen, veiligheidsvoorzieningen monteren enz

13)installatie bij de klant
14)opstarten

intussen moeten de manuals en de rest van de documentatie natuurlijk wel op orde zijn, evenals de CE verklaring (als dit nodig is tenminste)

15)opleveren

Ik vind het "on the fly" maken (voor hobby werk) veel leuker dan alles netjes te doen. Vooral het gebruiken van de onderdelen die je toevallig voorhanden hebt, maken het een uitdaging. Soms ga ik zover dat ik zelfs de weerstandjes van een sloop print soldeer, zodat een klein projectje echt helemaal uit gerecyclede onderdelen bestaat, terwijl ik de benodigde weerstanden gewoon nieuw op de schap heb liggen.

Dat vind ik gewoon veel leuker dan ontwerpen, tekenen, etsen, onderdelen bestellen en zo. Je kunt dan ook nog veel gemakkelijker iets aanpassen als dat nodig is.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
GJ_

Moderator

Dat gebeurt hier bij hobbyprojectjes net zo. En dat kun je aan het eindresultaat meestal wel zien ook :)

free_electron

Silicon Member

in volgorde

1) pen en papier.
2) I/O , connectoren , protectie ,
3) raming van 'voeding' budget : hoeveel watts
4) user interface ( display en user input :toetsen , encoders etc).
5) memory benodigdheden.
6) cpu / fpga
7) tune de digitale voeding in. ( ga op zoek naar datasheets voor bruikbare switchers . je hebt digitaal achter de rug )
8) tijd voor analoog ...
9) tune de analoge voeding in

hier gekomen heb je alle datasheets van alles wat je gaat gebruiken.
schematic editor opstarten en tekenen maar.
het echte designwerk gebeurt tijdens schematic entry.
ik krijg de beste ideeen terwijl ik met het schema van een bepaald blok bezig ben. schema tekenen is rustgevend voor mij. ik denk helderst op dat moment.
ditto voor pcb layout.

Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM

Okay,

bedankt voor de reacties; ik ben odt ad slag met MS Visio en MS Word. Ik post later wel eens wat!

edit:

Eerste poging van een blokschema voor 't nieuw project:

http://users.pandora.be/chs/Temp/Blokschema_1st.pdf

[Bericht gewijzigd door Tech_Makes_Sense op 17 juni 2008 15:54:17 (37%)]