[Discussie] Arduino-topic

[LED-Maniak]

Pizza_Boom schreef op dinsdag 11 augustus 2015 @ 23:45:
[...]
Ik heb er 2. Ik neem aan dat ik de CTC mode moet pakken waarbij de TOP van OCR1a wordt afgeleid? Dat zou WGM12 zijn bij de 32U4.

Correct.

[...]
Is er nog een reden dat je voor een prescaler voor 256 kiest? Waarschijnlijk wel en zie ik iets heel basaal over het hoofd, maar bij een prescaler van 64 kom ik exact op 624 uit als waarde voor de OCR1a.

Thnx voor de feedback iig.

Je timer is 8 of 16 bit.
Bij 8-bit is de maximale waarde voor het compare register 255. Bij 16-bit 65535. Daar moet je binnen blijven.
Beschikbare prescalers zijn 1, 8, 64, 256 en 1024 waar je uit kan kiezen. Berekening was puur een voorbeeld(geen idee op welke kloksnelheid jij draait) maar als het met een 64 prescale kan, dan is dit natuurlijk beter(omdat inderdaad rond getal).

Nog een kleine tip/truc:
Gezien een AVR overigens maar een beperkt aantal timers heeft en de refresh frequentie niet echt heel nauwkeurig hoeft te zijn, zou je net zo goed de 8-bit timer kunnen pakken. Die gebruik ik zelf in projecten relatief minder vaak dan een 16-bit timer. Of wie weet heb je al een timer ergens draaien op een frequentie die in de buurt komt en kan je daar nog een extra interrupt bij zetten voor je display.

[ Voor 19% gewijzigd door LED-Maniak op 12-08-2015 00:09 ]

[Pizza_Boom]

Ik ga even uit van het feit dat mijn Arduino Mirco (zowaar een echte!) op 16 MHz draait. Prescaler naar 1024 komt uit op ongeveer een seconde per interrupt bij een berekening waarbij ik uitga van 16 MHz. Het knipperende LEDje dat ik er tijdelijk aan heb gehangen staat inderdaad, voor zover meetbaar met het blote oog, ongeveer een seconde aan en dan weer een seconde uit.

Behalve het aantal bit waarin je moet blijven voor je timer (timer1 is volgens mij gewoon 16 bit), zijn er geen voorkeuren voor een bepaalde prescaler dus.

Ik heb nog geen timers draaien tot nu toe, komt wellicht nog. Even denken wat die nRFjes ook alweer nodig hadden. Maar het overzetten naar een 8 bit timer is inderdaad wel een idee, het hangt toch niet zo nauw.

[ Voor 21% gewijzigd door Pizza_Boom op 12-08-2015 00:15 ]

[LED-Maniak]

Bij bepaalde applicaties zou je kunnen zeggen dat je een zo laag mogelijke prescaler wilt. Bijvoorbeeld in het geval van het genereren van een blokgolf, dan heb je meer 'tick' nauwkeurigheid om de duty cycle te variëren. In dit geval maakt het inderdaad geen snars uit.

nRF hebben alleen een SPI interface nodig dacht ik? Dus dat kan je mooi in hardware SPI fixen.

[ Voor 15% gewijzigd door LED-Maniak op 12-08-2015 00:18 ]

[Pizza_Boom]

Ah, duidelijk. Maar dat heb ik nu toch niet nodig, dus eerst hier maar eens mee pielen.

nRF heeft inderdaad SPI en nog enkele vrije pinnen nodig (je hebt er 5 nodig op je Arduino IO, er is nog een interrupt pin die ik nog niet werkend heb gekregen, maar dat is natuurlijk wel het mooiste om te doen, als je toch met interrupts bezig bent, 1x per minuut o.i.d. een update van de buitentemperatuur, hoef je hem ook niet continue uit te luisteren).

Genoeg te doen dus. Zeker als je bedenkt dat de wens voor het buitenstation stiekem nog 100% wireless en solarpowered is ook. Paar cellen uit solarlampjes in serie en hopen dat dat genoeg stroom levert om en een Arduino te draaien en een batterij op te laden voor de nachtelijke uren.

[ Voor 81% gewijzigd door Pizza_Boom op 12-08-2015 00:33 ]

[RobV]

Deelmomentje:

Arduino IDE op OSX weigerde mijn nieuwe Arduino Micros te herkennen. Ik zag netjes de seriele poort verschijnen maar de uploader bleef roepen 'device in use'.

Wat bleek, het OS had de nieuwe seriele poort opgeeist als potentiele netwerkinterface. Na het verwijderen van de serial port uit de network preferences was het opgelost. Ook na herhaaldelijk inpluggen. Het zou een El Capitan bug kunnen zijn, maar iig opgelost voor nu.

[Pizza_Boom]

Ik weet niet of het bij mij aan de driver ligt. De andere micro (een kloon) doet het namelijk wel gewoon, zelfs op dezelfde poorten. Als ik de Micro aan zet, geeft ie heel kort cijfers weer op beide displaytjes van de duo 7 segment, vlak daarna vervalt ie naar 1 (die ook helderder wordt) en blijft ie daarop hangen. De LED die ook gemultiplexed zou moeten worden (die nu dus in het timer interrupt vectortje zit) blijft ook 100% uit. Alsof er intern iets gigantisch is vastgelopen. Een programma als Blink krijg ik er ook niet meer in, maar buiten dat, de bootloader branden lukt mij vooralsnog ook iet. Ik blijf errors krijgen.
EDIT: Dit gebeurde toen ik van timer1 naar timer3 ging en de interrupt vector schreef. Zou dat ermee te maken hebben gehad?[/edit]

Als ik deze lay out gebruik, dan heb ik het als volgt aangesloten:
Pin 10, zit op de micro op physical pin 30, zit aan de reset (physical 13) van de te branden Arduino
Pin 11, zit op de micro op physical pin 12, zit aan de Mosi op de GPIO (physical 10)
Pin 12, zit op de micro op physical pin 26, zit aan de Miso op de GPIO (physical 11)
Pin 13, zit op de micro op physical pin 32, zit aan de SCK op de GPIO (physical 9)

Aangezien beide Micro's zijn, hoef ik dat niet aan te passen. Na het inladen van het meegeleverde ArduinoISP programma, dat wel goed gaat (ik zie de heartbeat LED het ook doen), zet ik de bootloader om van ArduinoISP naar Arduino as ISP en druk ik op bootloader branden. 10x error:

Arduino: 1.6.3 (Windows 7), Board:"Arduino Micro"

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03

Ik heb hem even ingekort, maar alle 10 de pogingen hebben dezelfde error. En zoeken op deze error levert mij geen informatie op waar ik echt iets mee kan.

EDIT2: De Arduino blijft wel zichtbaar in apparaatbeheer en hij is ook gewoon zichtbaar in de Arduino omgeving, maar bij het uploaden van iets simpels als blink krijg ik ook de volgende melding:

Arduino: 1.6.3 (Windows 7), Board:"Arduino Micro"

De schets gebruikt 4.790 bytes (16%) programma-opslagruimte. Maximum is 28.672 bytes.

Globale variabelen gebruiken 151 bytes (5%) van het dynamisch geheugen. Resteren 2.409 bytes voor lokale variabelen. Maximum is 2.560 bytes.

avrdude: ser_open(): can't set com-state for "\\.\COM17"

avrdude: ser_send(): write error: sorry no info avail

En ja, hij zit op COM17, de immitatie zit daar ook op en die pakt hem wel gewoon op.

Inmiddels ook de drivers verwijderd en opnieuw erop gezet, dat had geen effect (behalve dat ik met de kloon moet initialiseren omdat de normale Arduino geen drivers gaf (bij de kloon hoefde ik niets te doen)).

[ Voor 22% gewijzigd door Pizza_Boom op 12-08-2015 13:43 ]

[RobV]

Waarom brand je een Arduino Pro Micro met ArduinoISP. Mijn Pro Micros zit gewoon een USB poort op.

Pro Micro:


Of heb je een pro mini?

Pro Mini:

[Pizza_Boom]

Nee, een Arduino Micro in Corporation with Adafruit. Een echte dus, in zo'n mooi klein doosje. En ik brand omdat ie niet reageert op de uploaden commando's.

Deze dus: http://www.arduino.org/products/arduino-micro

[ Voor 15% gewijzigd door Pizza_Boom op 12-08-2015 21:15 ]

[RobV]

Zoals in de PM gezegd ben ik inderdaad abuis. De Pro Micro is een SparkFun brouwsel, de Micro is een Adafruit/Arduino produkt. Ik was in de war met de oudere Nano.

[Pizza_Boom]

Het zijn er ook zoveel. En over de Micro is lang niet zoveel te vinden als de Nano en de Pro Micro.

Maargoed, nog iemand tips om te kijken of ik hem weer wakker geschud krijg? Blijf het vreemd vinden dat na een programmeeractie met timer3 er opeens niet meer gereageerd wordt door het apparaat. En het lijkt ook heel erg op een softwarematige fout in mijn eigen programmatuur, want het display valt terug naar 1 digit dat feller gaat branden op het moment dat dit gebeurt. Na een reset krijg ik trouwens de melding van Windows dat een USB apparaat niet herkend wordt en mogelijk niet goed werkt, na het opnieuw inpluggen krijg ik dat niet. En in apparaatbeheer is ie gewoon zichtbaar.

[SnowDude]

De bootloader zou via de isp altijd te programmeren moeten zijn. Zeker als er geen andere hardware aan de target board zit gekoppeld.

Bootloader programmeren is best simpel,

AVR ISP Software laden op programmer board.
Programmer instellen op Arduino as ISP (Niet ArduinoISP!!)
Boardtype van het target board selecteren in het menu.
Target board aansluiten met 6 draden



In het menu burn boatloader kiezen.

[Pizza_Boom]

SnowDude schreef op donderdag 13 augustus 2015 @ 15:56:
AVR ISP Software laden op programmer board.

Die ken ik niet. Ik heb wel, standaard uit de Arduino omgeving, de ArduinoISP en daarmee heb ik het geprobeerd.

Programmer instellen op Arduino as ISP (Niet ArduinoISP!!)
Boardtype van het target board selecteren in het menu.
Target board aansluiten met 6 draden

[afbeelding]

In het menu burn boatloader kiezen.

Heb ik allemaal gedaan en dan krijg ik de foutmeldingen. Ik heb het boardje zo aangesloten:

Behalve het feit dat in het echte boardje ook de 2 andere indicatieleds aangesloten zijn, maar hier niet ingetekend, omdat het anders wel erg onoverzichtelijk wordt.

Error:

Arduino: 1.6.3 (Windows 7), Board:"Arduino Micro"

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x03

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x03

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x03

Probleem bij het uploaden naar het board. Zie http://www.arduino.cc/en/Guide/Troubleshooting#upload voor suggesties.

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x03

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x03

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x03

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x03

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x03

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x03

Dit rapport zou meer informatie hebben met
"Tijdens de compilatie uitgebreide uitvoer weergeven"
ingeschakeld in Bestand > Voorkeuren.

[ Voor 47% gewijzigd door Pizza_Boom op 13-08-2015 17:03 ]

[RobV]

Ik zie geen aansluiting naar je reset lijn, kan dat kloppen?

Ik zie het al, boven ook een RST sorry.

edit: heb je gemeten of je gnd en 5v rail wel verbonden zijn? bij heel veel breadboards is de linker helft niet aan de rechterhelft verbonden. Dus even door meten of direct een jumper cable gebruiken.

[ Voor 89% gewijzigd door RobV op 13-08-2015 17:31 ]

[Pizza_Boom]

Rest lijn? Als je reset bedoelt, die komt vanaf 10 en is groen in het plaatje. Reset zit er dubbel op (beide kanten, 4e pin vanaf de drukknopkant geteld).

[RobV]

Pizza_Boom schreef op donderdag 13 augustus 2015 @ 17:32:
Rest lijn? Als je reset bedoelt, die komt vanaf 10 en is groen in het plaatje. Reset zit er dubbel op (beide kanten, 4e pin vanaf de drukknopkant geteld).

Ik had het al gecorrigeerd, sorry voor de verwarring.

[Pizza_Boom]

RobV schreef op donderdag 13 augustus 2015 @ 17:32:
[...]

Ik had het al gecorrigeerd, sorry voor de verwarring.

