uC vs "Classic".

[Fusioxan]

kitao schreef op donderdag 02 januari 2014 @ 17:02:
[...]
Kostte me wel een dag of vier voordat ik eindelijk wist waar je Parallax-materiaal in Nederland kon krijgen.
Tegenwoordig lijken ze eieren voor hun geld te kiezen en een dealtje met de italianen te hebben gemaakt :
[afbeelding]
Robotics Shield Kit (for Arduino)
$135,-
http://www.parallax.com/product/130-35000

Die dingen hebben ze dit jaar ook bij ons op school, terwijl we vorig jaar nog urenlang hebben zitten compilen met de javelin stamp...

Maar om toch nog een beetje on-topic te blijven: voor simpele dingen wil ik zelf altijd graag zonder uC te werk gaan, maar zodra je nogal wat moet regelen (dat boebotje hierboven bijvoorbeeld) komt er toch wel een uC bij kijken.

[memphis]

mad_max234 schreef op donderdag 02 januari 2014 @ 16:51:

Andersom vaak ook.

Bij nrf24 netwerk met ph sensoren heb je perse een uC nodig en ook paar discreet ic zoals paar opamps, het opamp circuit om probe uit te lezen, maar dat circuit alleen is ook niet voldoende om data te verzenden, heb je dus uC nodig. Data op lcd krijgen is zelfs al heel stuk lastig met discreet ic's, dan met uC.

Ene kan niet zonder het andere, hangt allemaal van toepassing af.

Eens dat met zo'n complex iets een uC makkelijker zal zijn. Ik weet niet hoe het met die nrf24 is maar met een Xbee of een Radiometix is het realiseerbaar zonder. De Xbee is ook in een transparant modus te zetten waardoor signalen in de vorm van PPM, PWM of zelfs een VCO over te zenden is, zelfs in meerdere kanalen over 1 lijntje
De Radiometix 433mhz FM modules werken over een analoog kanaal, ooit een project gezien waar 2 controlers hun data parallel (maar niet tegelijk) aan de zendmodule gaven maar ieder op een eigen spanningsniveau, aan de ontvangerkant was die data weer prima uit te filteren dmv venstercomperators. Vanuit een ballon werd zo op een lage baudrate om en om GPS data, hoogte, temperatuur etc naar beneden gestuurd en weer opgesplitst naar div. apparatuur. Ik vond het wel een inventieve oplossing om storingen van bv 2 zenders op elkaar te voorkomen en een stukje energiezuinigheid van maar 1 zender te realiseren.

Maar ja, als je verder gaat zal een uC makkelijker zijn, zeker als het om digitale signaalverwerking gaat.

[kitao]

timberleek schreef op donderdag 02 januari 2014 @ 17:54:
Bedoel je dat ze kiezen voor een arduino uitbreiding?
Dat lijkt me vrij logisch. Arduino heeft een flinke userbase tegenwoordig met ontelbare shields en voorbeeldcode. Dan is het als bedrijf makkelijker om daarin mee te gaan als star een eigen platform vol te houden.

Ja, dat bedoelde ik en ik geef ze ook geen ongelijk. Ik ben ook blij dat ik dat bedrijf ben tegengekomen en ze hebben leuk en gratis instructiemateriaal. De hardware bij hun is echter vrij duur en PBasic wordt weinig gebruikt. (hier althans)
Dan hebben ze nog de propellor, een 16-bitter, en die schijnt wel met C of daar op lijkend te programmeren zijn meen ik.

Maar voorlopig heb ik genoeg aan de uno

[Dazzyreil]

Sissors schreef op donderdag 02 januari 2014 @ 14:15:
[...]

Behalve al het eerdergenoemde, heb je ook nog steeds het risico op oscillaties bij die discrete oplossing. Ik zou zeggen dat er niks mis is met de discrete oplossing, en als zijn enige doel is dat te maken dan lijkt het me denk ik het beste om daarmee te beginnen, want het is één simpel schakelingetje. Maar er zitten zeker nadelen aan, en iets op een uC gebaseerd is beter uitbreidbaar. Dus om nou te zeggen dat het totaal overbodig is...

Veel meer dan een dpdt switch heeft hij niet nodig en ja een uC is beter uitbreidbaar maar niemand weet precies wat hij nog meer wil.

Dus eigenlijk slaat heel deze discussie nergens op want iedereen gaat er vanuit hoe hij/zij het zou willen aanpakken en er zijn gewoon teveel verschillende mogelijkheden die allemaal zullen werken, toch?

