Tijd instellen dmv drukknoppen arduino uno klok

Waw, ik heb even wat gemist...... :stuck_out_tongue:

Ik heb allemaal wel wat moeite om alle argumenten door te kauwen, maar ikzelf kan alleen proberen te begrijpen wat ikzelf zie ( in dit geval lees ).

Ik vind Cartoonist enorm veel moeite doen om me op een goed spoor te zetten en daar ben ik zeer dankbaar voor.

Hij zei zelf ook dat het "snel in mekaar geflanst was en het mooier geschreven kon worden." Kan ik als leek niet over oordelen.

Nu als die debounce bij het indrukken van de knop zo problematisch is, kan ik hem misschien wel hardwarematig "debouncen". Dit gebruikte ik ook bij de TTL en Cmos klokken door middel van een NE555 of een NE556 timer.....

@MAS3: ik heb jou post ook een paar keer moeten doorlezen en bedoel je dan dat ik de interrupt moet gebruiken om de drukknoppen uit te lezen?
Dat van die heartbeat ken ik niet, moet ik even opzoeken.

Er zijn op het web inderdaad klokken genoeg te vinden, maar diegenen die echt goed werken, zul je geen code bij vinden. Als je deze mensen eens een mailtje stuurt om wat info te vragen, en daarmee vraag ik niet rechtstreeks hun geschreven sketches, is het meest ontvangen antwoord : buy the kit, it comes with a programmed bla bla.....

Ik heb me daarom voorgenomen gewoon zelf wat te beginnen stoeien, gewoon een klokje op een lcd, die breidt ik dan mettertijd wel verder uit.

@ Cartoonist, ik heb de I2C converter nog niet ontvangen, zal voor volgende week zijn. Als ik hem heb, ga ik gelijk jouw sketch er even inbakken en zie ik zelf wel wat er gebeurd :smiley:

Ik heb er dan meteen maar een DHT11 sensor bijgenomen, kan ik ook even zien hoe warm en vochtig het hier wel is :stuck_out_tongue:

Nogmaals bedankt aan allen voor jullie hulp en meedenken 8)

Hou ons op de hoogte s.v.p. van je vorderingen bij het maken van je nixie klok.
Ik weet nog wel een (of meerdere) bruikbare tips die in je in het klok-programma mee kunt nemen.

Alle vragen over software, of hardware voor de arduino kun je hier plaatsen.
sucses toegewenst.

Ik was van plan niet meer te reageren, omdat cartoonist en ik het nooit eens zullen worden wat dit betreft.
Maar gezien Koen_P_Belgium's reactie kan ik het toch niet laten.

Koen is zo te zien inderdaad wel op de hoogte van elektronica, maar dat programmeren is toch wel erg nieuw allemaal.
Hij verklapt dat ie weet wat debounce is, en dat hij daar ook wel hardware oplossingen voor kent.
Maar ook dat ie geen idee heeft hoe dat dan in software opgelost kan worden.

Ik heb geen concrete oplossingen of code gegeven, alleen verteld dat zaken ook op een andere, maar mijn idee veel eenvoudiger manier bereikt kunnen worden.
Met name over het gebruik van interrupt heb ik een en ander vermeld, in relatie tot beginners (in programmeren).
Daar sta ik nog steeds achter en cartoonists laatste toelichting overtuigt mij niet.

@Koen_P_Belgium:

Ik bedoel dat jij nog niet toe bent aan het gebruik van interrupts.
In de eerder (niet door mij) geplaatste code word gebruik gemaakt van een interrupt om de hartslag te monitoren.
Op het moment dat je klok ic een hartslag puls geeft, moet je Arduino alles laten stoppen wat ie op dat moment aan het doen is, om te registreren dat het hart zojuist geklopt heeft.
Als dat eenmaal geregistreerd is, dan gaat de Arduino weer verder met waar ie mee bezig was.
Ergens in de code word dan gekeken of die hartslag al gezien is, en alleen in dat geval word er gekeken en afgebeeld hoe het er met de klok voor staat.
Daarmee word voorkomen dat de klok een groot aantal malen word uitgelezen en afgebeeld, terwijl er helemaal niets veranderd is in wat er uitgelezen en afgebeeld moet worden (alles inclusief de secondes zijn nog niet veranderd).