Ik zag het. Ik was ook al aan het editten, maar reageer zo wel. De originele micro, die dus opnieuw geprogrammeerd moet worden, heeft een powerled die permanent aan staat als ie stroom krijgt. Dus ik weet zeker dat die ook stroom krijgt, zie foto. Foto is nog net genomen dat de heartbeat led aan staat ook.

[ Voor 6% gewijzigd door Pizza_Boom op 13-08-2015 17:37 ]

[Vuikie]

Misschien een stomme vraag, maar heb jij de ArduinoISP sketch in de Arduino geladen die moet funcheren als programeer arduino???
Ik zie dit namelijk nergens in je posts terug(Of ik lees er overheen)
zie: File->examples->ArduinoISP

[Pizza_Boom]

Jup.

Momenteel in de Fablab en daar hebben we hem net met een USBASP werkend gehad, na wat gepiel. Zo ver zelfs dat ik hem gewoon weer kon programmeren. Totdat ik mijn programma erop zette, toen sloeg deze weer vast en deed ie niets meer. Dit is gekomen sinds ik met CTC bezig ben gegaan.

C:

#include <avr/interrupt.h>

const int SEG7A = 2;
const int SEG7B = 3;
const int SEG7C = 7;
const int SEG7D = 6;
const int SEG7E = 5;
const int SEG7F = A5;
const int SEG7G = 4;
const int SEG7DOT = 8;
const int BLA10 = 10;

const int SEL1 = A2;
const int SEL2 = A1;

int segment;
int segment1;
int segment2;



void setup() 
{
   pinMode(SEG7A, OUTPUT);
   pinMode(SEG7B, OUTPUT);
   pinMode(SEG7C, OUTPUT);
   pinMode(SEG7D, OUTPUT);
   pinMode(SEG7E, OUTPUT);
   pinMode(SEG7F, OUTPUT);
   pinMode(SEG7G, OUTPUT);
   pinMode(SEG7DOT, OUTPUT);
   pinMode(BLA10, OUTPUT);
  
  pinMode(SEL1, OUTPUT);
  pinMode(SEL2, OUTPUT);
  
  // timer1 initialisatie
  cli();              // disable general interrupt
  TCCR1A = 0;
  TCCR1B = 0;
  
  OCR1A = 155;              // ((16M/256)/400)-1
  TCCR1B |= (1 << WGM12);   // CTC enable
  TCCR1B |= (1 << CS12);    // prescaler /256
  TIMSK1 |= (1 << OCIE1A);  // enable timer1 interrupt flag by CTC
  sei();                    // reenable general interupt
  
}

ISR(TIMER1_OVF_vect)
{
  digitalWrite(BLA10, !digitalRead(BLA10));
}


void loop() {
  // put your main code here, to run repeatedly:
  
  segment1 = 2;
  segment = segment1;
  segmentcounter();  
  digitalWrite(SEL1, HIGH);
  digitalWrite(SEL2, LOW);
  delay(2);
  digitalWrite(SEL1, LOW);
  delay(1);
  segment2 = 8;
  segment = segment2;
  segmentcounter();
  digitalWrite(SEL1, LOW);
  digitalWrite(SEL2, HIGH);
  delay(2);
  digitalWrite(SEL2, LOW);
  delay(1);  
 
}

void segmentcounter(){
  
  digitalWrite(SEG7A, HIGH);
  digitalWrite(SEG7B, HIGH);
  digitalWrite(SEG7C, HIGH);
  digitalWrite(SEG7D, HIGH);
  digitalWrite(SEG7E, HIGH);
  digitalWrite(SEG7F, HIGH);
  digitalWrite(SEG7G, HIGH);
  digitalWrite(SEG7DOT, HIGH);
  delay(0);

  if(segment == 0)
  {
  digitalWrite(SEG7A, LOW);
  digitalWrite(SEG7B, LOW);
  digitalWrite(SEG7C, LOW);
  digitalWrite(SEG7D, LOW);
  digitalWrite(SEG7E, LOW);
  digitalWrite(SEG7F, LOW);
  digitalWrite(SEG7G, HIGH);
  digitalWrite(SEG7DOT, HIGH);
  }
}

Ik het het deel waarop we kiezen welk cijfer we weergeven even ingekort, maar dit is tot nu toe wat ik heb. Alles deed het toen ik nog niet met het preciezer instellen van de timing bezig was. Er gaat dus iets fout in de timing op het moment dat ik besluit voor de CTC modus te gaan.

EDIT: Inmiddels doet ie het weer, maar ik ben even huiverig met mijn programma erin zitten... Er gaat dus iets fout met de exactere timing bepalen, wellicht doordat er nog delays in het programma staan, maar dat durf ik niet met zekerheid te zeggen. Zou niet mogen, want het is een timer interrupt.

[ Voor 5% gewijzigd door Pizza_Boom op 13-08-2015 22:18 ]

[RobV]

Mooi dat je hem hebt weten te unbricken.

Wat je probeert te bereiken in de ISR is mij niet helemaal helder. Je flipt daar een pin maar ik zie veel andere code in je loop() staan

Update: misschien heb je wat aan de firmware van de Sparkfun 4 digit 7 segment display
https://github.com/sparkf..._Segment_Display_Firmware

Update 2:

Het gebruik van timers is wel handig, maar niet noodzakelijk. Als je de timers eventjes niet meer aandurft, maar wél verder wilt met je project, kun je er natuurlijk altijd voor kiezen om een oplossing te maken dmv de ‘blink without delay’ tactiek. Check deze link voor een goede tutorial hierover http://www.gammon.com.au/blink

[ Voor 70% gewijzigd door RobV op 14-08-2015 07:36 ]

[Pizza_Boom]

RobV schreef op vrijdag 14 augustus 2015 @ 07:13:
Mooi dat je hem hebt weten te unbricken.

Wat je probeert te bereiken in de ISR is mij niet helemaal helder. Je flipt daar een pin maar ik zie veel andere code in je loop() staan

Ik had daar een LED op gezet om te kijken wat er gebeurde met mijn timers en interrupts. Immers is de rest nog met delays uitgevoerd. Het is de bedoeling het grootste deel van de loop ook naar de isr te brengen, maar daar was ik nog niet.

Millis zet het programma niet vast? Want ik wil nog meer doen dan enkel wat weergeven.

[RobV]

Pizza_Boom schreef op vrijdag 14 augustus 2015 @ 11:42:
[...]

Millis zet het programma niet vast? Want ik wil nog meer doen dan enkel wat weergeven.

Dat is het hele idee van blink-withou-delay. Ik stel voor dat je de link nogmasls goed doorneemt. Het staat er toch duidelijk beschreven.

[D-Three]

Een ISR dient zo kort mogelijk te zijn. Het overgrote deel van jouw programma hoort in functies en de loop te zittten, niet in de ISR.