[Oyster]

Dit soort discussies zijn van alle tijden en gaan nergens over. Buis - transistor. 8051 - AVR. ASM - ANSI-C, AM - FSK. Lekker doen wat je leuk vindt en blijft vinden.

[Sibylle]

Oyster schreef op vrijdag 03 januari 2014 @ 16:30:
Dit soort discussies zijn van alle tijden en gaan nergens over. Buis - transistor. 8051 - AVR. ASM - ANSI-C, AM - FSK. Lekker doen wat je leuk vindt en blijft vinden.

Ik wil hier toch nog op reageren, naar aanleiding van dit topic:
[Help] LEDs programmeren

Kijk, ik snap best dat je snel naar een uC grijpt, of zelfs Arduino of RPi oid. En dat is ook prima, wat ik echter jammer vind is dat het telkens moeilijker wordt voor nieuwelingen om de basis van elektronica te begrijpen. Veel mensen die veel advies geven, hebben zelf vooral uC ervaring en dan verdwijnt de onderliggende gedachte een beetje.

Als voorbeeld kan ik vertellen hoe ik met elektronica om ga.
Ik heb natuurkunde gestudeerd en heb elektronica als hobby erbij. Nu ben ik verliefd op programmeren en zijn veel projectjes die ik doe met een uC. Echter, op dit moment ben ik voor een groot bedrijf in Eindhoven een circuit aan het ontwerpen voor prototype (naast mijn natuurkunde werk) en dan heb ik niet zo heel veel aan mijn uC skills.
Een uC is relatief ingewikkeld en duur om in een eindproduct te zetten, het liefst werk je met goedkope en snelle analoge componenten. Ik kan zonder problemen dergelijke schakelingen ontwerpen en mijn elektronica kennis is van toegevoegde waarde.

In het lab hetzelfde, als ik een experimentje bedenk en daar een schakeling bij wil hebben dan heb ik die vaak binnen een uur gebouwd en werkende. Als ik het via uC moet doen dan heb ik eerst een uur nodig om de schakeling goed te krijgen, dan moet ik een PC interface regelen, een programma schrijven en testen... kost te veel werk en is qua onderdelen 3x zo duur.


Al met al is een uC een prima toevoeging aan je elektronica-kennis, maar meer toegevoegde waarde voor je kennis en ervaring is te halen bij de basiskennis.

[Sissors]

Ronde 2 begint

Als diegene een 555-IC pakt, krijg je daar meer elektronica kennis van? Leer je daar de basis van elektronica mee begrijpen? Ik durf wel te beweren dat nagenoeg niemand die een 555 gebruikt daadwerkelijk kijkt naar wat erin zit.