Het is een heel goed idee om niet veranderde gegevens niet voor niets uit te lezen en ook niet voor niets opnieuw af te beelden, wantr dan ben je eigenlijk alleen maar druk bezig met niets.

Het commentaar dat ik in jouw, deze thread gaf was niet aan jou gericht maar aan mensen die je proberen te helpen.
Ik heb hele grote vraagtekens en moeite bij hulp door aanleveren van een code, met de mededeling "probeer dit eens, dat moet werken".
Die hulp gebeurt zonder twijfel met de beste bedoeling, maar als degene die geholpen word het met dank aanneemt, maar ondertussen geen idee heeft wat ie nu heeft en hoe het werkt, is die dan wel geholpen ?

In de aangeleverde code zitten stukken die in meer of mindere mate discutabel zijn.
Daar is wel een opmerking over gemaakt dat het even snel gemaakt is, maar daarmee is de kans op verwarring en moeite om het te begrijpen groot, en er worden dingen aangeleerd die beter anders kunnen.
Hier heb ik het met name over het toepassen van delay() en de mededeling dat dat mede als doel heeft te debouncen.
Dat is gewoon niet wat daar gebeurt, want als je wil weten of een schakelaar op twee momenten dezelfde stand heeft, dan moet je er ook twee keer naar kijken (en dat gebeurt dus niet).
Het mooie van Arduino is nou juist dat je heel veel kunt doen zonder extra externe componenten.
Dat je weet hoe je het hardwarematig kunt oplossen kan je ook helpen begrijpen hoe het in software op te lossen, en das mooi meegenomen voor jou.

Je kunt op een andere manier dingen een tijdje wel of niet doen, dus zonder gebruik te maken van delay().
Daarvoor moet je meer dingen bijhouden, en een ding daarvan is zeg maar de systeemtijd.
De delay() functie maakt ook gebruik van die systeemtijd, maar doet ondertussen bijna niets anders dan wachten en kijken of de opgegeven tijd al verstreken is.
Je kunt ook doorgaan met het verwerken van code en dan regelmatig kijken of de tijd al verstreken is.
Hoe dat gaat, is beschreven in het voorbeeld "blink without delay", en als je goed kijkt zie je dat ik daar onder aan iedere post ook naar verwijs, en das niet voor niets.

Ik heb in mijn eerdere commentaren verteld dat je daarom beter geen delay gebruikt, maar ook geen while.
En dat zit wel in de aangeleverde code.
Als je dit niet wist, dan ben je in mijn ogen een beginner.
Sterker nog, nu na 2 jaar sinds ik begon met spelen met de Arduino vind ik mezelf ook nog een beginner, of in ieder geval zeker geen routinier.
Omdat ik in de vorige eeuw ook wel eens een beetje gesnuffeld heb aan programmeren, en daarbij ook interrupts ben tegengekomen, weet ik wel wat dat is, en waar het voor gebruikt kan worden.
Maar ik heb ze nog niet hoeven toepassen in mijn Arduino experimenten tot nog toe.

Ik ben nu zelf op het punt waar ik probeer om functies (zoals die bij C++ bekend zijn) goed te begrijpen, maar ik heb ook geen haast met het leerproces.
Het meeste leer ik nog van de vragen die ik lees en regelmatig probeer te beantwoorden hier op het forum.
Maar genoeg over mij.

Als je cartoonists code begrijpt en daarmee verder wil gaan dan is dat prima.
Als je het niet begrijpt maar dat wel wil, dan moet je dat aangeven en proberen aan te geven waar je het kwijtraakt.
Als je hulp wil die een andere richting op gaat dan moet je dat ook aangeven en ik zal je daar ook bij proberen te ondersteunen.
Maar ik zal je geen kant en klare code aanreiken.
Wel zal ik jouw code bekijken en er op of aanmerkingen op maken en eventueel een stukje voorbeeld of aanpassingen bij geven.
Maar als het je eigen werk is, zul je er ook zelf het beste van leren en daar is het mij om te doen.
Anders zien we je bij een volgend maar vergelijkbaar project weer en dan waarschijnlijk een beetje meer gefrustreerd.
Ik hoop dat anderen je daarbij ook ondersteunen, want de kracht van zo'n forum als dit is nou juist dat er meerdere mensen en dus meningen en ervaringen kunnen helpen.

