PWM met frequentieregeling met Arduino t.b.v. besturing analoge DC-treinbaan

[Timo]

Hoi Joop,

Ik ga even over de code zoals ik het tegen kom. Lijkt misschien gezeur om het zo te lezen maar zo bedoel ik het niet! Probeer je tot een goed programma te laten komen

Code: [Selecteer]

typedef struct pwmPins {
  int pin;
  unsigned long cyclus;
  unsigned long startCyclus;
  unsigned long toggle;
} pwmPin;
byte is groot genoeg voor een pin nummer. De pinState kun je ook gewoon uitlezen. Daarnaast zet je de initiële waarde van de pinState op HIGH terwijl de pin initiëel laag is.

Ook mag het in C++ direct:

Code: [Selecteer]

struct pwmPin_t{
  int pin;
  unsigned long cyclus;
  unsigned long startCyclus;
  unsigned long toggle;
  bool pinState;
};

pwmPin_t pwmObjects[] = {
  {3}, {5}
};
const byte NrPwmObjects = sizeof(pwmObjects)/sizeof(pwmObjects[0]);
//ik gebruik vaak de macro
//#define numberOf(x) (sizeof(x)/sizeof(x[0]))
//dan kan je schrijven
//const byte NrPwmObjects = numberOf(pwmObjects);
En eigenlijk ben je met die struct en de setPWM functie al goed op weg om het een object te maken

Code: [Selecteer]

const byte pinMotor1    = 4;
const byte pinMotor2    = 5;
Zou ook een uitgelezen plek zijn voor een array

Code: [Selecteer]

unsigned long currentMicros  = micros();Doet niets, je kunt pas een functie aanroepen in een functie.

Code: [Selecteer]

const byte pinPotmeter  = 3;Als je A3 gebruikt ipv 3 kan je nooit voor gekke verrassingen komen te staan. Want er zijn een aantal Arduino's waar analogRead(3) en analogRead(A3) niet hetzelfde doen.

pwm1 is nooit gebruikt en potmeter als global is niet zo zinvol.

Code: [Selecteer]

if (speed < 0) {digitalWrite(pinMotor1, LOW);} else {digitalWrite(pinMotor1, HIGH);}Probeer dingen niet op één regel te proppen. Regels (en spaties) zijn gratis (maar overdrijf het ook niet).

Code: [Selecteer]

if (speed < 0) {
    digitalWrite(pinMotor1, LOW);
  }
  else {
    digitalWrite(pinMotor1, HIGH);
  }En moet je pinMotor2 ook niet aan passen? Of welke H-brug gebruik je eigenlijk?

Code: [Selecteer]

getPotmeterSetting()Het is ook niet erg logisch dat deze functie de richting zet. Zou je namelijk niet verwachten aan de naam

Dan meer naar de werking:

Code: [Selecteer]

unsigned int freq = snelheid + 30;Okay, frequentie tussen 30 en 130 dus.

Code: [Selecteer]

pwmObjects[index].cyclus = 1.00 / freq * 1000000;De float cast maakt het wel wat lastig maar zorgt denk ik voor de correcte afronding. Maar is hetzelfde als

Code: [Selecteer]

pwmObjects[index].cyclus = (1000000 + (freq / 2) ) / freq;Maar in ieder geval de duur van een periode in us.

Code: [Selecteer]

pwmObjects[index].toggle=pwmObjects[index].cyclus*snelheid/100;Hoeveel daar van aan.

Duurde even voor ik dat door had. period en onPeriode ofzo zou het duidelijker hebben gemaakt.

Ik zou het daarna overigens niet eens meer in 500us intervallen hakken maar gewoon checken. Zou eerder het aantal analogReads() beperken. Zeker omdat 500us nu best een grove afronding geeft. Zie deze grafieken wat voor variatie je nu hebt.

Ik zou het dus allemaal iets directer doen

Hopelijk is het niet te veel commentaar


Timo

[jmu]

Dag Timo,

Bedankt voor je correcties. De source was idd nog niet op orde en was hier en daar snel bij elkaar gekopieerd. Maar goede tips zijn altijd welkom, daar hoef je je niet voor te excuseren!
Kost het uitlezen van de pinState meer processor stappen? Dat is de reden dat ik vaak uitwijk naar een var.

Jouw berekening pwmObjects[index].cyclus = (1000000 + (freq / 2) ) / freq; levert een andere uitkomst. Het scheelt weliswaar niet veel (een half), maar waarom zou je het op die wijze doen?