delay() zou normaal geen probleem mogen vormen, interrupts blijven werken bij het gebruik van delay(). Enig probleem met delay() is dat het effectief de rest van de uitvoering van code "blokkeert" (met uitzondering van de int's dus). Zit je dus met tijdskritische zaken of erg lange delay's dan is het gebruik van delay's af te raden. Maar hier heb je maar delay's van een paar milliseconden, ik zie niet in waarom die een probleem zouden vormen.

Er is dus iets anders verkeerd.

[RobV]

Misschien dat de digitalRead op een OUTPUT pin roet in het eten gooit, maar niet dat je je daarmee je arduino brickt. Ik zou je timer setup eens erg goed nakijken want een obvious fout zie ik niet.

[RobV]

En weet je zeker dat je ISr klaar is wanneer de volgende begint? Bijv. Door de frequentie veel te hoog te zetten, waardoor de cpu geen tijd overhoud voor andere dingen zoals de loop() of hardware irqs

[Pizza_Boom]

D-Three schreef op vrijdag 14 augustus 2015 @ 12:58:
Een ISR dient zo kort mogelijk te zijn. Het overgrote deel van jouw programma hoort in functies en de loop te zittten, niet in de ISR.

delay() zou normaal geen probleem mogen vormen, interrupts blijven werken bij het gebruik van delay(). Enig probleem met delay() is dat het effectief de rest van de uitvoering van code "blokkeert" (met uitzondering van de int's dus). Zit je dus met tijdskritische zaken of erg lange delay's dan is het gebruik van delay's af te raden. Maar hier heb je maar delay's van een paar milliseconden, ik zie niet in waarom die een probleem zouden vormen.

Er is dus iets anders verkeerd.

Wat er in de ISR moet komen, uiteindelijk, is het in en uitschakelen van de segmenten, het multiplex gedeelte. Het kiezen van het cijfer en dergelijke zou er ook niet in komen, het overgrote deel zou erbuiten blijven.

RobV schreef op vrijdag 14 augustus 2015 @ 13:04:
En weet je zeker dat je ISr klaar is wanneer de volgende begint? Bijv. Door de frequentie veel te hoog te zetten, waardoor de cpu geen tijd overhoud voor andere dingen zoals de loop() of hardware irqs

In de huidige code kan dat geen probleem opleveren, lijkt mij, dat is namelijk 1 regeltje. Okee, die digitalwrite kost 8 berekeningen en de digitalread zal ook wel zoiets zijn, maar dan nog. Op ongeveer 400 Hz (daarop zou die moeten draaien, 16.000.000 Hz processor, prescaler 256). Toch lijkt het er wel op, want zoals ik al zei, op het moment dat ik hem inschakelde gingen heel even de beide displays aan en daarna viel er een weg en bleef er nog eentje aan staan, zij het feller. Alsof hij bleef hangen. Het knipperen van de LED gebeurde helemaal niet meer (had ik ook niet verwacht).

RobV schreef op vrijdag 14 augustus 2015 @ 13:02:
Misschien dat de digitalRead op een OUTPUT pin roet in het eten gooit, maar niet dat je je daarmee je arduino brickt. Ik zou je timer setup eens erg goed nakijken want een obvious fout zie ik niet.

Er is ook geen obvious foutje, want dan had de compiler hem er wel uit geslingerd.

[SnowDude]

Pizza_Boom schreef op donderdag 13 augustus 2015 @ 16:59:
[...]
Die ken ik niet. Ik heb wel, standaard uit de Arduino omgeving, de ArduinoISP en daarmee heb ik het geprobeerd.

[...]
Heb ik allemaal gedaan en dan krijg ik de foutmeldingen. Ik heb het boardje zo aangesloten:
[afbeelding]
Behalve het feit dat in het echte boardje ook de 2 andere indicatieleds aangesloten zijn, maar hier niet ingetekend, omdat het anders wel erg onoverzichtelijk wordt.

Error:

Arduino: 1.6.3 (Windows 7), Board:"Arduino Micro"

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03

avrdude: stk500_recv(): programmer is not responding

Dit geeft al aan dat de programmer niet gevonden wordt door de arduino software. Dit geeft in aan dat je of de verkeerde programmer hebt geselecteerd onder Tools - > Programmer of dat de com poort fout is.

[LED-Maniak]

@Pizza_Boom

Timer0 - An 8 bit timer used by Arduino functions delay(), millis() and micros().

Toevallig de delay functie die timer1 gebruikt? Werkt het zonder delay functie wel?

Hoe je de pinnen instelt is overigens hopeloos traag. Kan je beter in een shift actie alle pinnen tegelijk doen. Is ook overzichtelijker.

[Pizza_Boom]

SnowDude schreef op vrijdag 14 augustus 2015 @ 15:20:
[...]
Dit geeft al aan dat de programmer niet gevonden wordt door de arduino software. Dit geeft in aan dat je of de verkeerde programmer hebt geselecteerd onder Tools - > Programmer of dat de com poort fout is.

Compoort was correct en programmer was Arduino as ISP bij de poging tot branden. Hij is inmiddels gedebrickt, dus voorlopig kan ik weer even voort.

LED-Maniak schreef op vrijdag 14 augustus 2015 @ 16:11:
Toevallig de delay functie die timer1 gebruikt? Werkt het zonder delay functie wel?

Dat heb ik niet geprobeerd. Met werkte het wel toen ik nog gewoon de timer volledig liet vollopen voordat ie een overflow gaf. Pas toen ik ben gaan klooien met de CTC en de aangepaste overflow is het fout gegaan. 2x. Dus dat zou goed kunnen, maar ik heb de balls niet om het nogmaals te proberen (ik heb hier geen USBASP (ga ik bestellen), dus als ie weer brickt zit ik vast).

Hoe je de pinnen instelt is overigens hopeloos traag. Kan je beter in een shift actie alle pinnen tegelijk doen. Is ook overzichtelijker.

Dat klopt en daarvan ben ik me bewust. Zoals ik al zei, het een en ander is nog in ontwikkeling. Mijn eerste doel was überhaupt een multiplexer maken, dat is gelukt, en nu stroomlijnen en versnellen, alle dubbele en zinloze delen eruit.

[LED-Maniak]

Pizza_Boom schreef op vrijdag 14 augustus 2015 @ 16:19:
[...]
Dat heb ik niet geprobeerd. Met werkte het wel toen ik nog gewoon de timer volledig liet vollopen voordat ie een overflow gaf. Pas toen ik ben gaan klooien met de CTC en de aangepaste overflow is het fout gegaan. 2x. Dus dat zou goed kunnen, maar ik heb de balls niet om het nogmaals te proberen (ik heb hier geen USBASP, dus als ie weer brickt zit ik vast).

Niet werkende code programmeren heeft totaal niets te maken met het wel of niet kunnen programmeren. Daar gaat dus iets anders fout.

Ik gok dat de arduino omgeving op de achtergrond je timers gaat instellen op een andere manier dan dat jij wil(nog een reden om naar avrstudio te gaan ).

Voor 10 euro ofzo koop je een AVRISP MKII kloon op ebay. Mooie investering als je eens wat meer wilt doen(+je hebt meer ruimte voor code) en nog handiger dat bricken niet zo snel zal gaan(dat herstel je immers zo ).

[ Voor 12% gewijzigd door LED-Maniak op 14-08-2015 16:25 ]

[SnowDude]

Pizza_Boom schreef op vrijdag 14 augustus 2015 @ 16:19:
[...]
Compoort was correct en programmer was Arduino as ISP bij de poging tot branden. Hij is inmiddels gedebrickt, dus voorlopig kan ik weer even voort.
[...]
Dat heb ik niet geprobeerd. Met werkte het wel toen ik nog gewoon de timer volledig liet vollopen voordat ie een overflow gaf. Pas toen ik ben gaan klooien met de CTC en de aangepaste overflow is het fout gegaan. 2x. Dus dat zou goed kunnen, maar ik heb de balls niet om het nogmaals te proberen (ik heb hier geen USBASP, dus als ie weer brickt zit ik vast).

[...]
Dat klopt en daarvan ben ik me bewust. Zoals ik al zei, het een en ander is nog in ontwikkeling. Mijn eerste doel was überhaupt een multiplexer maken, dat is gelukt, en nu stroomlijnen en versnellen, alle dubbele en zinloze delen eruit.

Als je zorgt dat je bootloader programmer werkt, dan durf je weer te experimenteren.

[Pizza_Boom]

LED-Maniak schreef op vrijdag 14 augustus 2015 @ 16:21:
Niet werkende code programmeren heeft totaal niets te maken met het wel of niet kunnen programmeren. Daar gaat dus iets anders fout.

Maar de code werkte wel. Ik heb er een LED extra bij gestoken en die ging keurig knipperen, afhankelijk van de presecaler deed ie dit zeer rustig of redelijk vlot.

Ik gok dat de arduino omgeving op de achtergrond je timers gaat instellen op een andere manier dan dat jij wil(nog een reden om naar avrstudio te gaan ).

Voor 10 euro ofzo koop je een AVRISP MKII kloon op ebay. Mooie investering als je eens wat meer wilt doen(+je hebt meer ruimte voor code) en nog handiger dat bricken niet zo snel zal gaan(dat herstel je immers zo ).

Zou een mogelijkheid zijn. Ik durf het niet te zeggen. Geloof dat ie gister inderdaad van AVR Studio op zijn donder heeft gehad. Was nog wel werk, want eerst moest ie helemaal leeg geveegd worden, anders liet een andere bootloader zich niet branden. Best een koppig ding dus. En dit is al onderweg. Daarmee is het gister ook gelukt.

SnowDude schreef op vrijdag 14 augustus 2015 @ 16:21:
[...]

Als je zorgt dat je bootloader programmer werkt, dan durf je weer te experimenteren.

Ik dacht altijd dat je met een normale andere Arduino ook je bootloader weer kon branden, dus dat heb ik geprobeerd (binnen de Arduino omgeving wordt zo'n mooi stukje programma meegeleverd), maar dat werkte blijkbaar niet. Het was in ieder geval een vreemde storing, want na stroomloos gestaan te hebben aankoppelen ging prima, dan zag de PC hem ook, maar kon Arduino er niets mee, na een reset middels de resetknop was het opeens ook een foutief USB apparaat en zag de Arduino omgeving hem ook niet meer.

[SnowDude]

Pizza_Boom schreef op vrijdag 14 augustus 2015 @ 16:42:

[...]
Ik dacht altijd dat je met een normale andere Arduino ook je bootloader weer kon branden, dus dat heb ik geprobeerd (binnen de Arduino omgeving wordt zo'n mooi stukje programma meegeleverd), maar dat werkte blijkbaar niet. Het was in ieder geval een vreemde storing, want na stroomloos gestaan te hebben aankoppelen ging prima, dan zag de PC hem ook, maar kon Arduino er niets mee, na een reset middels de resetknop was het opeens ook een foutief USB apparaat en zag de Arduino omgeving hem ook niet meer.

Dat moet ook gewoon kunnen. ik heb al tientallen keren een boatloader geburned met zowel (clone) nano's als uno's en mega's en ik heb nog nooit problemen gehad. Bij jou was er duidelijk el een probleem tussen de PC en de "programmer" arduino

[Pizza_Boom]

SnowDude schreef op vrijdag 14 augustus 2015 @ 17:04:
[...]

Dat moet ook gewoon kunnen. ik heb al tientallen keren een boatloader geburned met zowel (clone) nano's als uno's en mega's en ik heb nog nooit problemen gehad. Bij jou was er duidelijk el een probleem tussen de PC en de "programmer" arduino

Dan snap ik alleen niet waarom ik allerhande sketches en dergelijke er wel gewoon zonder problemen op kreeg. Blink, ArduinoISP, andere programma's van mijzelf.

[RobV]

Pizza_Boom schreef op vrijdag 14 augustus 2015 @ 17:10:
[...]
Dan snap ik alleen niet waarom ik allerhande sketches en dergelijke er wel gewoon zonder problemen op kreeg. Blink, ArduinoISP, andere programma's van mijzelf.

Het is verwarrend omdat je goed moet opletten welke van de 2 Arduino’s de ArduinoISP of de Blink sketch krijgt toegestuurd. En dat risico/verwarring is de deur uit met een basic USBAsp programmertje van $3.

[Pizza_Boom]

RobV schreef op vrijdag 14 augustus 2015 @ 17:21:
[...]

Het is verwarrend omdat je goed moet opletten welke van de 2 Arduino’s de ArduinoISP of de Blink sketch krijgt toegestuurd. En dat risico/verwarring is de deur uit met een basic USBAsp programmertje van $3.

De Arduino die slecht is hang je als slave via de SPI aan de Aduino die je de ArduinoISP sketch hebt gegeven, vervolgens selecteer je als programmer de Arduino as ISP en druk je op bootloader branden (omdat ik 2 Micro's gebruik hoef ik dat niet aan te passen). Lijkt mij de juiste manier?

[RobV]

Pizza_Boom schreef op vrijdag 14 augustus 2015 @ 17:38:
[...]
De Arduino die slecht is hang je als slave via de SPI aan de Aduino die je de ArduinoISP sketch hebt gegeven, vervolgens selecteer je als programmer de Arduino as ISP en druk je op bootloader branden (omdat ik 2 Micro's gebruik hoef ik dat niet aan te passen). Lijkt mij de juiste manier?

Klinkt alsof het zou moeten kloppen. Als je tenminste ook de juiste target board type (Arduino Micro) hebt geselecteerd voor beide uploads. Het uploaden van een Uno firmware naar een Micro gaat waarschijnlijk niet werken.

Ik moet zeggen dat ik ooit 1x een ArduinoAsISP heb gebruikt (dat was met 1x Arduino Uno als ISP en 1x Mini als target), maar dat was dus met andere CPU’s. Ik heb geen flauw idee of die truck ook werkt met Micro’s.

[D-Three]

LED-Maniak schreef op vrijdag 14 augustus 2015 @ 16:11:
Toevallig de delay functie die timer1 gebruikt? Werkt het zonder delay functie wel?

delay gebruikt Timer0 (heb ik ook even moeten opzoeken hoor )

Pizza_Boom schreef op vrijdag 14 augustus 2015 @ 14:35:op het moment dat ik hem inschakelde gingen heel even de beide displays aan en daarna viel er een weg en bleef er nog eentje aan staan, zij het feller. Alsof hij bleef hangen. Het knipperen van de LED gebeurde helemaal niet meer (had ik ook niet verwacht).

Als ik zou jouw code bekijk zoals je die gepost hebt, lijkt me dat wel ongeveer wat er moet gebeuren? Je zet bepaalde pinnen van een segment hoog en anders wijzigt er weinig?

Dat de LED niet knippert, ligt dan waarschijnlijk aan een foutje van de interrupt. En mij lijkt daar inderdaad niet te kloppen. Timer1 is een 16-bit teller. Dat wil zeggen dat die aan een bepaalde snelheid telt van 0 tot 65535. Meer doet dat niet, het is in principe een dom ding

Een timer genereert wel verschillende interrupts. Zo heb je overflow, de interrupt-routine die jij gebruikt (OVF), deze triggert wanneer de teller zijn max heeft bereikt en dus overloopt. Dan heb je ook ook compare waarbij een interrupt wordt gegenereerd wanneer de waarde van de teller gelijk is aan een bepaalde ingestelde waarde. Daar moet dus ergens iets verkeerd zijn. Ik herinner me wel uit mijn PIC-periode dat ik timers wel moet resetten of presetten. Waarschijnlijk is dit hier ook het geval.

edit:
Het klopt waarschijnlijk niet, jouw setup is om de compare-interrupt te gebruiken maar jouw ISR is overflow, zie: http://blog.oscarliang.ne...r-and-interrupt-tutorial/
Ik ben niet zeker dat het dat is maar zou best kunnen.

[ Voor 7% gewijzigd door D-Three op 14-08-2015 18:45 ]

[LED-Maniak]

Resetten van een timer hoef je niet in een AVR, tenzij het een single-shot is.

Ik zie nu wel hetgeen wat volgens mij niet klopt...

code:

ISR(TIMER1_OVF_vect)
{
  digitalWrite(BLA10, !digitalRead(BLA10));
}

Dit moet zijn:

code:

ISR (TIMER1_COMPA_vect)
{
  digitalWrite(BLA10, !digitalRead(BLA10));
}

Overigens... als BLA10 staat voor bijvoorbeeld PB1 (portb pin 1) dan is deze code veel sneller om een LED te togglen:

code:

ISR (TIMER1_COMPA_vect)
{
  PORTB ^= (1<<PB1);
}

In je huidige code zal hij naar de locatie van TIMER1_COMPA gaan waar een verwijzing naar 0 staat en je programma reset. Dan begint je AVR dus constant bij locatie 0; Wat in de buurt komt van een reset.

[ Voor 21% gewijzigd door LED-Maniak op 14-08-2015 18:50 ]

[RobV]

Ode aan LED-Maniak

[Pizza_Boom]

D-Three schreef op vrijdag 14 augustus 2015 @ 18:41:
Als ik zou jouw code bekijk zoals je die gepost hebt, lijkt me dat wel ongeveer wat er moet gebeuren? Je zet bepaalde pinnen van een segment hoog en anders wijzigt er weinig?

Ja en nee. Ik heb een duo 7 segment en die moeten gemultiplexed worden. Dat deed ik in het begin met de delayfunctie die in de loop staat. Dat deed de Arduino ook niet meer. Het opstarten gebeurde met beide displays, maar na een seconde of 2-3 viel het tweede display eraf (en werd het eerste sterker). Hij bleef dus ergens in de code hangen, hetgeen blijkbaar zo erg was dat de hele Arduino vast liep. Wellicht in de hieronder genoemde ISR.

Dat de LED niet knippert, ligt dan waarschijnlijk aan een foutje van de interrupt. En mij lijkt daar inderdaad niet te kloppen. Timer1 is een 16-bit teller. Dat wil zeggen dat die aan een bepaalde snelheid telt van 0 tot 65535. Meer doet dat niet, het is in principe een dom ding

Een timer genereert wel verschillende interrupts. Zo heb je overflow, de interrupt-routine die jij gebruikt (OVF), deze triggert wanneer de teller zijn max heeft bereikt en dus overloopt. Dan heb je ook ook compare waarbij een interrupt wordt gegenereerd wanneer de waarde van de teller gelijk is aan een bepaalde ingestelde waarde. Daar moet dus ergens iets verkeerd zijn. Ik herinner me wel uit mijn PIC-periode dat ik timers wel moet resetten of presetten. Waarschijnlijk is dit hier ook het geval.

Je bedoelt, de interrupt flag weer naar 0 zetten. Interrupts ken ik ook uit de PIC wereld, vandaar dat ik geen gebruik wil maken van de library's.

edit:
Het klopt waarschijnlijk niet, jouw setup is om de compare-interrupt te gebruiken maar jouw ISR is overflow, zie: http://blog.oscarliang.ne...r-and-interrupt-tutorial/
Ik ben niet zeker dat het dat is maar zou best kunnen.

Hetzelfde als LED zegt dus.

LED-Maniak schreef op vrijdag 14 augustus 2015 @ 18:45:
Resetten van een timer hoef je niet in een AVR, tenzij het een single-shot is.

Ik zie nu wel hetgeen wat volgens mij niet klopt...

code:

ISR(TIMER1_OVF_vect)
{
  digitalWrite(BLA10, !digitalRead(BLA10));
}

Dit moet zijn:

code:

ISR (TIMER1_COMPA_vect)
{
  digitalWrite(BLA10, !digitalRead(BLA10));
}

Overigens... als BLA10 staat voor bijvoorbeeld PB1 (portb pin 1) dan is deze code veel sneller om een LED te togglen:

code:

ISR (TIMER1_COMPA_vect)
{
  PORTB ^= (1<<PB1);
}

In je huidige code zal hij naar de locatie van TIMER1_COMPA gaan waar een verwijzing naar 0 staat en je programma reset. Dan begint je AVR dus constant bij locatie 0; Wat in de buurt komt van een reset.

Klinkt logisch. Zou dat de reden zijn dat ie bleef hangen na een paar seconde? En echt nergens meer op reageerde? Klinkt dat plausibel voor een Arduino?

[LED-Maniak]

Ja dat kan zeker. Het is maar net waar die vector naar verwijst. Waarschijnlijk default naar adres 0 en dus helemaal het begin van je arduino. Als het goed is staat daar de bootloader code.

Er kan op die manier van alles gebeuren. Speculatie zou zijn dat je timer na verspringen nog steeds loopt maar de code in een wacht loop komt. Na een paar seconde verstrijkt die loop en wordt de interrupt ergens uitgezet.

Het kan dan handig zijn om in ieder geval alle interrupts van peripherals die aan staan te definiëren met een ISR() maar daarna leeg te laten. Dan keert hij in ieder geval weer terug.

Met AVRStudio kan je dit gedrag waarschijnlijk wel simuleren. Dan zie je hem na stappen maken vastlopen/verspringen ergens.

[RobV]

Het .Net-micro framework had on-device debugging (breakpoints, register inspector enz). Dat was echt awesome.

[LED-Maniak]

Dat kan elke AVR die JTAG ondersteunt met JTAG ICE of de Dragon:
http://www.dx.com/nl/p/av...QaAh-s8P8HAQ#.Vc5LBbfZ9E4

Wederom via AVRStudio zonder extra framework er omheen.

[ Voor 15% gewijzigd door LED-Maniak op 14-08-2015 22:12 ]

[Pizza_Boom]

Toch even dapper mijn stoute schoenen aangedaan en de ISR vector van Timer1 verandert. Et voila, nu loopt ie niet vast. Daar zat dus het probleem. Gaan we nu weer door met het leuke deel, een mooie multiplexroutine schrijven voor mijn 7 segmentjes.

[Pizza_Boom]

LED-Maniak schreef op vrijdag 14 augustus 2015 @ 22:10:
Lokquote

Mijn code. Zoals ik zei, ik gebruik nog gewoon de pinMode functies in setup. Naast de dwarsliggende Ax poort als output, heb ik ook wat ruzie met andere dan numerieke waarden in mijn if statements. Ik probeerde bijvoorbeeld om de code waar nu 123 staat, te gebruiken als OFF en UIT, maar dat kreeg ik niet voor elkaar. Iedere keer sprong de code toch door naar de 0, terwijl ik dat segment dan juist uit wilde hebben. Vervelend, want ik wil er nog meer mee laten draaien dan alleen getallen. Ik heb OFF en UIT in het if statement geprobeert, zowel als OFF, als 'OFF' en als "OFF". Alleen met een numerieke waarde lukte het, daarom dat ik nu maar even 123 neergezet heb.

Ik neem verder aan dat ik, als ik voor een interrupt op pin ga, deze instellingen gewoon binnen de cli() en sei() statements kan plaatsen, waar ik nu ook de timer1 declareer?

C:

#include <avr/interrupt.h>

const int SEG7A = 2;  //PORT D1
const int SEG7B = 3;  //PORT D0
const int SEG7C = 7;  //PORT E6
const int SEG7D = 6;  //PORT D7
const int SEG7E = 5;  //PORT C6
const int SEG7F = 13; //PORT C7
const int SEG7G = 4;  //PORT D4
const int SEG7DOT = 8;//PORT B4

const int SEL1 = A2;  //PORT F5
const int SEL2 = A1;  //PORT F6

unsigned char segment;
int segment1;
int segment2;
int teller = 99;
unsigned char uff;

long VorigeMilli = 0;
long interval = 1000;


void setup() 
{
   pinMode(SEG7A, OUTPUT);
   pinMode(SEG7B, OUTPUT);
   pinMode(SEG7C, OUTPUT);
   pinMode(SEG7D, OUTPUT);
   pinMode(SEG7E, OUTPUT);
   pinMode(SEG7F, OUTPUT);
   pinMode(SEG7G, OUTPUT);
   pinMode(SEG7DOT, OUTPUT);
  
  pinMode(SEL1, OUTPUT);
  pinMode(SEL2, OUTPUT);
  
  // timer1 initialisatie
  cli();              // disable general interrupt
  TCCR1A = 0;
  TCCR1B = 0;
  
  OCR1A = 155;              // ((16M/256)/400)-1 = 400 Hz
  TCCR1B |= (1 << WGM12);   // CTC enable
  TCCR1B |= (1 << CS12);    // prescaler /256
  TIMSK1 |= (1 << OCIE1A);  // enable timer1 interrupt flag by CTC
  sei();                    // reenable general interupt
  
}

ISR(TIMER1_COMPA_vect)
{
  static unsigned char HuidigSegment =0;
  
  switch (HuidigSegment++)
  {
    case 0:
    PORTF = (0<<PF6);
    segment = segment1;
    segmentcounter();
    PORTF = (1<<PF5);
    break;
    case 1:
    PORTF = (0<<PF5);
    segment = segment2;
    segmentcounter();
    PORTF = (1<<PF6);
    break;
  }
    if(HuidigSegment >= 2)
      HuidigSegment = 0;
  
}


void loop() {

  unsigned long NuMilli = millis();
  if (NuMilli - VorigeMilli > interval)
    {
      segment1 = (teller/10);    // Display 1 is meest rechts
      segment2 = (teller%10);    // Display 2 van rechts
      VorigeMilli = NuMilli;
      if(teller == 0)
        teller = 100;
      teller--;
    }
  

}

void segmentcounter(){
/*  
  PORTD = (1<<PD1);    // Segment A
  PORTD = (1<<PD0);    // Segment B
  PORTE = (1<<PE6);    // Segment C
  PORTD = (1<<PD7);    // Segment D
  PORTC = (1<<PC6);    // Segment E
  PORTC = (1<<PC7);    // Segment F
  PORTD = (1<<PD4);    // Segment G
  PORTB = (0<<PB4);    // Segment DOT
*/  
  if(segment == 123)
  {
    PORTD = (1<<PD1 | 1<<PD0 | 1<< PD7 | 1<<PD4);    // Segment A off, Segment B off, Segment D off, Segment G off
    PORTE = (1<<PE6);                                // Segment C off
    PORTC = (1<<PC6 | 1<<PC7);                       // Segment E off, Segment F off
    PORTB = (1<<PB4);                                // Segment DOT off
    goto END;
  }
  
  if(segment == 0)
  {
    PORTD = (0<<PD1 | 0<<PD0 | 0<< PD7 | 1<<PD4);    // Segment A on, Segment B on, Segment D on, Segment G off
    PORTE = (0<<PE6);                                // Segment C on
    PORTC = (0<<PC6 | 0<<PC7);                       // Segment E on, Segment F on
    PORTB = (1<<PB4);                                // Segment DOT off
    goto END;
  }

  if(segment == 1)
  {
    PORTD = (1<<PD1 | 0<<PD0 | 1<< PD7 | 1<<PD4);    // Segment A off, Segment B on, Segment D off, Segment G off
    PORTE = (0<<PE6);                                // Segment C on
    PORTC = (1<<PC6 | 1<<PC7);                       // Segment E off, Segment F off
    PORTB = (1<<PB4);                                // Segment DOT off
    goto END;
  }
}

[LED-Maniak]

Je code klopt toch niet helemaal.

Als je een enkele pin aan zet doe je dat zo:
PORTB |= (1<<PB1);

Zet je hem uit doe je dat zo:
PORTB &= ~(1<<PB1);

Zet je alle pinnen behalve een pin aan dan doe je het zo:
PORTB = (1<<PB1);

Dat heeft te maken met bit-wise operations(is veel over te vinden).

Door de manier dat je het nu opschrijft beïnvloed je alle pinnen op een poort. Ook pinnen die waarschijnlijk een andere functie hebben.

Bijvoorbeeld hier:

code:

    case 0:
    PORTF = (0<<PF6);
    segment = segment1;
    segmentcounter();
    PORTF = (1<<PF5);
    break;

Je maakt eerst PORTF geheel 0(alles uit);
Daarna zet je PF5 hoog en alles laag. Het zal werken, maar gaat je later problemen opleveren als je PF2 wilt gebruiken.

Dat kan beter zo:

code:

    case 0:
    PORTF &= ~(1<<PF6);
    segment = segment1;
    segmentcounter();
    PORTF |= (1<<PF5);
    break;

Kan je toevallig alle segment delen op één port kwijt? Port is 8 bits dus met 7 segmenten + dot moet dat kunnen. Dan is het namelijk nog veel simpeler om aan te sturen.


Dat hij 123 niet pakt als dat wel in je unsigned char staat is vreemd. Let wel: als je met interrupts en global variables gaat werken dan kan je er beter volatile unsigned char van maken. Dit zegt tegen de compiler dat hij dat niet moet optimaliseren maar altijd de juiste waarde pakt.


In je void segmentcounter(){} zou ik toch wel echt met if else if en else werken. Als hij een karakter dan niet herkent, gaat het display automatisch uit bijvoorbeeld.

code:

if(segment == 0){
//show 0
}
else if(segment == 1){
//show 1
}
else{
//turn all off
}

goto END heb je nu ook niet meer nodig.

[ Voor 21% gewijzigd door LED-Maniak op 16-08-2015 13:57 ]

[Pizza_Boom]

LED-Maniak schreef op zondag 16 augustus 2015 @ 13:50:
Dat heeft te maken met bit-wise operations(is veel over te vinden).

Door de manier dat je het nu opschrijft beïnvloed je alle pinnen op een poort. Ook pinnen die waarschijnlijk een andere functie hebben.

Bijvoorbeeld hier:

Je maakt eerst PORTF geheel 0(alles uit);
Daarna zet je PF5 hoog en alles laag. Het zal werken, maar gaat je later problemen opleveren als je PF2 wilt gebruiken.

Dat zou dus verklaren waarom die ene pin op de analog telkens dwars lag, die werd op een ander moment aangestuurd.

Kan je toevallig alle segment delen op één port kwijt? Port is 8 bits dus met 7 segmenten + dot moet dat kunnen. Dan is het namelijk nog veel simpeler om aan te sturen.

Dat gaat niet lukken, van PF (de Analog) heb ik 6 pinnen (A0 - A5) en van PD heb ik er 7, maar dan pak ik wel RX en TX mee. En ik moet gaan verplaatsen, want 2 en 3 (PD0 en PD1) zijn de I2C SDA en SDL pinnen en ik wil er een RTC aan hangen, dus die ga ik nodig hebben. Even kijken hoe ik het dan over zet naar de RX en TX. De SPI pinnen zijn nodig voor de nRF, dus het is even puzzelen. Zie dit plaatje:

Dat hij 123 niet pakt als dat wel in je unsigned char staat is vreemd. Let wel: als je met interrupts en global variables gaat werken dan kan je er beter volatile unsigned char van maken. Dit zegt tegen de compiler dat hij dat niet moet optimaliseren maar altijd de juiste waarde pakt.

Ik denk dat je mij niet goed begrijpt, 123 pakt ie wel, maar juist OFF en UIT pakt ie niet. Alleen numerieke waardes worden, ondanks dat het een char is, geaccepteerd.

In je void segmentcounter(){} zou ik toch wel echt met if else if en else werken. Als hij een karakter dan niet herkent, gaat het display automatisch uit bijvoorbeeld.

code:

if(segment == 0){
//show 0
}
else if(segment == 1){
//show 1
}
else{
//turn all off
}

goto END heb je nu ook niet meer nodig.

Die ga ik nog eens overwegen. Ik heb nu bewust voor de if en goto gekozen, omdat ervaring uit het verleden leert dat de if/else statements niet altijd soepel doorlopen worden. Maar Arduino heeft daar dus geen last van.

[RobV]

Waar zijn Off en UIT gedefinieerd?
Je kunt geen strings of char[] met een == vergelijken.

[LED-Maniak]

Pizza_Boom schreef op zondag 16 augustus 2015 @ 14:14:
[...]
Ik denk dat je mij niet goed begrijpt, 123 pakt ie wel, maar juist OFF en UIT pakt ie niet. Alleen numerieke waardes worden, ondanks dat het een char is, geaccepteerd.

Ah zo.. ik was al in verwarring.
een unsigned char is niets anders dan een 8-bit byte. Als je OFF en UIT wilt dan heb je het over een string. Dat is immers 3 chars = 3 bytes O, F en F.

Je kan wel doen:
#define OFF 123
#define UIT 124


if(segment == OFF){}

Je compiler vervangt die OFF door 123. Het is alleen leesbaarder.

[...]
Die ga ik nog eens overwegen. Ik heb nu bewust voor de if en goto gekozen, omdat ervaring uit het verleden leert dat de if/else statements niet altijd soepel doorlopen worden. Maar Arduino heeft daar dus geen last van.

Als if en else fout gaat, dan is er iets anders in de code mis. Het is een basaal ding in C code. Allemaal if en goto achter elkaar is niet echt heel netjes.

[ Voor 6% gewijzigd door LED-Maniak op 16-08-2015 14:22 ]

[RobV]

LED-Maniak schreef op zondag 16 augustus 2015 @ 13:50:

code:

if(segment == 0){
//show 0
}
else if(segment == 1){
//show 1
}
else{
//turn all off
}

Als ik even mag inhaken zonder bijdehand te klinken

Als je een if/elseif/else straatje gaat doen op basis van dezelfde variabele en een aantal constante waarden kun je veel beter een switch statement pakken

code:

switch(segment)
{
   case 0 :
         //stapjes
         break;
   case 1 :
         //stapjes
         break;
   case 123 :
         //stapjes
         break;
    default:
        //alle andere gevallen
        break;
}

wel eventje opletten dat je de break niet vergeet.

nummer 2, constanten
In Arduino-land (en misschien ook elders) kun je beter een const pakken dan een define. Een const is namelijk typed en een define niet. Daarmee voorkom je dat je een constante voor een string definieert en die dan als integer gaat gebruiken.

code:

const int OFF = 0;
const int ON = 1;

//deze regel zal niet compileren.
const int OFF = "OFF";

Een const gebruiken is zelfs nog efficiënter ook, want een #define die je 2x gebruikt wordt 2x in memory geplaatst terwijl een const altijd dezelfde resource gebruikt (een ook nog eens in flash gezet kan worden).

Zo. Nu terug naar LED.

[ Voor 26% gewijzigd door RobV op 16-08-2015 17:44 ]

[LED-Maniak]

RobV schreef op zondag 16 augustus 2015 @ 17:38:
[...]
Als je een if/elseif/else straatje gaat doen op basis van dezelfde variabele en een aantal constante waarden kun je veel beter een switch statement pakken

Niet per definitie.

Omdat dit in een interrupt wordt afgehandeld wil je dit zo snel mogelijk
Een switch is trager dan een if/else constructie en kost je dus meer klokticks.

Dit is wel weer afhankelijk van je compiler en hoe groot die switch is(of de extra code van een hash/jump tabel je meer oplevert). Of bijvoorbeeld je al 99% van de statements oppikt met de eerste if/else if.

nummer 2, constanten
In Arduino-land (en misschien ook elders) kun je beter een const pakken dan een define. Een const is namelijk typed en een define niet. Daarmee voorkom je dat je een constante voor een string definieert en die dan als integer gaat gebruiken.

Dat is inderdaad een voordeel.

Een const gebruiken is zelfs nog efficiënter ook, want een #define die je 2x gebruikt wordt 2x in memory geplaatst terwijl een const altijd dezelfde resource gebruikt (een ook nog eens in flash gezet kan worden).

Om dit verhaal hard te maken zullen we eens in de assembly code moeten duiken.
Afhankelijk van de compiler, hoe vaak je die constant gebruikt en optimization level zal je nog verrassende resultaten tegenkomen.. Wederom: we willen het in een interrupt draaien.


Aan de andere kant.. We zitten in het hopeloos inefficiënte arduino land dus of dit dan weer discussie waardig is... 90% van de tijd komt het neer op waar je het meest comfortabel mee bent.

[ Voor 7% gewijzigd door LED-Maniak op 16-08-2015 18:35 ]

[RobV]

Mijn opmerkingen gingen niet per sé om 'het onderste uit de kan halen', maar om leerbare code te onderhouden. Als je het elke micro-seconde uit je ISR wilt halen moet je in mijn optiek de andere code ook grondig onder de loep nemen. Een oud gezegde: eerst zorgen dat het werkt, daarna mag je het mooier/sneller/beter maken.

De discussie over de #define vs const op Arduino is overigens al een aantal keren uitgebreid gevoerd op het ons welbekende internet. Voor wat ik tot nu toe gelezen heb zal de compiler optimiser zal het geheugengebruik over het algemeen wel rechttrekken, maar het voordeel van typed constants is voor mij de doorslaggevende factor bij het produceren van stabiele code. Het zal een #define een worst wezen of je een 0xffff in een uint8_t probeert te vrotten en aangezien de definitie en de usage vaak aan de andere uiteinden van de code (of andere bestandjes, ergens diep in een library) staat maakt het geheel er niet makkelijker op.

[Sissors]

Ik denk eerder dat define minder geheugen gebruikt dan const. Omdat een compiler met een define helemaal mag doen wat ie leuk vindt, terwijl het met een const een stuk vaster ligt. Voeg daaraan toe dat bij Arduino een const niet automagisch het flash in gaat, en het kost je ook RAM.

Const heeft wel voordelen, dat hij typed is, en als je dus een enkele gebruikt is het helemaal prima en waarschijnlijk de beste keuze.

[RobV]

Sissors schreef op zondag 16 augustus 2015 @ 19:48:
Ik denk eerder dat define minder geheugen gebruikt dan const. Omdat een compiler met een define helemaal mag doen wat ie leuk vindt, terwijl het met een const een stuk vaster ligt. Voeg daaraan toe dat bij Arduino een const niet automagisch het flash in gaat, en het kost je ook RAM.

Dat was mijn eerste gevoel ook.

Arduino UNO, Arduino IDE 1.6.5 op OS X 10.11 beta 6. Dit voorbeeld gebruik ik specifiek de constanten meerdere keren.

code:

const uint8_t PIN_BLINK = 13;
const unsigned long PAUSE = 500L;

void setup() {
  pinMode(PIN_BLINK, OUTPUT);

}

void loop() {
  digitalWrite(PIN_BLINK, HIGH);
  delay(PAUSE);
  digitalWrite(PIN_BLINK, LOW);
  delay(PAUSE);
}

output:

code:

Sketch uses 1,030 bytes (3%) of program storage space. Maximum is 32,256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2,039 bytes for local variables. Maximum is 2,048 bytes.

Nu met #defines

code:

#define PIN_BLINK 13
#define PAUSE 500L

code:

Sketch uses 1,030 bytes (3%) of program storage space. Maximum is 32,256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2,039 bytes for local variables. Maximum is 2,048 bytes.

Conclusie: voor DIT voorbeeld maakt het geen drol uit. De compiler heeft het geheugengebruik geoptimaliseerd.

Aanvulling: je kunt #defines voor meer dingen gebruiken van pin constanten, bijvoorbeeld voor macro's en multi-target code. Die varianten heb ik bewust buiten beschouwing gelaten.

Const heeft wel voordelen, dat hij typed is, en als je dus een enkele gebruikt is het helemaal prima en waarschijnlijk de beste keuze.

De reden waarom het mijn voorkeur geniet.

[Pizza_Boom]

LED-Maniak schreef op zondag 16 augustus 2015 @ 13:50:
Als je een enkele pin aan zet doe je dat zo:
PORTB |= (1<<PB1);

Zet je hem uit doe je dat zo:
PORTB &= ~(1<<PB1);

Zet je alle pinnen behalve een pin aan dan doe je het zo:
PORTB = (1<<PB1);

Hieruit begrijp ik dus ook dat het gebruik van meerdere statements in 1 regel allen dus gelijk moeten zijn, allemaal of aan of uit?

Dit zou dus mogen:
PORTD |= (1<<PD1 | 1<<PD0 | 1<< PD7 | 1<<PD4);

En dit niet?
PORTD |= (0<<PD1 | 1<<PD0 | 0<< PD7 | 1<<PD4);

Die zou ik dus moeten splitsen tot:
PORTD |= (1<<PD0 | 1<<PD4);
PORTD &=~(1<<PD1 | 1<<PD4);
En dat uitzetten moet dus niet met:
PORTD &=~(0<<PD1 | 0<<PD4);

[LED-Maniak]

Om dat te begrijpen is het het beste om te weten wat hier nu werkelijk gebeurt.

Hier staan wat voorbeelden:
http://www.micahcarrick.c...al/avr-c-programming.html
Wikipedia: Bitwise operation
Wikipedia: Bitwise operations in C

Er zijn vast nog wel duidelijkere voorbeelden te vinden.

Stel je voor dat PORTD initieel dit is: 0b10101011 (PD7, 5, 3, 1, 0 staan dus aan/hoog)

Dan gebeurt er dit:

code:

PORTD |= (1<<PD1 | 1<<PD0 | 1<< PD7 | 1<<PD4);
PORTD = 0b10101011 | 0b10010011;

OR-operatie:
           0b10101011
           0b10010011
Resultaat: 0b10111011

Dan pak ik de volgende:

code:

PORTD |= (0<<PD1 | 1<<PD0 | 0<< PD7 | 1<<PD4);
PORTD = 0b10101011 | 0b00010001;

OR-operatie:
           0b10101011
           0b00010001
Resultaat: 0b10111011 (PD7, 5, 4, 3, 1, 0 aan/hoog)

Aiii... Dat was niet de bedoeling! Je doel was om 1 en 7 uit te zetten!


Dit werkt hetzelfde voor het uitzetten alleen dan heb je een extra stap(je doet een AND(&) en een NOT(~))


Bitwise manipulatie zoals hierboven is een belangrijk iets bij microcontrollers. Hierbij hoort ook shiften.
Als je dat onder de knie hebt zal je zien dat code vaak korter en sneller kan.

[ Voor 23% gewijzigd door LED-Maniak op 17-08-2015 16:38 ]

[Sissors]

Let hierbij op dat bovenstaande voorbeeld goed gaat, maar:

code:

PORTD |= (0<<PD1 + 1<<PD0 + 0<< PD7 + 1<<PD4);

gaat fout.

Dit is omdat optellen een hogere prioriteit heeft als shiften (net als dat vermenigvuldigen voor optellen gaat), en shiften een hogere dan een bitwise OR.

Daarom zou ik zelf, ook al is bovenstaande dus correct, toch bij voorkeur altijd haakjes rond shifts zetten.

[RobV]

Sissors schreef op maandag 17 augustus 2015 @ 16:39:
Let hierbij op dat bovenstaande voorbeeld goed gaat, maar:

code:

PORTD |= (0<<PD1 + 1<<PD0 + 0<< PD7 + 1<<PD4);

gaat fout.

Dit is omdat optellen een hogere prioriteit heeft als shiften (net als dat vermenigvuldigen voor optellen gaat), en shiften een hogere dan een bitwise OR.

Daarom zou ik zelf, ook al is bovenstaande dus correct, toch bij voorkeur altijd haakjes rond shifts zetten.

Niet alleen dat. Een 0-bitje OR-en heeft ook niet veel zin.

[SnowDude]

RobV schreef op zondag 16 augustus 2015 @ 20:37:
[...]

Aanvulling: je kunt #defines voor meer dingen gebruiken van pin constanten, bijvoorbeeld voor macro's en multi-target code. Die varianten heb ik bewust buiten beschouwing gelaten.

Ik gebruik defines normaal gesproken alleen voor macro's en voor debug blokken. Voor een single waarde gebruik ik altijd const om de simpele reden dat die typed zijn

[RobV]

SnowDude schreef op donderdag 20 augustus 2015 @ 12:10:
[...]
Ik gebruik defines normaal gesproken alleen voor macro's en voor debug blokken. Voor een single waarde gebruik ik altijd const om de simpele reden dat die typed zijn

Een van de nadelen van een const is dat je ze niet extern kan definieren. Daarom dit lelijke truukje:

code:

const int numLeds = NUMLEDS_ARG;

en dan compiler args ..... -DNUMLEDS_ARGS=12

[sjimmie]

Bah...
Het blijkt dat de 3.3V aansluiting op mijn Mega2560 geen 3.3 maar 5V geeft.
Ik had daar een ESP8266 aan gekoppeld en die werd best warm. Na lang zoeken bleek het dus de hoge spanning te zijn. De ESP8266 geeft op alle verschillende baudrates alleen maar garbage dus ik vermoed dat ik die gesloopt heb met de te hoge spanning.

EDIT: (in het begin gaf de esp8266 nog een redelijke output, alleen eindigde die op "invalid" in plaats van "ready")

[ Voor 15% gewijzigd door sjimmie op 21-08-2015 22:32 ]

[BladeSlayer1000]

He bah! Dat is zeker balen. Waarschijnlijk kan je het wel oplossen door de spanning regelaar te vervangen.

Ook zeker balen dat de esp module nu ook stuk is. Toch zonde!

[sjimmie]

BladeSlayer1000 schreef op vrijdag 21 augustus 2015 @ 22:31:
He bah! Dat is zeker balen. Waarschijnlijk kan je het wel oplossen door de spanning regelaar te vervangen.

Ook zeker balen dat de esp module nu ook stuk is. Toch zonde!

Hmm, helaas is solderen op dat niveau niet (meer) aan mij besteed.
Ik heb op ebay al een 5 naar 3.3v regelaar in bestelling, naast nu ook een nieuwe esp8266. Dan maar de duurdere langere makkelijkere weg.

[Pizza_Boom]

Hmmm, waardeloos. Pin change interrupts op de Micro en Leonardo kan maar op een zeer beperkt aantal pinnen.

[RobV]

Meer dan op ern UNO:

https://www.arduino.cc/en/Reference/AttachInterrupt

[Pizza_Boom]

Afijn, vooralsnog verwacht ik niet dat ik het nodig ga hebben (kan straks wel mijn hele programma uit interrupts bouwen Niet de bedoeling). In de basis werkt de huidige constructie, maar tevreden ben ik nog niet.

Ik had verwacht dat dit:

C:

  if (digitalRead(KNOB) == HIGH)
    {
      if (LOOPDIRECTION == 1)
        LOOPDIRECTION = 0;
      else if (LOOPDIRECTION == 0)
        LOOPDIRECTION = 1;
      while (digitalRead(KNOB) == HIGH){}

op dezelfde manier zou werken als onderstaande. Onderstaande loopt echter een soort van vast. Als ik LOOPDIRECTION met een int op 1 stel, wisselt deze 1x de telrichting, als ik hem op 0 stel wisselt hij niet. Het lijkt dus erop dat hij hem niet meer terug naar 1 krijgt. LOOPDIRECTION is een gewone int, geen const int o.i.d.

C:

  KNOBSTATE = digitalRead(KNOB);
  if (KNOBSTATE == 1)
   {
    LOOPDIRECTION ^= LOOPDIRECTION;
   }
    while (digitalRead(KNOB) == 1){}

Verder werkt ie een seconde vertraagd, best irritant...

Bijbehorende code:

C:

  unsigned long NuMilli = millis();
  if (NuMilli - VorigeMilli > interval)
    {
      segment1 = (teller/10);    // Display 1 is meest rechts
      segment2 = (teller%10);    // Display 2 van rechts
      VorigeMilli = NuMilli;
      if (LOOPDIRECTION == 0)
      {
        if(teller == 0)
          teller = 100;
        teller--;
      }
      if (LOOPDIRECTION == 1)
      {
        if(teller == 100)
          teller = 0;
        teller++;
      }
    }

[ Voor 8% gewijzigd door Pizza_Boom op 22-08-2015 00:30 ]

[LED-Maniak]

Laat je hele code eens zien. Waar manipuleer je loopdirection?

[Pizza_Boom]

In het stukje boven het filmpje, staat strak boven elkaar in de loop:

C:

void loop() {

  int KNOBSTATE = 0;

  
  KNOBSTATE = digitalRead(KNOB);
 /* if (KNOBSTATE == 1)
   {
    LOOPDIRECTION ^= LOOPDIRECTION;
   }
    while (digitalRead(KNOB) == 1){}
   */
   
  if (digitalRead(KNOB) == HIGH)
    {
      if (LOOPDIRECTION == 1)
        LOOPDIRECTION = 0;
      else if (LOOPDIRECTION == 0)
        LOOPDIRECTION = 1;
      while (digitalRead(KNOB) == HIGH){}
    }
  
  unsigned long NuMilli = millis();
  if (NuMilli - VorigeMilli > interval)
    {
      segment1 = (teller/10);    // Display 1 is meest rechts
      segment2 = (teller%10);    // Display 2 van rechts
      VorigeMilli = NuMilli;
      if (LOOPDIRECTION == 0)
      {
        if(teller == 0)
          teller = 100;
        teller--;
      }
      if (LOOPDIRECTION == 1)
      {
        if(teller == 100)
          teller = 0;
        teller++;
      }
    }
  

}

[LED-Maniak]

Is logisch waarom het niet werkt hoor

code:

Bitwise XOR "^"
bit a   bit b   a ^ b (a XOR b)
0   0   0
0   1   1
1   0   1
1   1   0

Even kijken wat daar gebeurt:

code:

LOOPDIRECTION = 1;
LOOPDIRECTION ^= LOOPDIRECTION;
LOOPDIRECTION = LOOPDIRECTION ^ LOOPDIRECTION;
LOOPDIRECTION = 1 ^ 1;

Resultaat uit tabel: 1 en 1 = 0

Nu is LOOPDIRECTION = 0 door je vorige code
Kijken wat er nu gebeurt:

code:

LOOPDIRECTION = 0;
LOOPDIRECTION ^= LOOPDIRECTION;
LOOPDIRECTION = LOOPDIRECTION ^ LOOPDIRECTION;
LOOPDIRECTION = 0 ^ 0;

Resultaat uit tabel: 0 en 0 = 0

Aaiiii...


Probeer dit eens:

code:

LOOPDIRECTION = 1;
LOOPDIRECTION ^= 0x01;
LOOPDIRECTION = LOOPDIRECTION ^ 1;
LOOPDIRECTION = 1 ^ 1;

[b]Resultaat uit tabel: 1 en 1 = 0[/]

code:

LOOPDIRECTION = 0;
LOOPDIRECTION ^= 0x01;
LOOPDIRECTION = LOOPDIRECTION ^ 1;
LOOPDIRECTION = 0 ^ 1;

[b]Resultaat uit tabel: 0 en 1 = 1[/]

Tadaa
Het is allemaal logica. Als het niet werkt jezelf altijd afvragen wat er onderliggend gebeurt en waarom.

---

Het is overigens helemaal geen schande als je alles in interrupts krijgt geprikt hoor. Dat komt wel eens voor.
Op een gegeven moment moet je daar natuurlijk mee uitkijken en zal je als er veel code uitgevoerd moet worden door de interrupt een flag moeten laten zetten(ChangeDir = 1 bijvoorbeeld) die je loop() steeds controleert en zodra de flag is gezet, de code uitvoert.

Je milli's teller is trouwens prima geschikt voor een interrupt! Stel je voor dat hij met horten en stoten gaat tellen omdat er ondertussen nog een hoop andere dingen te doen zijn. Dat zou flauw zijn

---

Bij de grotere AVR's kan je een pin interrupt laten lopen op vrijwel álle pinnen. Wat je dan vaak wel moet doen is bij de interrupt kijken welke pin het was die een trigger heeft laten plaatsvinden.

[ Voor 31% gewijzigd door LED-Maniak op 22-08-2015 01:08 ]

[Pizza_Boom]

LED-Maniak schreef op zaterdag 22 augustus 2015 @ 00:59:

Tadaa
Het is allemaal logica. Als het niet werkt jezelf altijd afvragen wat er onderliggend gebeurt en waarom.

Het was eigenlijk meer dat ik een korte vervanger zocht voor de RA1 != RA1; statements die ik altijd gebruikte in PICkit om een waarde of een statement te inverteren.

Het is overigens helemaal geen schande als je alles in interrupts krijgt geprikt hoor. Dat komt wel eens voor.
Op een gegeven moment moet je daar natuurlijk mee uitkijken en zal je als er veel code uitgevoerd moet worden door de interrupt een flag moeten laten zetten(ChangeDir = 1 bijvoorbeeld) die je loop() steeds controleert en zodra de flag is gezet, de code uitvoert.

Zou an sich wel leuk zijn. Ik wil immers uiteindelijk data ophalen van een ander systeem, of ik dat ga doen door direct op deze Arduino een nRF24L01+ te hangen of door een extra Arduino in het I2C netwerk te hangen die dat gaat doen, moet ik nog even bedenken:

Je milli's teller is trouwens prima geschikt voor een interrupt! Stel je voor dat hij met horten en stoten gaat tellen omdat er ondertussen nog een hoop andere dingen te doen zijn. Dat zou flauw zijn

Mijn idee is dat het straks niet zo nauw meer hangt. Zoals ik hierboven zeg, er moet informatie van een extern systeem gehaald worden, temperatuurinformatie. Maar ik wil die afwisselen met een klok en daarvoor heb ik al een DS1307 + 32,125 kHz kristal liggen (ergens ). Moet ik eens mooi in elkaar solderen zodat dit gewoon bruikbaar is in breadboard (waarom ik nou weer zo'n los ICtje en kristalletje moest halen en niet gewoon een plug&play RTC printje van ebay gehaald heb, weet ik ook niet meer ) Dan zou deze timer alleen nog gebruikt worden voor het wisselen van weergave. Maar an sich, voor de leercurve een timer interrupt maken zou wellicht geen kwaad kunnen. Ik heb vernomen dat de delay functie op timer0 werkt, timer1 heb ik inmiddels in gebruik (alhoewel ik daarin nog prima een counter tot 400 bij kan zetten voor 1 seconde counting, draai nu op 400 Hz en dan de extra subroutine voor het tellen oproepen), timer2 en timer3 zijn dus nog vrij.

Bij de grotere AVR's kan je een pin interrupt laten lopen op vrijwel álle pinnen. Wat je dan vaak wel moet doen is bij de interrupt kijken welke pin het was die een trigger heeft laten plaatsvinden.

Hmm, ik vond via het Arduino Forum deze pagina en hier heeft men het over de SPI pinnen en 8, 9, 10 en 11. Op het forum werd in de post waarin deze link aangehaald werd, gezegd dat dit de enige pin interrupts zijn, na een vraag daarover.

Maar ondertussen heb ik ook dit en dat lijkt juist gewoon te kijken naar een onverwachte change of state op een bepaalde poort, om vervolgens daarop een interrupt te genereren waarna jij softwarematig mag gaan kijken welke pin van die poort nou eigenlijk die change of state had (of zeg ik dat nou verkeerd?).

Thnx voor je input iig, de code is verandert en nu loopt ie ook vrolijk door. Wellicht toch een idee de richtingverandering in een interrupt te zetten, drukte al een paar keer mis. Alleen nog uitvinden waarom die eerst door telt, maar dat zal wellicht ook te maken hebben met busy zijn van de processor op dat moment. Ik verwacht dat het met een interrupt sowieso getackled is.

[LED-Maniak]

Pizza_Boom schreef op zaterdag 22 augustus 2015 @ 01:23:
[...]
Mijn idee is dat het straks niet zo nauw meer hangt. Zoals ik hierboven zeg, er moet informatie van een extern systeem gehaald worden, temperatuurinformatie. Maar ik wil die afwisselen met een klok en daarvoor heb ik al een DS1307 + 32,125 kHz kristal liggen (ergens ). Moet ik eens mooi in elkaar solderen zodat dit gewoon bruikbaar is in breadboard (waarom ik nou weer zo'n los ICtje en kristalletje moest halen en niet gewoon een plug&play RTC printje van ebay gehaald heb, weet ik ook niet meer ) Dan zou deze timer alleen nog gebruikt worden voor het wisselen van weergave. Maar an sich, voor de leercurve een timer interrupt maken zou wellicht geen kwaad kunnen. Ik heb vernomen dat de delay functie op timer0 werkt, timer1 heb ik inmiddels in gebruik (alhoewel ik daarin nog prima een counter tot 400 bij kan zetten voor 1 seconde counting, draai nu op 400 Hz en dan de extra subroutine voor het tellen oproepen), timer2 en timer3 zijn dus nog vrij.

DS1307 kan ook elke seconde een interrupt genereren zodat de arduino/AVR weet dat er een seconde is verstreken. Anders ben je constant bij de RTC aan het opvragen wat de tijd is.. Werkt ook, maar is niet zo sexy .

[...]
Hmm, ik vond via het Arduino Forum deze pagina en hier heeft men het over de SPI pinnen en 8, 9, 10 en 11. Op het forum werd in de post waarin deze link aangehaald werd, gezegd dat dit de enige pin interrupts zijn, na een vraag daarover.

Maar ondertussen heb ik ook dit en dat lijkt juist gewoon te kijken naar een onverwachte change of state op een bepaalde poort, om vervolgens daarop een interrupt te genereren waarna jij softwarematig mag gaan kijken welke pin van die poort nou eigenlijk die change of state had (of zeg ik dat nou verkeerd?).

Correct! Veel pinnen kunnen dat gewoon. Ja het heeft limitaties vergeleken een INT0 maar is prima voor zulke simpele dingen

Thnx voor je input iig, de code is verandert en nu loopt ie ook vrolijk door. Wellicht toch een idee de richtingverandering in een interrupt te zetten, drukte al een paar keer mis. Alleen nog uitvinden waarom die eerst door telt, maar dat zal wellicht ook te maken hebben met busy zijn van de processor op dat moment. Ik verwacht dat het met een interrupt sowieso getackled is.

Er zal wel een of andere functie zijn die ergens teveel tijd opneemt. Geen idee of er achter digitalRead veel code hangt voordat hij zegt dat een pin hoog is.

Mooi dat het werkt in ieder geval!

[Pizza_Boom]

LED-Maniak schreef op zaterdag 22 augustus 2015 @ 01:30:
DS1307 kan ook elke seconde een interrupt genereren zodat de arduino/AVR weet dat er een seconde is verstreken. Anders ben je constant bij de RTC aan het opvragen wat de tijd is.. Werkt ook, maar is niet zo sexy .

Zo ver wilde ik niet eens gaan. Ik heb een 4 digits groot display in gedachte, het liefste eentje met puntjes onder (komma getallen), puntjes tussen digit 2 en 3 (voor de klok) en puntje tussen 3 en 4 (voor temperatuur). zoiets dus, alleen nu nog eens kijken waar ze dat voor een schappelijk prijsje verkopen. Maar ik zou dus niet eens iedere seconde hoeven opvragen of een interrupt hoeven hebben, 1x per minuut zou al voldoende zijn.

Correct! Veel pinnen kunnen dat gewoon. Ja het heeft limitaties vergeleken een INT0 maar is prima voor zulke simpele dingen

Alleen even uitvogelen hoe het precies werkt en te implementeren is. Zou mooi zijn als ik dat ook op mijn analoge poorten krijg, ik heb er 6 en heb er 4 in gedachte als schakelpin voor de torren van het multiplexen, dus wellicht de interrupt van de RTC en de interrupt van de button erop (als ik die dan nog laat bestaan), meer zou ik dan niet nodig hebben. Kan je op 1 poort de interrupt laten genereren en daarna kijken welke pin het was. Alleen jammer dat ik dan de interrupt van de nRF (die ik overigens nog niet werkend heb gekregen) dan weer ergens anders op zou moeten zetten, of de button opofferen, hoe vaak gebruik je dat nou.

Er zal wel een of andere functie zijn die ergens teveel tijd opneemt. Geen idee of er achter digitalRead veel code hangt voordat hij zegt dat een pin hoog is.

Mooi dat het werkt in ieder geval!

Zal vast wel wat achter hangen, digitalWrite kost ook al 8 cycles, t.o.v. 1 of 2 met de huidige methode waar je over vertelde. Scheelt ook wel fors natuurlijk als je met 8 pinnen bezig bent.

[RobV]

Pizza_Boom schreef op zaterdag 22 augustus 2015 @ 02:16:
[...]
[...] Ik heb een 4 digits groot display in gedachte, het liefste eentje met puntjes onder (komma getallen), puntjes tussen digit 2 en 3 (voor de klok) en puntje tussen 3 en 4 (voor temperatuur). zoiets dus, alleen nu nog eens kijken waar ze dat voor een schappelijk prijsje verkopen.

Voor mijn klokproject wat ik in 2014 gedaan heb, heb ik datzelfde displaytje gebruikt (met de extra dots). Na veel verschillende sources geprobeerd te hebben, heb ik er uiteindelijk voor gekozen gewoon bij Sparkfun te halen wat ik nodig had.

Ik heb er overigens nog een stuk of 15 liggen hier (over) voornamelijk groen.

[Pizza_Boom]

Hmmm, in de eerder aangehaalde link van Geert's pages wordt geschreven dat de ATMega die hij gebruikt op iedere poort een PCINT heeft, echter heeft de Arduino Micro, of liever gezegd, de ATMega 32U4, er maar 8, waarvan er 3 zijn verwerkt in de ISP/SPI pinnen en 4 zitten onder pinnen zitten waar ik nu mijn 7 segment mee aanstuur. Zal ik dus wat moeten omdraden vrees ik. Of ik moet hem op de Slave Select pin zetten, daar zit PCINT 0 op, 4-7 zitten op 8, 9, 10 en 11 (PB4 - 7). Lijkt er dus op dat alleen PortB een pin change interrupt kent. Nou moest ik al gaan schuiven als ik de I2C wil gaan gebruiken, maar nu wordt het iets intensiever.

Slave select kan ik naar mijn idee gewoon gebruiken voor een pin change interrupt, want die gebruik je, volgens mij, alleen als je Arduino voor SPI slave speelt. Dat doet ie niet, de nRF is immers het slave device.

Nog een vraag: ik doe nu in ieder stapje waar ik een poort oproep, een pin noemen. PORTB |= (1<<PB5). Ik verwacht van niet omdat je direct op de pin zit, maar is het mogelijk om deze PB5 middels een declaratie een andere naam te geven? Waar ik nu tegenaan loop is dat ik, omdat ik meerdere pinnen zou moeten gaan veranderen, ik minstens 10 routines door moet om overal de pin te veranderen.

Verder: Kan ik de RX/TX lijnen ook als gewone I/O lijnen gebruiken? Als ik de pin layout van de Leonardo bekijk, zie ik dat ze daar gewoon als pin 0 en 1 genoemd zijn. Bij mij zitten ze op de juiste plaats, er zit een groundpin tussen, maar terugtellend zou je op 1 en 0 uitkomen.

Grappig detail trouwens, de Micro lijkt meer bruikbare pinnen te hebben dan de Leonardo. Sowieso is de Micro voorzien van dubbele SPI, zowel op zijn ISP als op de normale headers, waar de Leonardo deze heeft niet en alleen via ISP zijn SPI kwijt kan.

EDIT: Ik weet trouwens ook hoe het kan dat hij doortelt na het wijzigen van telrichting: het getal verander ik direct nadat ik hiermee segment 1 en 2 bepaald heb. Als ik het telgetal zou printen met een serial print, dan zou die permanent, op 3 cycles per 1000 milli's na, 1 hoger/lager zijn dan het getal zoals weergegeven op het 7 segment. Ligt dus puur aan de keuzes m.b.t. de volgorde van het programma zoals ik die gemaakt heb.

[ Voor 10% gewijzigd door Pizza_Boom op 23-08-2015 00:40 ]

[mcDavid]

Als je geen SPI gebruikt kun je die pinnen prima voor iets anders gebruiken. Het zelfde geldt voor pin 0 en 1 voor seriële communicatie. Daarbij heb je met de 32u4 nog het voordeel dat communicatie met de computer via de ingebouwde USB interface loopt en niet via de seriële poort op pin 0 en 1.

En dat de pro micro meer pinnen uitgebracht heeft is ook niet zo gek, zonder die domme arduino-formfactor is er gewoon veel meer mogelijk wat dat betreft.

[Pizza_Boom]

Ik dacht dat de USB verbinding ook gebruik maakte van de TX/RX, omdat die LED's altijd gezellig meeknipperen bij programmeren. SPI is nog niet besloten, dat kan verplaatst worden naar een andere chip die dan de info via I2C doorstuurt (I2C wil ik toch al gebruiken voor een RTC, dus dat zou efficiënt zijn), maar het kan ook zijn dat ik de nRFjes direct op deze Arduino hang.

Qua aantal I/O's die je op de pinnen kan zetten zit er geen verschil tussen de Leonardo en de Micro. Beide zitten aan het maximale aantal poorten. Okee, niet alles als I/O pin in gebruik (TX LED bijvoorbeeld), maar de limiet is aardig bereikt. 34 pinnen, 2 niet aangesloten, terwijl de 32U4 totaal 44 pinnen heeft. Zit al 5x ground bij, waar ik er 2 heb op de Micro. Kristalpinnen, HWB, 2 USB pinnen, etc).

mcDavid schreef op zondag 23 augustus 2015 @ 00:57:
En dat de pro micro meer pinnen uitgebracht heeft is ook niet zo gek, zonder die domme arduino-formfactor is er gewoon veel meer mogelijk wat dat betreft.

Geen pro Micro, gewoon een Micro. Officieel Arduino boardje:

[ Voor 11% gewijzigd door Pizza_Boom op 23-08-2015 01:14 ]

[RobV]

Waarom heb je zoveel interrupts nodig als ik vragen mag?

[Pizza_Boom]

Ik heb er niet veel nodig (2 tot nu toe, 1x timer en 1x pin change), maar ik heb er ook maar weinig en op die pinnen zit al een andere functie.

[ Voor 17% gewijzigd door Pizza_Boom op 23-08-2015 11:23 ]

[RobV]

Pizza_Boom schreef op zondag 23 augustus 2015 @ 11:22:
Ik heb er niet veel nodig (2 tot nu toe, 1x timer en 1x pin change), maar ik heb er ook maar weinig en op die pinnen zit al een andere functie.

Dus je hebt eigenlijk geen probleem..

[Pizza_Boom]

RobV schreef op zondag 23 augustus 2015 @ 11:58:
[...]

Dus je hebt eigenlijk geen probleem..

Echt een probleem wilde ik het niet noemen, ik zat alleen met een aantal vragen. O.a. over het gebruik van bijv. de TX/RX pinnen als I/O.

[Verwijderd]

RobV schreef op zondag 23 augustus 2015 @ 11:58:
[...]

Dus je hebt eigenlijk geen probleem..

[RobV]

Pizza_Boom schreef op zondag 23 augustus 2015 @ 12:01:
[...]
Echt een probleem wilde ik het niet noemen, ik zat alleen met een aantal vragen. O.a. over het gebruik van bijv. de TX/RX pinnen als I/O.

Sorry, een beetje flauw van mij. Je hoeft niet altijd een probleem te hebben om op een forum te babbelen, vind ik (op sommige andere fora wordt daar heel anders over gedacht). Ik ben juist blij dat je dingen aan het uitzoeken bent.

[Pizza_Boom]

Ik hoop alleen dat er nog iemand is die antwoord kan geven op mijn vraag of ik voor de poortnaam ook gewoon een eigen hulpvariabele kan maken? Ik gok van niet, maar zeker weten doe ik dat niet en ik krijg er verder geen duidelijkheid over.

En ach, een lolletje. Gezellig keuvelen over dit soort dingen hoort imho juist thuis in zo'n topic, dat maakt het zo waardevol. Zorgt voor een stukje "bonding" tussen users, lekker weten waar ieder mee bezig is.

[ Voor 31% gewijzigd door Pizza_Boom op 23-08-2015 19:00 ]

[LED-Maniak]

Hoe bedoel je dat? Wat wil je bereiken?

[Pizza_Boom]

Ik moet pinnen gaan omzetten, want de SPI lijnen verwacht ik vooralsnog nodig te hebben en alle andere lijnen met een pin change interrrupt hebben nu een andere functie. Aangezien ik al een aantal situaties heb, moet ik dus in ieder van de 11 huidige situaties de pin veranderen. Als ik dat tot 1 variabele kan zetten die ik in het begin declareer, blijft de rest gewoon lekker makkelijk gelijk en is dat makkelijker met veranderen.

[ Voor 15% gewijzigd door Pizza_Boom op 23-08-2015 19:44 ]

[LED-Maniak]

Ah dat kan gewoon hoor.

Dat doe je met #define

#define Button_Port PORTB
#define Button_Pin PB1

Button_Port |= (1<<Button_Pin);

http://www.starlino.com/port_macro.html

code:

// MACROS FOR EASY PIN HANDLING FOR ATMEL GCC-AVR
//these macros are used indirectly by other macros , mainly for string concatination
#define _SET(type,name,bit)          type ## name  |= _BV(bit)    
#define _CLEAR(type,name,bit)        type ## name  &= ~ _BV(bit)        
#define _TOGGLE(type,name,bit)       type ## name  ^= _BV(bit)    
#define _GET(type,name,bit)          ((type ## name >> bit) &  1)
#define _PUT(type,name,bit,value)    type ## name = ( type ## name & ( ~ _BV(bit)) ) | ( ( 1 & (unsigned char)value ) << bit )

//these macros are used by end user
#define OUTPUT(pin)         _SET(DDR,pin)    
#define INPUT(pin)          _CLEAR(DDR,pin)    
#define HIGH(pin)           _SET(PORT,pin)
#define LOW(pin)            _CLEAR(PORT,pin)    
#define TOGGLE(pin)         _TOGGLE(PORT,pin)    
#define READ(pin)           _GET(PIN,pin)

/*
    BASIC STAMPS STYLE COMMANDS FOR ATMEL GCC-AVR

    Usage Example:
    
    #define pinLed B,5  //define pins like this

    OUTPUT(pinLed);       //type fixed
    //OUTPUT(pinLED);     //compiles as DDRB |= (1<<5);
    HIGH(pinLed);         //compiles as PORTB |= (1<<5);
    
*/

Hele macro om dit voor elkaar te krijgen

[ Voor 91% gewijzigd door LED-Maniak op 23-08-2015 20:04 ]

[jctjepkema]

Folks! Ik zit hier met een GRBL probleempje. Ik krijg het keurig geflashed op mijn arduino nano v3.0, Ik gebruik GRBLController om te communiceren met de arduino, maar ik krijg maar error's.

Ik heb zon chinese laser engraver aangeschaft, niet eentje die op cd lades draait, maar een met wel nema 17 type motoren. Opzich prima ding, hier en daar wat kleine chinese probleempjes maar dat los ik wel op. Maar ik wil dat ding op GRBL aan de praat krijgen en dat lukt me niet. Ik krijg telkens de Error Undefined Feed rate als ik op een handmatige knop druk in GRBL Controller, en ik krijg een alarm lock van de arduino als ik hem volgens een g-code script wil laten draaien. Haal ik het alarm lock er af met $X dan loopt hij gewoon vast en kan ik pas weer verder tot dat ik op reset druk op de arduino.

Wanneer ik zelf een scriptje draai om de motoren te laten draaien, doet hij het prima en draaien de motoren wel. Maar ik wil hem juist via G-Code laten draaien.

Dit zijn de instellingen:


Verder ik heb geen limit switches, dus dan zou ik software limit switches moeten gebruiken neem ik aan? En hebben jullie een alternatief voor grbl die wel G-Code aanneemt? Of weten jullie mijn fout?

ALVAST BEDANKT

[mcDavid]

Pizza_Boom schreef op zondag 23 augustus 2015 @ 01:10:
Ik dacht dat de USB verbinding ook gebruik maakte van de TX/RX, omdat die LED's altijd gezellig meeknipperen bij programmeren.

Ik zeg het even uit mijn hoofd maar volgens mij staat vrij duidelijk in de docu dat de tx/rx leds aan de usb-interface gekoppeld zijn. Dat de usb-interface geen gebruik maakt van de hardware-serial poort op pin 0 en 1 weet ik iig heel zeker.

[...]

Geen pro Micro, gewoon een Micro. Officieel Arduino boardje:
[afbeelding]

Oh leuk, die is er dus ook inmiddels. Is die van arduino.cc of van arduino.org?

[RobV]

Micro heeft Rx/Tx gekoppeld aan de USB Serial (in Arduino 'Serial'). Voor de Rx/Tx op het board wordt 'Serial1 gebruikt'.

[Pizza_Boom]

mcDavid schreef op zondag 23 augustus 2015 @ 21:48:
[...]

Ik zeg het even uit mijn hoofd maar volgens mij staat vrij duidelijk in de docu dat de tx/rx leds aan de usb-interface gekoppeld zijn. Dat de usb-interface geen gebruik maakt van de hardware-serial poort op pin 0 en 1 weet ik iig heel zeker.

RobV schreef op zondag 23 augustus 2015 @ 21:52:
Micro heeft Rx/Tx gekoppeld aan de USB Serial (in Arduino 'Serial'). Voor de Rx/Tx op het board wordt 'Serial1 gebruikt'.

Dus ik kan die pinnen gewoon gebruiken als I/O pin? Dat zou wel handig zijn, kan ik de twee draden van de I2C pinnen daarnaartoe gooien. Even als conclusie dus. Documentatie ben ik nog zoekende.

Oh leuk, die is er dus ook inmiddels. Is die van arduino.cc of van arduino.org?

Mijne is van Arduino.org volgens het doosje, maar Arduino.cc heeft hem ook (en verkoopt hem buiten de USA als Genuino Micro ) En de andere is een kloon en daarvan is er nog eentje onderweg.

[RobV]

Niet als je de hardware i2c gebruiken wilt. En dus alle arduino libs die Wire.h gebruiken.

[LED-Maniak]

Dan zal je de voorbeelden uit de atmel datasheets of de standaard open source code moeten gebruiken in plaats van arduino libraries waarmee je die LED's uitschakelt.

Dan heb je de pinnen erbij.

Nog weer zo'n goede reden

[Pizza_Boom]

Een losse I2C lib zal er toch vast wel ergens zijn? En anders zelf schrijven. Heb een EEPROM die ik al eerder als slave heb gebruikt om mijn eigen I2C programma te schrijven voor een PIC die ik nu natuurlijk weer kan gebruiken, alhoewel een bestaande lib natuurlijk makkelijker is.

Reden dat ik zo door vraag is omdat bij alle andere Arduino's staat dat het niet mag en ik geen zin heb in weer een gebrickt geval. Okee, logischerwijs verwacht ik dat het bij deze wel kan, simpelweg omdat de onboard serial niet gebruikt wordt voor een FTL232 chip, maar toch. Better safe than sorry.

[LED-Maniak]

Ik heb nog nooit een I2C lib zelf geschreven. Er zijn voldoende alternatieven.
Beetje googlen en je hebt er een.

Arduino heeft zo zijn eigenaardigheden. Als het gewone pinnen zijn kan je het prima aansturen als de rest van je programma zich er maar geen ongewenst eigendom van maakt.

Bricken zal niet snel gebeuren als je dadelijk die SPI programmer hebt. Dan kan je alles(met uitzondering van een verkeerd ingestelde klok source) herstellen.

[Pizza_Boom]

Hoe bedoel je gewone pinnen? Ze zouden dan in de routine die door de interrupt wordt aangeroepen voor de 7 segment displays komen te zitten, zodat ik 2 en 3 als I2C kan gebruiken.

Trouwens met de andere kloon die eraan komt even opletten, bij de kloon die ik nu heb zijn pin 2 en 3 niet helemaal lekker bruikbaar. Bij weerstand meten meet ik 0,6 ohm weerstand tussen 2 en 3, bij alle andere pinnen krijg ik geen weerstand te zien (dus oneindig) en ook bij programmeren viel het me al een op dat pin2 en 3 samen oplichten en weer doven. Zou dat een hardwarefoutje zijn of kan dat ook nog ergens software/firmwarematig zijn? Verkeerde fuses gezet ofzo?

[ Voor 14% gewijzigd door Pizza_Boom op 24-08-2015 01:00 ]

[LED-Maniak]

Gewone pinnen als in de zin van dat het geen kristal, usb of andere speciale pinnen zijn. Als op de pinout van de datasheet staat dat het ook een normale pinfunctie kan hebben dan kan je die gebruiken.

Zo'n lage weerstand doet mij denken aan een bruggetje ergens. Foutje in de koper traces of soldeerbruggetje. Zie je wel meer uit china.

[Pizza_Boom]

De 32U4 heeft echt een aparte D+ en D- en een RXD1 en TXD1.



Jammer, weinig aan te doen dus, behalve de baantjes doorhalen en met 2 draadjes naar de pinnen een nieuwe verbinding leggen. Pokkewerk dus. Hopen dat de volgende kloon het niet heeft en deze dan maar niet voor I2C gebruiken.

edit:
Alhoewel... Ik denk dat hier het probleem zit, dit valt me net op, met de pinout van de 32U4 klopt het in ieder geval:

Ik ga de drukknop naar een interrupt brengen. Heb de volgorde van telrichting kiezen en segment bepalen omgedraaid en druk nu te vaak mis, dat ie dus bezig is. Irritant...

[ Voor 31% gewijzigd door Pizza_Boom op 24-08-2015 02:30 ]

[RobV]

Het klinkt mij alsof je erg moeilijk aan het doen bent, sorry maar zo komt het bij mij over.

[LED-Maniak]

Die pinnen lijken mij gewoon beschikbaar voor andere dingen.

Foto ziet er inderdaad uit als kortsluiting
Dat is dus PD0 en PD1 die contact maken. Ik zou zeggen: doe er wat flux op, verhit het en zuig het weg met litze of een pompje.

RobV schreef op maandag 24 augustus 2015 @ 09:49:
Het klinkt mij alsof je erg moeilijk aan het doen bent, sorry maar zo komt het bij mij over.

Omdat hij interrupts gebruikt?

[ Voor 66% gewijzigd door LED-Maniak op 24-08-2015 09:52 ]

[RobV]

LED-Maniak schreef op maandag 24 augustus 2015 @ 09:50:
Die pinnen lijken mij gewoon beschikbaar voor andere dingen.

Foto ziet er inderdaad uit als kortsluiting


[...]

Omdat hij interrupts gebruikt?

Een 4-digit 7-segment aansluiten op een Arduino met een button en een interrupt pin is nou niet echt rocket science.. Daarvoor hoeft je echt niet je i2c bus naar andere pinnetjes te verhuizen volgens mij.

EDIT: Ik lees nu over de defecte pinnen 2 en 3.. Tja, als je board sluiting maakt wordt het lastig zoeken natuurlijk, mijn excuses.

[ Voor 13% gewijzigd door RobV op 24-08-2015 09:54 ]