Wat voor een product handiger is hangt van de situatie en de oplage af, maar ik durf wel te beweren dat vaak een microcontroller beter is dan zelf een schakelingetje maken met 74HCs enzo: Een microcontroller neemt minder ruimte in, zal vaak zuiniger zijn, is flexibel (als de eisen weer eens veranderen, of er toch een fout in het ontwerp zat, kan je dat vaak met nieuw programma'tje oplossen), betrouwbaar en is normaal gesproken sneller om te ontwerpen, en bij kleinere oplages is dat toch belangrijk.

Analoge componenten zijn over het algemeen niet goedkoop. Wat ze wel (kunnen) zijn is snel. Daarvoor gebruik je dan ook analoog, omdat je niet anders kan: Voor RF dingen, voor power toepassingen, en voor signal conditioning voordat je een ADC in gaat (of als je uit een DAC komt), oftewel opamps/filters. Daarbuiten is eigenlijk altijd digitaal superieur (met wat hele specifieke toepassingen). En mijn baan is analoog designer, dus ik ben niet gebiased voor digitaal . Uiteraard doet dit er alleen weinig toe voor iemand die net begint.

Wat je aan het einde beschrijft is meer jouw specifieke setup en ervaring dan een gemiddelde situatie. Als je een uur nodig hebt om een schakeling te bouwen is het natuurlijk vreemd als je een uC een gedeelte laat doen en dan nog een uur nodig hebt om het te bouwen. Dingen als een PC interface wil je gewoon met een standaard bordje regelen voor een snelle prototype voor een experimentje.
Stel je voor, je hebt een 7kHz, 0.7 duty cycle blokgolf nodig voor je experiment. Ik pak een mbed, schrijf de code:

code:

#include "mbed.h"
PwmOut pwm(p24);

int main() {
  pwm.period(1/70000.0f);
  pwm = 0.7;
  while(1);
}

Compile de handel, sleep hem naar de mbed, en ik heb mijn blokgolf, met een verrekte hoge nauwkeurigheid. En daar moet ik dan waarschijnlijk een opampje/comparator/inverter achter zetten voor mijn gewenste amplitude. Jij gaat dat echt niet met een 555 ofzo sneller doen.


ECHTER:
Dit is allemaal leuk en aardig, maar hier ging het voornamelijk over hobby dingen. Dan is kwestie 1 natuurlijk: Wat vind je leuker?
In dit geval was het iemand die redelijk nieuw is, en gewoon zelf een specifiek iets wil maken. Dus dan is de vraag wat is de beste methode voor hem om dat te doen. En dan kom je in een grijs gebied uit, waarbij het afhangt van zijn ervaring, voorkeuren, specifieke toepassing, etc. Bijvoorbeeld jouw oplossing uit mijn hoofd voorziet niet in zijn knipperende ledje van de huidige week. Uiteraard kan dat wel weer, met wat xor gates en oscillatortjes, maar dat is het probleem van met discrete componenten het opbouwen: Je opstelling explodeert qua formaat met wat eisen erbij.

Overigens heb je weleens een arduino/mbed gebruikt? Dit is niet vervelend bedoelt, alleen jij hebt het ook daar in je post over de moeite om met je PC te communiceren, terwijl dat echt een kwestie is van je bordje met USB kabel verbinden en je het programmeer en seriele connectie.

[ Voor 18% gewijzigd door Sissors op 28-01-2014 11:33 ]

[mux]

Dit is bijna omgekeerde wereld. Het is juist een stuk mínder gewenst om in een eindproduct veel gebruik te maken van analoge of basic elektronica, voornamelijk omdat je dan een hele hoop ongedefinieerde states introduceert en daardoor compatibilityproblemen, extra support-tijd, reliability issues, etc.

Een eindproduct moet zo eenvoudig en gereduceerd mogelijk zijn, en niet verder. Microcontrollers en de meeste andere programmeerbare zooi heeft een goed gedefinieerd opstart-, power down- en brownout-gedrag en kan stable by design zijn. Analoge zooi moet je eindeloos lang met random garbage op testpunten injecteren voordat je er zeker van kunt zijn dat je circuit robuust en glitch-vrij is. Daarnaast is analoog vrijwel altijd duurder omdat je fundamenteel veel meer silicium nodig hebt om dezelfde complexiteit te implementeren. Zeer eenvoudige apparaten daargelaten.

[Sprite_tm]

Ik ben voor de gein eens gekeken wat de goedkoopste microcontroller vs de goedkoopste NE555 tegenwoordig nog doet. Digikey, per 50 stuks: NE555 EUR0.21, PIC10F200: EUR0.31. Voor een knipperende LED doet het elkaar dus slechts 10 cent, en hoe complexer het geheel word hoe goedkoper een microcontroller-oplossing word.

Mijn mening: voor simpele projectjes zal het niet zo heel veel uitmaken of je discreet of met een uC bezig gaat: misschien is de ervaring die je met beiden hebt wel belangrijker dan de prijs omdat je tijd duurder is dan de componenten en je veel zaken even goed digitaal als analoog op kan lossen. (For example: ik heb RC-filters in software gedaan en debouncing in hardware.) Voor grotere zaken is het meestal redelijk duidelijk: je gaat geen analoge koptelefoonversterker opbouwen vanuit een microcontroller en geen touchscreendisplay plus een zwik discrete chips pakken om een user interface te bouwen.

Voor hobbyisten zoals wij zal het vaak anders liggen. Ik heb vaak knarsetandend lopen te kijken naar de mensen die een Arduino gebruiken om iets te doen wat ze ook met een ATTiny kunnen oplossen en ben vanuit daar nooit fan van de Arduino-movement geweest, maar uiteindelijk komt het er toch op neer dat mensen pakken wat ze een combinatie van weinig moeite en geld pakken, zeker als ze niet van plan zijn een nieuwe technologie te leren. Vandaar zou ik iemand die erg goed is in Python maar geen kaas gegeten heeft van C en dat ook niet wil of kan leren bijvoorbeeld misschien best kunnen aanraden om tegen iets waar ik een AVR tegenaan zou gooien, een RasPi voor te pakken.

[Verwijderd]

Sibylle schreef op dinsdag 28 januari 2014 @ 10:38:
[...]


Een uC is relatief ingewikkeld en duur om in een eindproduct te zetten, het liefst werk je met goedkope en snelle analoge componenten.

onzin natuurlijk .. en je gebruikt iets te vaak IK imho, en dat is beslist geen valide argument, een ander doet het op zijn manier

^{en naar aanleiding van [Help] LEDs programmeren ben ik dan weer heel nieuwsgierig hoe jij dat 'effe' bouwt met goedkope analoge snelle componenten.}

[ Voor 18% gewijzigd door Verwijderd op 28-01-2014 12:21 ]

[Sibylle]

Ah, er is nog leven in dit topic

Voor de snelle experimenten en robuustere setups gebruiken we uiteraard
http://sine.ni.com/nips/cds/view/p/lang/nl/nid/209069
of
http://sine.ni.com/nips/cds/view/p/lang/nl/nid/203343
Dat is veel handiger en sneller, eventjes wat blokjes slepen in Multisim en klaar.

Ik heb het over de setups die zonder PC snel moeten werken: Eventjes visualiseren wanneer er iets gebeurt, en na 20x een extra melding geven. Dat soort dingen.
Of een signaal integreren/differentiëren en daarop iets triggeren.
Dat ga je toch niet met uC of computer doen, dat maak je gewoon ff snel analoog en klaar.

mux schreef op dinsdag 28 januari 2014 @ 11:50:
Dit is bijna omgekeerde wereld. Het is juist een stuk mínder gewenst om in een eindproduct veel gebruik te maken van analoge of basic elektronica, voornamelijk omdat je dan een hele hoop ongedefinieerde states introduceert en daardoor compatibilityproblemen, extra support-tijd, reliability issues, etc.

Een eindproduct moet zo eenvoudig en gereduceerd mogelijk zijn, en niet verder. Microcontrollers en de meeste andere programmeerbare zooi heeft een goed gedefinieerd opstart-, power down- en brownout-gedrag en kan stable by design zijn. Analoge zooi moet je eindeloos lang met random garbage op testpunten injecteren voordat je er zeker van kunt zijn dat je circuit robuust en glitch-vrij is. Daarnaast is analoog vrijwel altijd duurder omdat je fundamenteel veel meer silicium nodig hebt om dezelfde complexiteit te implementeren. Zeer eenvoudige apparaten daargelaten.

In dit geval bedoel ik dus zeer eenvoudige apparaten, maar ook zeer eenvoudige onderdelen van circuit in je apparaat.
Bijvoorbeeld de amplitude meten van een RF signaal, dat kun je met een uC of dedicated iC proberen of je gebruikt een RC en comparator. Succes met het kleiner en goedkoper krijgen tegen dezelfde specs als 5ns comparators en één R en één C.


Mijn punt is simpelweg: uC is prima, maar de echte toegevoegde waarde komt vanuit de basiskennis van elektronica. En ik vind het een slechte zaak dat tegenwoordig veel te snel naar uC wordt gegrepen als DE oplossing, terwijl dat lang niet altijd zo hoeft te zijn.

[Verwijderd]

.. en nog steeds geen valide argument gelezen om geen uP te gebruiken in [Help] LEDs programmeren
_{maar ik begrijp je punt wel, enigzins}.

[Sibylle]

Verwijderd schreef op dinsdag 28 januari 2014 @ 12:52:
.. en nog steeds geen valide argument gelezen om geen uP te gebruiken in [Help] LEDs programmeren
_{maar ik begrijp je punt wel, enigzins}.

Ik zou het zelf in dat geval ook met een uC doen

Alleen ik kom tot die conclusie omdat ik de nadelen en voordelen van wel/geen uC kan afwegen. Daarnaast is een uC voor mij amper werk qua programmeren en aan PC hangen.
Als ik dus een analoge oplossing vergelijk met een uC oplossing dan kies ik zelf voor een uC maar geen RPi of Arduino (bij een ander probleem wellicht wel).

Alleen mis ik die overweging helaas, er wordt niet nagedacht over een analoog circuit en de voordelen/nadelen daarvan.... helaas.

[Verwijderd]

zo ben ik het met je eens.

maar ik denk dat je ook een onderscheid moet maken tussen hobby en beroep ( en beroepshobbyisten)
een argument als ' ja die en die processor koop IK bij mouser per 1000 voor 4.2 cent vind ik dan weer lachwekkend als hobbyist.. maak mij dat nou uit dat die bij Conrad 80 cent kost.

[Sissors]

Sibylle schreef op dinsdag 28 januari 2014 @ 12:57:
[...]


Ik zou het zelf in dat geval ook met een uC doen

Alleen ik kom tot die conclusie omdat ik de nadelen en voordelen van wel/geen uC kan afwegen. Daarnaast is een uC voor mij amper werk qua programmeren en aan PC hangen.
Als ik dus een analoge oplossing vergelijk met een uC oplossing dan kies ik zelf voor een uC maar geen RPi of Arduino (bij een ander probleem wellicht wel).

Alleen mis ik die overweging helaas, er wordt niet nagedacht over een analoog circuit en de voordelen/nadelen daarvan.... helaas.

Maar een uC is dus de beste oplossing zeg je zelf. En Arduino is dat ook gewoon, de reden dat ik die adviseer is omdat hij die makkelijk kan programmeren en veel voorbeeldcode voor beschikbaar is. De IDE is simpel, maar werkt. Als hij wil kan hij daarna de atmega328 er gewoon uithalen en op een eigen printplaatje zetten. Dat is toch handiger dan hem een losse microcontroller + programmer aan te raden.

Hoe jij er dan bij komt dat andere de voor/nadelen van een uC niet hebben afgewogen voordat ze het adviseren begrijp ik niet echt.

Bijvoorbeeld de amplitude meten van een RF signaal, dat kun je met een uC of dedicated iC proberen of je gebruikt een RC en comparator. Succes met het kleiner en goedkoper krijgen tegen dezelfde specs als 5ns comparators en één R en één C.

Die kende ik zelf nog niet, diode - R - C is natuurlijk standaard, maar alleen als je flinke swing hebt. Dus ik moest even over deze nadenken. Alleen heb je dan niet nog wat meer nodig? Op zijn minst een diode zou ik denken: input op je éne input van je comparator. Uitgang via diode en R naar een C, en spannings op de C naar de andere ingang van je comparator. Dan laadt hij de C op tot zover als de maximale spanning van je RF signaal.

Maar goed dit valt ook onder het eerdergenoemde RF, waarbij digitaal het gewoon niet trekt (tegen redelijke complexiteit/power). Al denk ik dat een dedicated IC dan vaak toch een beter idee is, tenzij je enkel en alleen een ruwe schattig nodig hebt van je RF amplitude.

[Oyster]

Sibylle schreef op dinsdag 28 januari 2014 @ 10:38:
[...]


Ik wil hier toch nog op reageren, naar aanleiding van dit topic:
[Help] LEDs programmeren

Kijk, ik snap best dat je snel naar een uC grijpt, of zelfs Arduino of RPi oid. En dat is ook prima, wat ik echter jammer vind is dat het telkens moeilijker wordt voor nieuwelingen om de basis van elektronica te begrijpen. Veel mensen die veel advies geven, hebben zelf vooral uC ervaring en dan verdwijnt de onderliggende gedachte een beetje.

...

Ik ben het absoluut met je eens. Maar als kanttekening zet ik daarbij dat het eigen maken van basiskennis in sommige gevallen niet direct relevant is. Als iemand de interesse toont om een bepaalde functionaliteit door middel van elektronica te implementeren dan staat het resultaat op de eerste plek. De manier waarop is wat mij betreft ondergeschikt. Op de tweede plek staat dat de interesse uitgebuit moet worden om de aandacht en interesse erbij te houden voor toekomstige projecten. Dan is het verstandig om voor de weg van de minste weerstand en 'meest toegankelijke ondersteuning' te kiezen.

Als iemand met interesse eerst Floyd moet uitpluizen dan is degene al ontmoedigd voordat de eerste pin gesoldeerd is. uC's zorgen veelal voor een modulaire implementatie waardoor verder bouwen op het beschikbare gestelde werk van een ander en als gevolg fout zoeken eenvoudiger is. Analoge schakelingen kunnen complex zijn of anders bij simpele wijzigingen heel snel complex worden. Als je de kans dat een project op de plank wordt gegooid wilt verkleinen, dan moet je mogelijke knelpunten minimaliseren. Elektronica is een breed begrip en sommige implementaties zijn nu eenmaal sneller robuust te krijgen en houden dan anderen. Op een uC prik je wat randspul en werkt het vaak. Analoog prik je wat dingen op elkaar en blijkt die (een andere, de gewenste hadden ze natuurlijk niet) BJT toch net even wat anders ingesteld te moeten worden, etc, etc. Dan is het wel erg fijn als je gewoon een scope hebt om te verifiëren, etc.

In mijn geval hangt het van de situatie af wat ik zou adviseren. Maar iemand met weinig kennis mag van mij al snel een arduino met wat shields (oid) kopen en daar lekker met zijn soldeerbout de fik in zetten. Vindt je die buizen zo mooi gloeien? Prima. Vind je die relais zo'n mooie spanningsboog trekken? Prima. Wie ben ik dan om te roepen dat je van een MOSFET gebruik moet maken. Als er maar een moment van resultaat komt. Een overwinning smaakt al snel naar meer. En die gedrevenheid heb je bij analoge elektronica echt nodig wil je daar mee uit de voeten kunnen.

[kitao]

"Op een uC prik je wat randspul en werkt het vaak".

Dat vind ik wel beetje simpel gesteld eerlijk gezegd. Je kan prikken wat je wilt maar zonder sketch gaat er echt niks gebeuren. En natuurlijk, er zijn sketchvoorbeelden genoeg en met plakken en knippen kom je een aardig eind maar zelf schrijven vereist toch aardig wat training. Bovendien zijn er op analoog gebied ook genoeg voorbeelden en kant en klare DIY kits.
Zo heb ik vandaag voor het eerst een rotary encoder aangesloten; ging op zich vrij gemakkelijk (afgezien van eerst uitzoeken welke pinnetje nu eigenlijk wat doet) maar de bijbehorende voorbeelden zoals hier en hier vind ik niet echt eenvoudig qua code. En toch ben ik al ruim een half jaar vrijwel dagelijks een uurtje bezig om C een beetje onder de knie te krijgen. Maar kan ook aan mij liggen, ik heb daar niet echt talent voor.
Ik weet wel dat er best veel tijd in kan gaan zitten om dingen aan de praat te krijgen of dat het nu analoog of per uC is. En tuurlijk, de ene is daar vlotter in als de ander.
Uiteindelijk zal het toch in elkaar overvloeien, met die encoder heb je misschien weer last van bouncen en dan komt er weer een analoog rc-kringetje om de hoek kijken.
Met welke je dan begint lijkt me niet veel uit te maken maar dat is mijn persoonlijke mening. Ben wel met je eens dat het waarschijnlijker is dat iemand door blijft gaan met elektronica als er vrijheid is om bij wijze van spreke de krenten uit de pap te halen en eerst begint met wat die iemand het leukst vindt en daar ook direkt resultaat van ziet zonder eerst alle theoretische achtergrond door te spitten. Bij analoge schakelingen heb je daar denk ik wel meer 'last' van.

[Oyster]

kitao schreef op zaterdag 22 februari 2014 @ 15:31:
Met welke je dan begint lijkt me niet veel uit te maken maar dat is mijn persoonlijke mening.

Wat is dan het 'analoge' alternatief voor je rotary encoder, waarbij je dus geen gebruik maakt van een uC? Daar ben ik dan wel benieuwd naar. Bij een analoog equivalent moet je dondersgoed weten wat je doel is voordat je een implementatie gaat bouwen. Er is weinig aanpruts marge. Tegen een uC kan je een encoder gooien en een beetje verder prutsen zonder dat je een functioneel doel hebt. Bij analoog moet je met dezelfde dingen rekening houden als een uC (hysteresis zoals je zegt) plus nog heel veel meer. Aan een uC kan je met natte vingerwerk redelijk robuust iedere interface knopen als je daar zin in hebt.

[memphis]

Oyster schreef op zaterdag 22 februari 2014 @ 21:46:
[...]


Wat is dan het 'analoge' alternatief voor je rotary encoder, waarbij je dus geen gebruik maakt van een uC? Daar ben ik dan wel benieuwd naar.

Wat noem je analoog? Waar in je verhaal zit het begrip van de 74xx en de 40xx logische IC's?

Een rotary is best nog wel naar een up en down puls te krijgen -> aan een up/down counter geven en je kunt het nodige sturen zoals een D/A converter voor variabele spanning.

[Oyster]

Tja, dat is dus effectief de discussie (weer) op een zijspoor zetten. Analoog staat niet voor niets tussen haakjes. Ik kom prima uit de voeten zonder uC en kan uitstekend alternatieven aandragen om een functionaliteit van begin tot eind te implementeren. Dat wordt precies geduid in het stuk dat je niet quote.

Als het interpreteren van de functionaliteiten abstractie in code een uitdaging vormt zoals kitao aangeeft, dan wordt het implementeren van deze functionaliteiten abstractie in hardware dat helemaal. Effe ditje, effe datje, effe spinwebje, effe wat logische poortjes hier, effe DA'tje daar, dat ken ik allemaal wel. Bij een uC kan je met die lossy eisen goedkoop wegkomen door de hoge peripheral integratie. Bij een hardware implementatie ligt er snel een duur half werkende over gedimensioneerd product op tafel dat amper integreerbaar is, alleen in de zomer werkt en dat al zoveel tijd heeft gekost dat het doel uit het zicht verdwenen is. Al lerend reduceren kan altijd nog.

[kitao]

Oyster schreef op zaterdag 22 februari 2014 @ 21:46:
[...]
Wat is dan het 'analoge' alternatief voor je rotary encoder, waarbij je dus geen gebruik maakt van een uC?
Daar ben ik dan wel benieuwd naar. Bij een analoog equivalent moet je dondersgoed weten wat je doel is voordat je een implementatie gaat bouwen. Er is weinig aanpruts marge.

Ik weet dat alternatief niet maar dat was m.i. ook niet van belang op de strekking van mijn post. Wat ik eigenlijk wilde zeggen is dat bijvoorbeeld in het geval van een vrij simpel iets als een rotary encoder met slechts 5 pinnetjes en wat ingebouwde weerstandjes, er behoorlijk (wederom m.i.) ingewikkelde code voor nodig is om dat apparaatje enigzins iets nuttigs te laten doen.
Je hebt het over (zelf) bouwen.
Geef de gemiddelde hobbyist een uC en zo'n encoder (of menig ander randapparaat) en zeg, ok, maak hier iets werkends van zonder (code)voorbeelden dan gaat menigeen wanhopig met de handen in het haar zitten (incl. mezelf). Dus daarom vond ik jouw opmerking van "erin prikken en het werkt meestal" iets te simplistisch gesteld.
Dat ik bijvoorbeeld met die encoder toch de lichtsterkte van een led kon beïnvloeden was enkel te danken aan het feit dat iemand anders al een code daarvoor had geschreven. Maar iets vergelijkbaars heb je ook met analoog. Daar zijn ook genoeg kant en klare voorbeelden van en honderden kitjes die je in elkaar kunt flansen en leuke dingen kunt laten doen zonder dat iemand daar de hele theorie erachter hoeft te weten.
Geef je de gemiddelde iemand echter de opdracht om het zelf te bouwen zonder te spieken dan loop je volgens mij tegen precies dezelfde problemen aan als bij een uC: zonder achtergrondkennis wordt dat dan vrijwel een onoplosbare opgave.

Tegen een uC kan je een encoder gooien en een beetje verder prutsen zonder dat je een functioneel doel hebt. Bij analoog moet je met dezelfde dingen rekening houden als een uC (hysteresis zoals je zegt) plus nog heel veel meer. Aan een uC kan je met natte vingerwerk redelijk robuust iedere interface knopen als je daar zin in hebt.

Ik denk dat je hierin wel gelijk hebt, maar is het nog wel toepasbaar om analoog en digitaal 1 op 1 te gaan vergelijken ? Waar misschien 60 jaar geleden er nog analoge alternatieven waren is dat tegenwoordig volgens mij al volkomen uitgesloten.

[Oyster]

Nouja, als je stelt dat het niet zoveel uitmaakt waarmee je begint dan moet je minimaal een gevoel voor het alternatief hebben denk ik. Dat je "er tegenaan gooien" te simplistisch gesteld vindt begrijp ik, maar het stond in context en relatief ten opzichte van het alternatief. Die 100-den andere kits geven een geïntegreerde oplossing en nodigen minder uit tot nadenken. Als ze klaar zijn eindigen ze op de kast. Been there, done that. Terwijl jij met je uC realiseert dat je er van alles mee kunt doen door er simpelweg een ander bord op te prikken. Over dat bord is al nagedacht en bemeten. Die code die je aanhaalt is echt niet moeilijk en is zelfs exact de rede dat mensen zonder elektrotechnische achtergrond resultaat kunnen halen. Zonder elektrotechnische achtergrond en apparatuur een hardware implementatie wordt nog heel veel meer zeuren.

Deze discussie kan op vele manieren gevoerd worden. Voor mij is het in ieder geval het meest belangrijk dat mensen met weinig/geen apparatuur en elektrotechnische kennis hun doel met zo min mogelijk opstakels kan bereiken en daarbij de smaak te pakken kan krijgen. Al doende leert men.

[kitao]

Ik begreep wel dat je het niet letterlijk bedoelde over "draadjes verbinden en het werkt" maar ook nu komt toch enigzins de indruk in je post naar voren dat jij het (voor anderen) makkelijker lijkt te vinden om te programmeren als om wat berekeningen uit te voeren om discrete componenten te kunnen koppelen bijv. voor een analoog versterkertje o.i.d.
Maar ik kan me ook voorstellen dat dit per persoon kan verschillen. Zoals de ene bijv. aanleg heeft voor wiskunde zo kan de ander goed zijn in programmeren, sport of tekenen etc. Kortom, dit kan verschillen per individu.
Eerder genoemde code noem jij bijvoorbeeld gemakkelijk maar voor mij en waarschijnlijk nogal wat anderen is dit misschien helemaal 'geen eitje'.
Zoals gezegd ben ik regelmatig bezig met C++ door te lezen maar ik zie mezelf dit nog niet uit m'n mouw schudden. Ik ben al blij als ik enigzins weet welke richting zulke codezinnen op wijzen maar voorlopig schrijf ik dit nog niet zelf op een blanco papiertje. En als dit ook voor veel andere mensen zo is dan zijn zij en ik dus in principe even ver in kennis als bij het monteren van welk dan ook voorgedrukt diy-print-kitje.
De vorige link is juist een mooi voorbeeld van 'overkill' wat in dit topic al vaker is genoemd, want het uiteindelijke resultaat is dat een ledje minder of meer fel gaat branden wat veel makkelijker te bereiken is met een pot en een tor. Maar goed, het is natuurlijk een principeschakeling en geen uitgebreide toepassing.

En inderdaad, als iemand de smaak te pakken heeft - vanaf de 'grondbeginselen' of direkt met een uC-starterskit - dan zal na verloop van tijd alle aspecten van elektronica aan bod komen als de interesse ervoor is gegroeid. Ik heb het dan over de hobbyïst, want een student elektronica met een beroepswens zal wellicht meer gebaat zijn bij een gestructureerd leersysteem dat in sequentiële blokken is opgedeeld. Dat laatste valt echter enigzins buiten dit topic vermoed ik.

(Grondbeginselen heb ik overigens tussen aanhaaltekens gezet want ik heb daar eigenlijk nog geen strakke definitie van gezien.)

[alexandersamson]

kitao schreef op woensdag 26 februari 2014 @ 22:18:
..
Maar ik kan me ook voorstellen dat dit per persoon kan verschillen. Zoals de ene bijv. aanleg heeft voor wiskunde zo kan de ander goed zijn in programmeren, sport of tekenen etc. Kortom, dit kan verschillen per individu.

Dit dekt dus eigenlijk de lading van het hele topic

[Stoney3K]

kitao schreef op donderdag 02 januari 2014 @ 15:48:
[...]

En deze ook

[...]

Dat is nog simpeler op te lossen met een paar eindschakelaartjes en twee (latching) relaisjes die elk één richting van de motor voor hun rekening nemen.

Alles waar we mee werken heeft zijn doel en het is niks anders dan gereedschap. Voor zo'n simpel op-neer liftje zou ik (als installateur en industriëel programmeur) er ook niet gelijk een complete PLC van duizend euro tegenaan kwakken. Kanon op een mug, dat soort dingen. Net zo goed als je geen heel DSP-board gaat gebruiken omdat je eventjes een volumeknopje wil maken en daar zo'n mooie sample van op de website staat.

Aan de andere kant, als ik één of andere complexe rekenstructuur moet maken die alleen linksom gaat lopen als de zon driekwart aan de hemel staat en het de eerste van de maand is, dan ga ik dat niet meer met transistoren en relais in elkaar lopen pielen. Daar hebben we dan weer mooie besturingssystemen voor

Toch kijk ik niet neer op de mensen die gebruik maken van de tools die ze zelf het liefste gebruiken. Als je een LED wil laten knipperen door een paar Arduino shields bij elkaar te prikken, waarom zou ik me daar druk om maken? Hooguit een beetje waste of resources, maar goed, daar hoeft niks mee mis te zijn.

Ik ben wel van mening dat het heel erg leerzaam is om ook eens uit je doosje te denken en nieuwe methodes en middelen te onderzoeken. Je hebt de elektronica-hobby nu eenmaal ook om te leren.

[ Voor 5% gewijzigd door Stoney3K op 04-03-2014 15:52 ]