Op jouw grafiek moet ik nog even studeren en het finetunen moet nog gebeuren. Ik heb iig al de freq berekening aangepast, omdat naar mijn zijn de freq te snel steeg. De formule is nu freq = 0.3 * snelheid + 30;

Joop

[jmu]

Ik heb nog geprobeerd om een software oscilloscoop aan de praat te krijgen, maar dat loopt op een teleurstelling uit. Zelfs al zet ik een toongenerator op de ingang, dan nog is het signaal niet bruikbaar. Helaas lukt het me niet om zo de blokgolf te kunnen onderzoeken. Als iemand nog een tip heeft houd ik me aanbevolen.

Joop

[Timo]

Maar goede tips zijn altijd welkom, daar hoef je je niet voor te excuseren!

Gelukkig! Het was namelijk nogal een rommelig zooitje tips geworden

Kost het uitlezen van de pinState meer processor stappen? Dat is de reden dat ik vaak uitwijk naar een var.

Iets, maar als je ook digitalWrite() gebruikt is het verwaarloosbaar.

Jouw berekening pwmObjects[index].cyclus = (1000000 + (freq / 2) ) / freq; levert een andere uitkomst. Het scheelt weliswaar niet veel (een half), maar waarom zou je het op die wijze doen?

Zou kunnen dat jouw berekening juist niet correct afrondde (altijd naar beneden). Dat is precies wat ik hier fix met "+ (freq / 2) )". Voorbeeldje, met integer math 10 / 4 = 2. Terwijl als we het normaal doen is het 2,5 wat afgerond 3 geeft. Als je de teller verhoogd met de helft van de noemer zal integer math ook correct afronden. In het voorbeeld, (10 + (4/2) ) / 4 = (10 + 2) / 4 = 12 / 4 = 3. Correct afgerond 

Waarom je liever bij integer math blijft? De standaard, 8-bit, Arduino's hebben geen hardware voor floating point math. De compiler weet dit en werkt er om heen door het op te breken in een berg integer math. Maar dat is dus altijd een stuk trager dan het te doen in integer math. Dat is ook waarom je op 8-bit microcontroller (of meer algemeen, microcontroller zonder floating point hardware) liever gewoon de decimaal weg haalt. Dus als je euros wilt met centen achter de komma sla je hetgewoon op als centen. Wil je graden Celsius met één decimaal sla je het op als deci-graden Celsius. Dit punt zet je er zo weer in als je het wilt printen.

Op jouw grafiek moet ik nog even studeren en het finetunen moet nog gebeuren. Ik heb iig al de freq berekening aangepast, omdat naar mijn zijn de freq te snel steeg. De formule is nu freq = 0.3 * snelheid + 30;

Maar met die formule loopt je frequentie tussen de 30Hz en 60Hz... Dat is wel een heeeeeeel verschil met eerst. En weer, in integer math is het een stuk sneller. Okay, snelheid / 3 + 30 is niet helemaal hetzelfde maar wel een stuk sneller. Voorbeeldje:

Code: [Selecteer]

volatile byte in = 10;
volatile byte out;
unsigned long tic, toc;

void setup(){
  Serial.begin(115200);

  Serial.println(F("---Float---"));
  tic = micros();
  for(in = 0; in <= 100; in++){
    out = 0.3 * in + 30;
  }
  toc = micros();
  Serial.print(F("Waarde: "));
  Serial.println(out);
  Serial.print(F("tijd: "));
  Serial.println(toc - tic);
 
  Serial.println(F("---Int---"));
  tic = micros();
  for(in = 0; in <= 100; in++){
    out = in / 3 + 30;
  }
  toc = micros();
  Serial.print(F("Waarde: "));
  Serial.println(out);
  Serial.print(F("tijd: "));
  Serial.println(toc - tic);
}

void loop(){
}Uitkomst:

---Float---
Waarde: 60
tijd: 2472
---Int---
Waarde: 63
tijd: 152

Goed, daar zie je al het verschil in uitkomst maar ook het enorme verschil in tijd. Namelijk 16 keer zo snel.

Zelf ooit wel een software oscilloscoop gebruikt maar niet veel en dat is lang geleden. Staat al een aardig tijdje een HP scope op me bureau Maar voor de geluidskaart oscilloscoop zal het nooit lukken om een blokgolf echt netjes weer te geven, zeker met die lage frequenties. Dat komt door de ontkoppel condensator in de geluidskaart waardoor je het altijd AC koppelt. Was ik even vergeten toen ik het noemde. Als je een goedkope USB geluidskaart gebruikt is deze condensator wel weg te halen. Maar voor blokgolven is de logic analyzergoedkope logic analyzer makkelijker.


Timo