Als je de DHT sensor ook in je klok gaat gebruiken, kun je er ook een extra nixie buis bij plaatsen die de symbolen voor de afgebeelde grootheden kan weergeven, zoals dit bijvoorbeeld (gewoon ff opgezocht met Google).

Veel succes met je verdere Arduino avonturen, inderdaad houd ons op de hoogte.

Het eeuwige probleem van geschreven internet communicatie, is het ongeweten misverstand door gebrek aan menselijke lichaamstaal.

Vooral dan de reacties op "nogmaals bedankt voor allen die helpen meedenken bla bla" lijkt begrepen te worden als dat ik het voorlopig voor bekeken hou, maar dat bedoel ik helemaal niet.

Het commentaar dat ik in jouw, deze thread gaf was niet aan jou gericht maar aan mensen die je proberen te helpen.
Ik heb hele grote vraagtekens en moeite bij hulp door aanleveren van een code, met de mededeling "probeer dit eens, dat moet werken".
Die hulp gebeurt zonder twijfel met de beste bedoeling, maar als degene die geholpen word het met dank aanneemt, maar ondertussen geen idee heeft wat ie nu heeft en hoe het werkt, is die dan wel geholpen ?

Dat zie ik net even anders.... Ik heb in de loop der jaren veel in Buitenland gewerkt, en heb daarbij vlot 5 talen leren spreken, zonder leerboekjes, gewoon door te spreken, met vallen en opstaan.

Persoonlijk vind ik dat het beste leerproces, ik doe ook de moeite om wat er aangeleverd word te ontleden en te begrijpen, ik kan zelf het uit niets nog niet zo wat maken, omdat ik de taal nog niet beheers, de C-woordenschat.... Maar hierdoor leer ik het best.

Ik ben zelf ook actief op enkele electronica forums, en er is inderdaad een slag van mensen zoals "ik wil vandaag nog even een nixieklok maken met 2 alarmen, kamer en buitentemperatuur, bla bla, wie geeft er eventjes een code, schema en liefst ook nog een CAD voor de printplaten???"

maar die haal je er wel uit enkel van de topictitel te lezen..... Sorry voor het offtopic gaan....

Ik sta trouwens helemaal open voor andere ideeën en werkwijzen, :grin:

Het is mooi dat je kunt leren door te doen, zoals met die talen.
Dat is lang niet voor iedereen weggelegd.

Het probleem is dat je een voorbeeld word voorgeschoteld, met fouten er in.
Er word maar heel kort verteld dat de werkwijze wellicht niet de beste is, maar verder word er niet op ingegaan.
Als jij daaruit een les trekt, dan leer je verkeerde zaken.
En ik vind dat daar op z'n minst voor gewaarschuwd moet worden.

Het uitbreiden van je project gaat nog interessant worden.

Wonder boven wonder, de Belgische post werkt ook op zaterdag, envelopje van Elektronica Hobby zat netjes in de brievenbus toen ik thuiskwam. ;D

Nu ineens alles omgebouwd naar een I2C LCD maar lijkt de opgegeven sketch toch niet echt lekker te zitten, ik krijg nl een error bij het compileren: ISO C++ says that these are ambiguous, even tough the worst conversion for the first is better then the worst for the second

sketch_nov23b:168: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:

.../Contents/Resources/Java/hardware/arduino/avr/libraries/Wire/Wire.h:58: note: candidate 1: uint8_t TwoWire::requestFrom(int, int)

.../Contents/Resources/Java/hardware/arduino/avr/libraries/Wire/Wire.h:56: note: candidate 2: uint8_t TwoWire::requestFrom(uint8_t, uint8_t)

Er wordt dan verwezen naar de subroutine Void readTime,
Wire.requestFrom(DS3231, 3); // reads 3 bytes data from RTC-registers
deze regel werd "geselecteerd" na het compileren

°°EDIT°° sketch is nu gecompileerd en geladen, Ik heb in het begin de regel
Byte DS3231 0x68 vervangen door #define DS1307_I2C_ADRES 0x68
en dit ook op alle regels waar de I2C voor de RTC aangesproken wordt veranderd.

