Geautomatiseerd testen op de Arduino
7 berichten
• Pagina 1 van 1
- nicoverduin
- Berichten: 5043
- Geregistreerd: 13 Mei 2013, 20:57
- Woonplaats: Heemskerk
Geautomatiseerd testen op de Arduino
Ik ben de laatste week druk doende geweest om een Geautomatiseerde manier van testen op de Arduino te ontwikkelen.
Testcases worden ingebracht in Excel (speciale sheet met VBA macro). Die genereert een aantal bestanden die automatisch bij de sketch worden toegevoegd tijdens compilatie. Hiervoor is slechts een statement nodig "#include <AutoTest.h>". De gegenereerde bestanden hoeven alleen maar in dezelfde folder te staan als de sketch zelf.
Het voordeel is dat de normale digitalRead en digitalWrite (Analog read komt nog) omgeleid worden en de library gaan aanroepen. Programma technisch zaten hier wel een paar leuke uitdagingen in. Er zijn ook nadelen of onmogelijkheden ('t is maar hoeje het bekijkt). Als tijd kritisch is dan heeft dit geen zin. Er wordt veel geladen uit Flash Geheugen (alle testsets worden daarin opgeslagen), er wordt gebruik gemaakt van Serial. Allemaal vertragende factoren. Daarnaast worden alleen de reads en writes omgeleid in die stukken code waar het include statement zit. Dus doe je niets aan een library (dus alleen gewoon gebruiken) dan blijven die R/W's gewoon werken op de pinnen.
Het geheel is nog experimenteel (hoewel het al werkt ). Hopelijk eind volgende week helemaal gereed om over te zetten naar Github en Arduino Playground.
De uitvoer is via de Serial in CSV formaat zodat je het in bijvoorbeeld Excel weer mooi kan bewerken.
Het mooie van dit alles is dat je de sketch verder niet hoeft aan te passen. Alleen de include en de rest gaat vanzelf.
Zie: http://www.verelec.nl/?page_id=177
Testcases worden ingebracht in Excel (speciale sheet met VBA macro). Die genereert een aantal bestanden die automatisch bij de sketch worden toegevoegd tijdens compilatie. Hiervoor is slechts een statement nodig "#include <AutoTest.h>". De gegenereerde bestanden hoeven alleen maar in dezelfde folder te staan als de sketch zelf.
Het voordeel is dat de normale digitalRead en digitalWrite (Analog read komt nog) omgeleid worden en de library gaan aanroepen. Programma technisch zaten hier wel een paar leuke uitdagingen in. Er zijn ook nadelen of onmogelijkheden ('t is maar hoeje het bekijkt). Als tijd kritisch is dan heeft dit geen zin. Er wordt veel geladen uit Flash Geheugen (alle testsets worden daarin opgeslagen), er wordt gebruik gemaakt van Serial. Allemaal vertragende factoren. Daarnaast worden alleen de reads en writes omgeleid in die stukken code waar het include statement zit. Dus doe je niets aan een library (dus alleen gewoon gebruiken) dan blijven die R/W's gewoon werken op de pinnen.
Het geheel is nog experimenteel (hoewel het al werkt ). Hopelijk eind volgende week helemaal gereed om over te zetten naar Github en Arduino Playground.
De uitvoer is via de Serial in CSV formaat zodat je het in bijvoorbeeld Excel weer mooi kan bewerken.
Het mooie van dit alles is dat je de sketch verder niet hoeft aan te passen. Alleen de include en de rest gaat vanzelf.
Zie: http://www.verelec.nl/?page_id=177
Advertisement
Re: Geautomatiseerd testen op de Arduino
Hoi Nico,
Volgens mij ben je wereldkampioen "out-of-the-box" denken. Mij is echter niet geheel duidelijk wanneer je 'constructie' zijn voordelen laat zien. Is dit bij het testen van de hardware, de software, of gaat het juist om het snel testen van verschillende combinaties van deze twee?
Volgens mij ben je wereldkampioen "out-of-the-box" denken. Mij is echter niet geheel duidelijk wanneer je 'constructie' zijn voordelen laat zien. Is dit bij het testen van de hardware, de software, of gaat het juist om het snel testen van verschillende combinaties van deze twee?
- nicoverduin
- Berichten: 5043
- Geregistreerd: 13 Mei 2013, 20:57
- Woonplaats: Heemskerk
Re: Geautomatiseerd testen op de Arduino
Om je een voorbeeld te geven:
Ik heb laatst een project gedaan voor een klant waarbij er een soort muziek speler op zat. Als de PLAY wordt ingedrukt, dan moet het volume gedurende x seconden oplopen en dan draaien voor y seconden. z seconden voor het eind moet het volume weer afbouwen en weer een beetje oplopen. Als PLAY voor de 2e x wordt ingedrukt dan moet hij gelijk uitschakelen. Als er een reset van buiten afkomt, moet hij gelijk uitschakelen maar wel het volume afbouwen (2 sec) en wer opbouwen. Als FF wordt ingedrukt en hij loopt nog niet dan moet eerst PLAY worden opgestart en daarna FF ingeschakeled zoalng hij is ingedrukt enz.enz.
Je snapt hem al heel veel verschillende timing situaties en complexe testgevallen.
Ik had toen via een truuk alle testgevallen ingebouwd en daar het op een ATTINY84 draaide was de UNO groot genoeg. Het nadeel was dat je door de hele code constant #ifdef DEBUG .... #else .... #endif tegenkwam. Aanleiding om eens te onderzoeken of er andere wegen naar Rome waren. Dus moest ik een manier vinden om de reads en writes af te vangen. Een nieuwe functie maken met hetzelfde prototype kan wel alleen loop je stuk tijdens linken (2 x gedefinieerd). Uiteindelijk uitgekomen op inline. Deze vervangt de aanroep door tijdens compileren daadwerkelijk de code die in de inline functie staat in het source te zetten. Hierdoor werd mijn digitalRead(..) nu in het uiteindelijke source call Autotest::callDigitalRead(..) en wordt de aanroep automatisch naar mijn class omgeleid en kan ik doen wat ik wil.
Dan ben je er nog niet. Testgevallen zijn leuk maar vreten geheugen en moeten gemakkelijk te managen zijn. Dus kan ik nu in Excel de testgevallen in de sheet zetten. Door op de button te klikken genereert hij 3 .h bestanden die in dezelfde foder staan als de Excel file zelf. Dus als je alles in de sketch folder zet staan ze gelijk goed.
Dan ben je er nog niet het moet ook nog in het Flash geheugen en daardoor moet je ook gelijk allerlei routines maken om de includes goed op te nemen, en om het flash geheugen te scannen. En dat gaat wel lekker.
Op de site zie je een uitgewerkte voorbeeld van de testresultaten van de eerdere opdracht. Met conditional formatting laat je de "1" blauw kleuren en kan je gelijk het bit patroon zin.
En ach het houdt mij lekker van de straat
En out of de box denken..... dat doe ik al 38 jaar
Ik heb laatst een project gedaan voor een klant waarbij er een soort muziek speler op zat. Als de PLAY wordt ingedrukt, dan moet het volume gedurende x seconden oplopen en dan draaien voor y seconden. z seconden voor het eind moet het volume weer afbouwen en weer een beetje oplopen. Als PLAY voor de 2e x wordt ingedrukt dan moet hij gelijk uitschakelen. Als er een reset van buiten afkomt, moet hij gelijk uitschakelen maar wel het volume afbouwen (2 sec) en wer opbouwen. Als FF wordt ingedrukt en hij loopt nog niet dan moet eerst PLAY worden opgestart en daarna FF ingeschakeled zoalng hij is ingedrukt enz.enz.
Je snapt hem al heel veel verschillende timing situaties en complexe testgevallen.
Ik had toen via een truuk alle testgevallen ingebouwd en daar het op een ATTINY84 draaide was de UNO groot genoeg. Het nadeel was dat je door de hele code constant #ifdef DEBUG .... #else .... #endif tegenkwam. Aanleiding om eens te onderzoeken of er andere wegen naar Rome waren. Dus moest ik een manier vinden om de reads en writes af te vangen. Een nieuwe functie maken met hetzelfde prototype kan wel alleen loop je stuk tijdens linken (2 x gedefinieerd). Uiteindelijk uitgekomen op inline. Deze vervangt de aanroep door tijdens compileren daadwerkelijk de code die in de inline functie staat in het source te zetten. Hierdoor werd mijn digitalRead(..) nu in het uiteindelijke source call Autotest::callDigitalRead(..) en wordt de aanroep automatisch naar mijn class omgeleid en kan ik doen wat ik wil.
Dan ben je er nog niet. Testgevallen zijn leuk maar vreten geheugen en moeten gemakkelijk te managen zijn. Dus kan ik nu in Excel de testgevallen in de sheet zetten. Door op de button te klikken genereert hij 3 .h bestanden die in dezelfde foder staan als de Excel file zelf. Dus als je alles in de sketch folder zet staan ze gelijk goed.
Dan ben je er nog niet het moet ook nog in het Flash geheugen en daardoor moet je ook gelijk allerlei routines maken om de includes goed op te nemen, en om het flash geheugen te scannen. En dat gaat wel lekker.
Op de site zie je een uitgewerkte voorbeeld van de testresultaten van de eerdere opdracht. Met conditional formatting laat je de "1" blauw kleuren en kan je gelijk het bit patroon zin.
En ach het houdt mij lekker van de straat
En out of de box denken..... dat doe ik al 38 jaar
Re: Geautomatiseerd testen op de Arduino
Je uitleg voegt veel toe. Als beginnend knutselaar bekeek ik je oplossing met ontzag, maar het ontbrak me de toepassing te zien. Nu wel. Niet tot in de puntjes. Ik doe het je niet na. Maar het achterliggend mechanisme, waarbij je met bekende tools nieuwe wegen maakt, is natuurlijk herkenbaar mooi.
Wat ik begrijp is dat je met een vast prototype, meerdere scenario´s kunt testen door libraries aan te maken met Excel. En dat in plaats van alle opties loos mee te laten liften via een veelheid aan #ifdef DEBUG 's? Je pleegt je interventie een niveau hoger dan gebruikelijk begrijp ik. En is het dan zo dat bij een ander prototype ook een nieuwe excel-construct nodig is?
Wat ik begrijp is dat je met een vast prototype, meerdere scenario´s kunt testen door libraries aan te maken met Excel. En dat in plaats van alle opties loos mee te laten liften via een veelheid aan #ifdef DEBUG 's? Je pleegt je interventie een niveau hoger dan gebruikelijk begrijp ik. En is het dan zo dat bij een ander prototype ook een nieuwe excel-construct nodig is?
- nicoverduin
- Berichten: 5043
- Geregistreerd: 13 Mei 2013, 20:57
- Woonplaats: Heemskerk
Re: Geautomatiseerd testen op de Arduino
't is veel simpler:
Er is straks een library AutoTest. Die zet je in de Arduino IDE libraires en klaar.
In de sketch folder kopieer je de Excelsheet en past hem aan voor de zaken die je wil testen en welke pinnen je gebruikt als input of output.
In je sketch zelf zet jet statement "#include <autotest.h>". In Excel klik je op de button "generate testsets". En klaar. compileren, installeren en draaien maar.
Ik maak dus geen libraries aan of zo. Ik maak include bestanden waar je eigenlijk verder niet aan hoeft te zitten. Autotest.h verwacht die bestanden in jouw sketch folder. Dus verder met je tengels afblijven. Om dat verder uit te leggen kan ik wel een keer een post aan wijden.
Maar om je een idee te geven hoe die includes worden ingelezen:
Terwijl ze er zo uitzien:
De grap is dat je programma gewoon niet in de gaten heeft dat alle pinnen fake zijn geworden
De rest is gewoon het probleem benaderen vanuit de gebruiker en niet de ontwikkelaar. Dan ga je vanzelf buiten de box denken.
Er is straks een library AutoTest. Die zet je in de Arduino IDE libraires en klaar.
In de sketch folder kopieer je de Excelsheet en past hem aan voor de zaken die je wil testen en welke pinnen je gebruikt als input of output.
In je sketch zelf zet jet statement "#include <autotest.h>". In Excel klik je op de button "generate testsets". En klaar. compileren, installeren en draaien maar.
Ik maak dus geen libraries aan of zo. Ik maak include bestanden waar je eigenlijk verder niet aan hoeft te zitten. Autotest.h verwacht die bestanden in jouw sketch folder. Dus verder met je tengels afblijven. Om dat verder uit te leggen kan ik wel een keer een post aan wijden.
Maar om je een idee te geven hoe die includes worden ingelezen:
- Code: Alles selecteren
#include "AutoTest.h"
//
// get the generated headers
//
const PROGMEM char pinHeaders[] =
#include "pinHeaders.h"
;
const PROGMEM char testCases[] =
#include "TestCases.h"
;
#include "FieldLengths.h"
//
// end getting generated headers
//
Terwijl ze er zo uitzien:
- Code: Alles selecteren
/**
* @file TestCases.h
*
* this is a generated file from generateTestSets.xls
* It contains all the testcases generated from the sheet
*/
#ifndef TESTCASES_H_
#define TESTCASES_H_
"Test case 1,1,0,10,100\n" //This is a simple testcase
"Test case 2,1,0,0,0\n" //This is testcase 2
"Test case 3,1,1,1,200\n" //This is just a tryout
"Test case 4,0,1,0,100\n"
"Test case 5,0,0,0,1000\n" //And finish this test case
"\n"
#endif // TESTCASES_H_
De grap is dat je programma gewoon niet in de gaten heeft dat alle pinnen fake zijn geworden
De rest is gewoon het probleem benaderen vanuit de gebruiker en niet de ontwikkelaar. Dan ga je vanzelf buiten de box denken.
- nicoverduin
- Berichten: 5043
- Geregistreerd: 13 Mei 2013, 20:57
- Woonplaats: Heemskerk
Re: Geautomatiseerd testen op de Arduino
Vandaag een werkende app door de autotester gehaald. Gelijk nog een paar leerpunten erbij, maar hij werkt Hopelijk eind volgende week op GITHUB. Ik twijfel nog een voorziening te treffen voor de analogWrite en analogRead(). Zal niet veel werk zijn verwacht ik. eerst maar een nacht over slapen...
Zie verder http://www.verelec.nl.
Zie verder http://www.verelec.nl.
- nicoverduin
- Berichten: 5043
- Geregistreerd: 13 Mei 2013, 20:57
- Woonplaats: Heemskerk
Re: Geautomatiseerd testen op de Arduino
Ik heb een voorlopige versie op GITHUB gezet : https://github.com/nicoverduin/AutoTest
7 berichten
• Pagina 1 van 1
Wie is er online?
Gebruikers in dit forum: Geen geregistreerde gebruikers en 5 gasten