Vraag1: heb je al ervaring in Arduino en /of C++.
Zo nee, ga dan eerst eens een aantal 'tutorials' doen.
Vraag 2: wat wil je bereiken, wat moeten al deze dingen doen.
Groet,
Henk SWT
Hallo Henk,
Nee ik heb niet zoveel ervaring maar heb wel wat kleine opzetjes gemaakt met leds, temp sensors en ventilators.
Het volgende zou ik willen doen
ik heb een zeeaquarium hier zou ik het volgende willen aansturen.
aquarium, sump en een jarrycan voorzien van temperatuur sensor
deze zo regelen dat als de temp van de sump te hoog is dat er een ventilator aan gaat en als hij te laag is dat een verwarmingselement aan gaat.
dat ik 6 doseer pompjes van 6v kan regelen.
tijd en datum kan instellen.
dat ik via internet grafieken kan bekijken van het verloop.
en dat ik dit alles kan instellen via tft touch screen.
Ed
Wat Henk SWT bedoeld is dat het een klassieke fout is om direct een "groot" project aan te pakken.
Begin eens met 1 temp sensor end dan 2 en dan 3.
Doe eens iets met enkel 1 motor en dan die motor op 1 temp sensor ....
Doe iets enkel met Ultrasone Module HC-SR04 and dan de motor erbij ....
Ik denk dat je het idee wel snapt.
En dit is echt niet omdat je een beginner bent. Het is een algemeen aanvaarde methode dat als iets niet werk en je komt er niet uit je 2 manieren van aanpakken hebt. 1 is componenten weghalen die je denkt dat de oorzaak zijn of gewoon weer vanaf nul beginnen en weer opbouwen component per component. Vanaf wanneer werkt het weer (als je componenten verwijderd) of niet meer(als je componenten toevoegd)?
Zo kan je focussen op de code, je gehele programa opbouw en de electronica.
Ikzelf ga dit vandaag doen voor men I2C bus.
Ik heb men probleem gevonden 8) (alle op zijn minst toch een stuk)
Alles van de I2C bus gesloopt.
Pull -up weerstanden gecontroleerd (blijkbaar heeft de mega een 10K pullup op de I2C bus)
Scope op de I2C bus-> geen signaal op de scope
Simpele sketch (die rechtstreeks naar de wire lib schrijft -dus ook op code vlak "naked"- ) die steeds signaal stuurt -> wel signaal op de scope
Code nalezen=> bug vinden if ( status == 0) hoort if (status !=0) te zijn (Als er zich een fout voordoet stop ik met sturen) hoera gevonden .... euch neen dus
Sample programma van 1 van de I2C devices opgestart (die om de xmillis -waar ik mee heb zitten spelen- een verzoek stuurt)-> werkt soms maar meestal niet
Van alles de spanning af en aan; werkt en dan weer niet ....
Ik doe de lijn if (status !=0) weg en bang het werkt
Ik doe een lijn code bij die de status logt en ik zie dat I2C regelmatig een error code weergeeft.
Next done
DFRPlayer status = 2
Next done
DFRPlayer status = 0
Next done
DFRPlayer status = 2
Next done
DFRPlayer status = 0
Next done
DFRPlayer status = 2
Next done
DFRPlayer status = 2
Conclusie: Door een verkeerde interpretatie van wat een foutcode bij I2C betekend was men code verkeerd.
Ik vermoed dat ik in plaats van het device afschakelen gewoon opnieuw moet proberen.
Hey prutser Wil je hiermee stellen dat Wire niet goed is? Ik heb nog wat ellende om onduidelijke redenen met een DS1307RCT die ook nog eens serieel doorlust naar een Seriele LCD. Die klok is zo onbetrouwbaar als de pest... soms wel meestal niet.
nicoverduin:
Hey prutser Wil je hiermee stellen dat Wire niet goed is? Ik heb nog wat ellende om onduidelijke redenen met een DS1307RCT die ook nog eens serieel doorlust naar een Seriele LCD. Die klok is zo onbetrouwbaar als de pest... soms wel meestal niet.
Ik acht mezelf niet goed genoeg in om daar op te antwoorden.
Wat ik nu wel merk is dat ik sinds ik men scope heb verwijderd alleen maar 0 krijg.
Ik ben eigenlijk op zoek naar hickups (lange delays tot blokeren van de code) en ja ik verdenk twi (en niet wire) van de oorzaak.
Hier hou ik niet van (vooral omdat ik op de scope constant laag signaal gezien heb als de zaak blokkeert
// wait until twi is ready, become master transmitter
while(TWI_READY != twi_state){
continue;
}
// wait for write operation to complete
while(wait && (TWI_MTX == twi_state)){
continue;
}
Verschillende bronnen hebben me gezegd dat I2C gevoelig is.
Ik ben nog wel even zoet vrees ik voor ik kan aanduiden wat er echt mis is.
Jantje
Jantje:
Ed
Wat Henk SWT bedoeld is dat het een klassieke fout is om direct een "groot" project aan te pakken.
Begin eens met 1 temp sensor end dan 2 en dan 3.
Doe eens iets met enkel 1 motor en dan die motor op 1 temp sensor ....
Doe iets enkel met Ultrasone Module HC-SR04 and dan de motor erbij ....
Ik denk dat je het idee wel snapt.
En dit is echt niet omdat je een beginner bent. Het is een algemeen aanvaarde methode dat als iets niet werk en je komt er niet uit je 2 manieren van aanpakken hebt. 1 is componenten weghalen die je denkt dat de oorzaak zijn of gewoon weer vanaf nul beginnen en weer opbouwen component per component. Vanaf wanneer werkt het weer (als je componenten verwijderd) of niet meer(als je componenten toevoegd)?
Zo kan je focussen op de code, je gehele programa opbouw en de electronica.
Ikzelf ga dit vandaag doen voor men I2C bus.
Met vriendelijke groet
Jantje
Hallo Jantje,
Ja zeker weet ik wat henk bedoeld en ik weet ook dat ik vaak te veel en te snel wil.
laat ik vertellen dat ik een klein projectje heb gemaakt wat het volgende doet.
1 temp sensor die de temperatuur meet zodra deze boven de 27 graden komt gaat er 1 ventilator aan zodra de temperatuur onder de 24 graden komt word er een verwarmings element aangeschakeld via een relais shield. En dit alles is aftelezen op een lcd schermpje van 16x2.
Dus zover ben ik al, alleen begrijp ik even niet hoe ik meerdere opdrachten in 1 programma kan verwerken. en ik moet kijk hoe het werkt met een tft touch screen.
Je moet jouw probleem eerst conceptueel neerzetten. Dus (met bijv een blokschema of zo) de verschillende functies aan elkaar knopen.
Je hebt het over een real-time oplossing dus wordt straks het lezen van sensoren, aansturen van Relais, ontvangen over Wifi, aansturen TFT enz. allemaal losse blokken die iets doorgeven aan/ontvangen van elkaar.
delay() kun je zowieso vergeten. Je zult met millis() en timers moeten gaan werken als je om de zoveel tijd iets wilt lezen of schrijven.
Maar ik zou eerst een conceptueel schema maken van alle koppelingen met de buitenwereld en dan in het kort beschrijven wat ze moeten doen. Als dat niet mogelijk blijkt te zijn dan heb je nog wat uit te zoeken. En kan je het niet beschrijven, dan kan je het ook niet programmeren......
Mijn motto "Bezint eer ge begint" oftewel eerst nadenken dan doen.
nicoverduin:
Je moet jouw probleem eerst conceptueel neerzetten. Dus (met bijv een blokschema of zo) de verschillende functies aan elkaar knopen.
Je hebt het over een real-time oplossing dus wordt straks het lezen van sensoren, aansturen van Relais, ontvangen over Wifi, aansturen TFT enz. allemaal losse blokken die iets doorgeven aan/ontvangen van elkaar.
delay() kun je zowieso vergeten. Je zult met millis() en timers moeten gaan werken als je om de zoveel tijd iets wilt lezen of schrijven.
Maar ik zou eerst een conceptueel schema maken van alle koppelingen met de buitenwereld en dan in het kort beschrijven wat ze moeten doen. Als dat niet mogelijk blijkt te zijn dan heb je nog wat uit te zoeken. En kan je het niet beschrijven, dan kan je het ook niet programmeren......
Mijn motto "Bezint eer ge begint" oftewel eerst nadenken dan doen.
Hallo Nico,
Thnx,
Ben nieuw hier mee en kan dingen best snel snappen als het me uitgelegd word dus vandaar dat ik het hier op het forum probeer te bespreken mss breng ik het niet duidelijk genoeg. als ik weet hoe ik moet beginnen met een opzet van een schema dan heb ik een begin en zal ik het ook beter gaan snappen ben best technisch aangelegd.
In je lijstje mis ik nog een RTC module om de tijd/datum exact te weten. Een RTC1307 module is af te raden omdat die niet erg nauwkeurig is. Loopt vaak vele seconden per dag voor of achter. Een DS3231 module is veel naukeuriger. (beter dan enkele seconden/maand afwijking is mogelijk). Werkt met de I2C databus en de wire-library. Een lcd display kun je dan ook via dezelfde I2C bus aansturen. 162 is een beetje klein maar bruikbaar. 204 daar kun je al een hoop text-informatie mee weergeven. Zo'n 2-draads bus maakt je project veel overzichtelijker in de ontwerpfase.
Een TFT-touch zou ik voorlopig nog mijden. Probeer eerst je project met druktoetsen, een toetsenbordje en/of een rotary-encoder werkend te krijgen. Een netwerk-shield voor de internet-koppeling is al complex genoeg.
Heb je eenmaal de zaak foutloos werkend dan kun je daarna een tablet of smartphone, die hebben immers TFT-touch, gebruiken voor input en weergave.
Je moet in blokjes programma denken. Ieder blokje heeft een input en een output. Ieder blokje programma kan zelfstandig werken en kan het beste als een soort subroutine geschreven worden.
De blokjes moeten dan een voor een worden afgewerkt.
Gebruik zo min mogelijk delay() statements want die zorgen ervoor dat je programma niets doet.
Elk probleem kun je opdelen in kleinere. En die in weer nog kleinere. Als je voor jezelf de afspraak maakt dat de volgorde is van boven naar beneden en van links naar rechts kun je jouw project opdelen in steeds kleinere delen. Zo zou je de eerste laag kunnen opdelen in lees_sensors, Toon_resultaten, Stuur motoren enz
lees_sensors kun je weer opsplitsen in Zet_sensor_aan, lees_waarde, sla_waarde_op enz.
Het mooie is dat al weet je niet wat je moet doen er nog geen programma regel is gemaakt. MAAR je kan nu wel gericht zoeken hoe iets aangestuurd wordt omdat je de vraag hebt beperkt tot de kern. Op deze manier kun je in feite het hele programma als structuur neerzetten zonder een regel gecodeerd te hebben.