Resultaat compileren en uploaden = OK
helaas niks op LCD te zien, contrast aangepast, geen verandering.
Ik kruip in bed en ga er eens goed over slapen :slight_smile:

Soms is het handig om zeker te stellen dat je LCD het wel doet. Dus van mij part ff een boodschap er naar toe sturen om uit te sluiten dat dat eventueel defect is.

Koen_P_Belgium:
sketch_nov23b:168: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:

.../Contents/Resources/Java/hardware/arduino/avr/libraries/Wire/Wire.h:58: note: candidate 1: uint8_t TwoWire::requestFrom(int, int)

.../Contents/Resources/Java/hardware/arduino/avr/libraries/Wire/Wire.h:56: note: candidate 2: uint8_t TwoWire::requestFrom(uint8_t, uint8_t)

Er wordt dan verwezen naar de subroutine Void readTime,
Wire.requestFrom(DS3231, 3); // reads 3 bytes data from RTC-registers
deze regel werd "geselecteerd" na het compileren

°°EDIT°° sketch is nu gecompileerd en geladen, Ik heb in het begin de regel
Byte DS3231 0x68 vervangen door #define DS1307_I2C_ADRES 0x68
en dit ook op alle regels waar de I2C voor de RTC aangesproken wordt veranderd.

Ik veronderstel dat je Arduino IDE 1.5.6 of later gebruikt. Daar is namelijk een toolchain verandering gebeurd die dit soort foutboodschappen genereert.
De oplossing die je gevonden hebt geeft maar weer eens aan waarom defines soms echt wel beter zijn :smiling_imp:
In het eerste geval zeg je expliciet "dit is een byte" en dan gebruik je die als eerste parameter in een functie die gedefineerd is met 2 "integer" of 2 "uint8_t". De 2de parameter die je geeft is 3 wat ik denk dat de compiler ziet als (int)3.
Er met dus een omvorming gebeuren van byte,3 naar int, int of uint8_t, uint8_t en de compiler raakt er niet wijs uit (en mag ook niet meer wegens de nieuwe ISO C++ conventie)
Door je aanpassing wordt de byte,3 0x68,3 en dat kan hij perfect naar int, int en naar uint8_t, uint8_t converteren. Ik zou gokken dat hij int,int zal nemen.

Veel success verder.
Jantje

Over de I2C interface naar het lcd.... >:( Er verschijnt helemaal niks op het LCD.... Als ik het LCD direct op de IO van de UNO aansluit doet hij het wel dus de LCD is ok.

Ik vermoed een adresseringsprobleem, maar uitleg over de module is voor mij heel onduidelijk. Ik heb al verschillende adressen gebruikt, steeds zonder resultaat.

http://arduino-info.wikispaces.com/LCD-Blue-I2C#v3

Er zijn op de module 3 sets soldeer eilandjes genummerd A0, A1, A2... ik vermoed dat hiermee het adres gezet wordt, deze zijn open op mijn module en op de foto's op het net zijn deze overal gebrugd.

Iemand hier ervaring mee?

Welk i2c adres gebruik je nu?

Koen_P_Belgium:
Ik vermoed een adresseringsprobleem, maar uitleg over de module is voor mij heel onduidelijk. Ik heb al verschillende adressen gebruikt, steeds zonder resultaat.

Het meest waarschijnlijk is inderdaad een adresseringsprobleem.

Op de I2C module zit een zogenaamde 'I/O expander' , dit is een IC wat 8 pinnen heeft die naar keuze als input of output geconfigureerd kunnen worden. Het typenummer van dit IC is PCF8574.
In de documentatie van dit IC
http://www.nxp.com/documents/data_sheet/PCF8574_PCF8574A.pdf
kun je vinden dat er 3 adresserings pinnen A0, A1 en A2 aanwezig zijn en op het printje zijn deze aangeslotem op de soldeereilandjes. Met 3 pinnen kunnen 8 adressen gecodeerd worden. Voor de PCF8574 liggen deze altijd tussen 0x20 en 0x27 ( 32 tot 40)
Als je de pinnen standaard open laat is adres 0x27 het meest waarschijnlijk.
In het testprogrammaatje wat ik hier postte was dat op 0x26 ingesteld.

Maar e.e.a. hangt af welk type je gekregen hebt.
Er is een heel simpel programmaatje voor om te testen welke I2C adressen op de bus gebruikt worden.
http://playground.arduino.cc/Main/I2cScanner
Dit geeft dacht ik een lijst van alle aangesloten I2C adressen. Je zult dan een adres vinden tussen 0x20 en 0x27 voor de PCF8574 en nog een tweede adres voor de DS1307, dat is altijd 0x68 en waarschijnlijk nog een derde adress van een 32kb EEPROM die meestal ook op de RTC module zit. Deze EEPROMS hebben altijd een adres ergens in de 0X50 zeg ik zo uit mijn hoofd.

P.S.

Het is ook van belang dat je de juiste library gebruikt.
Met die van fmalpartida moet het geen probleem zijn om dit printje i.c.m. een LCD aan de praat te krijgen.

~~https://github.com/pkourany/LiquidCrystal_V1.2.1~~

gewoon even zoeken

Dankje wel voor de tip ivm met de adreszoeker :grin:

De library van fmalpartida is diegene die ik geïnstalleerd heb.

Probleem door middel van het adres-zoek-programmaatje opgelost, slechte rij veertjes in het breadbord zodat er slecht of geen contact gemaakt werd >:( >:(

Ik ben blij voor je dat de I2C LCD display nu werkt.

Ik heb ook wel eens een splinternieuwe breadboard (uit china) gekregen waarin een contactprobleem zat. Heb toen aan de achterkant het dubbelzijdige plakkende foam-tape gedeeltelijk losgemaakt en kon daarna het kreupele veertje opnieuw , maar nu in de juiste positie, weer terugbuigen. Sindsdien geen problemen meer gehad met dat breadboard.
Maar ik blijf altijd op mijn hoede voor dat soort 'mankementen'.
Had ook laatst een setje hagelnieuwe breadboard jumper kabels, zo'n kabeltje van 20cm wat je gebruikt om iets op de breadboard aan te sluiten en daar bleek in een van de knijpaansluitingen bij de pinnen een onderbreking te zitten.
Zelfde kort geleden ook gehad met een setje experimenteer kabeltjes met krokodilklemmetjes aan de einden. Ook daar zat een slechte knijpverbinding.

Ik accepteer dat soort problemen gelaten, dat heb je met goedkoop massa spul. Het alternatief is om laboratorium kwaliteit jumpers en breadboards te kopen. Maar ja ....... de prijs he.....

cartoonist:
Ik accepteer dat soort problemen gelaten, dat heb je met goedkoop massa spul. Het alternatief is om laboratorium kwaliteit jumpers en breadboards te kopen. Maar ja ....... de prijs he.....

En de besparing op verloren tijd........ a xxx euri per uur......

Dta soort problemen oplossen is voor mij geen verloren tijd hoor. Daar doe ik praktijkervaring mee op.

Hier elke dag op het forum zitten lezen en posten, dat kost me een hoop tijd a xxx euri per uur. ;D

cartoonist:
Hier elke dag op het forum zitten lezen en posten, dat kost me een hoop tijd a xxx euri per uur. ;D

Dan moet je het niet doen :grin:

Jippie :grin:

Na een hoopje stress en wat grijze haren heb ik je sketch aan de praat @Cartoonist. Die I2C-LCD module is echt een aanwinst! Thanx 4 the tip!

Hier ben ik weer even mee zoet. Eerst eens proberen of ik mijn DHT11 sensor er mee inkrijg :grin:

Advies:

Eerst de losse DHT module aan de praat krijgen samen met de LCD (zodat je ziet wat ie doet).
Als je die DHT module begrijpt, kun je de sketches samenvoegen tot een mooi geheel.
Dat houd het overzichtelijk.

MAS3:
Advies:

Eerst de losse DHT module aan de praat krijgen samen met de LCD (zodat je ziet wat ie doet).
Als je die DHT module begrijpt, kun je de sketches samenvoegen tot een mooi geheel.
Dat houd het overzichtelijk.

+1