Vraag:
Unit testen AVR-assembleertaal
Len Holgate
2009-11-12 15:26:42 UTC
view on stackexchange narkive permalink

Hoe test je je assemblagecode unit?

Ik werk aan een seriële servocontroller als onderdeel van een hexapod-robotproject en de code is zo ver gekomen dat het ingewikkeld wordt;) Ben ik gewend om unit-tests te gebruiken in mijn dagelijkse werk als ontwikkelaar van C ++ -servers en heb daarom geprobeerd dezelfde soorten tests toe te passen op mijn AVR-assemblagecode. Ik heb een manier bedacht die voor mij goed werkt (zie hier) maar ik ben geïnteresseerd of er standaardtools of -technieken zijn die ik mis.

Bijgewerkt: Voor degenen onder u die geïnteresseerd zijn, is de volledige bron van de servocontroller en de unit-tests nu hier beschikbaar.

Twee antwoorden:
Kortuk
2009-11-13 14:57:06 UTC
view on stackexchange narkive permalink

Ik zou dit ook als elegant willen omschrijven, maar ik zou het probleem graag willen toevoegen, als je me mijn inbreuk wilt vergeven.

Ik weet dat er erg dure softwarepakketten zijn om door situaties als deze heen te werken, maar bij het bedrijf waar ik werk, kunnen we de kosten niet betalen, tenzij we zeker weten dat het doet wat we nodig hebben.

Test Driven Development (TDD) is een van de betere systemen waarvan ik heb gehoord voor ontwikkeling, en ik geniet ervan het, maar de problemen die mijn tijd in beslag nemen, worden normaal gesproken veroorzaakt door complexe interrupt- en hardwaregebeurtenissen die velen glitches zouden noemen. Het lijkt een kleinigheid om elke 2 uur een probleem te hebben wanneer de sterren uitgelijnd zijn, maar als je telefoon maar één keer per week bevroor, zou je de naam van de technicus vervloeken. In ons geval moeten we naar een feed-lot gaan als er dingen echt kapot gaan, wat ik, zoals je kunt begrijpen, graag vermijd.

Ik heb zeer intelligente oplossingen gezien voor het controleren van de functionaliteit van subsystemen, die, indien correct geïmplementeerd, zou het me waarschijnlijk 3 uur van een 50-urige werkweek besparen, maar als er een intelligente manier was om glitch-situaties te vinden, zou het me weken werk besparen bij het zoeken naar de "bug" die zich af en toe in het veld voordoet laden.

Dit bericht helpt waarschijnlijk niet veel, maar ik merk dat door alles aan het licht te brengen, alles gemakkelijker op te lossen is. Als er een TDD-methode was om glitch-situaties op te sporen, zou ik er tienduizenden kunnen krijgen om ervoor te betalen. -Max

Ik heb niet echt nagedacht over het testen van de interactie tussen de interruptcode en de niet-interruptcode. Het is een goed punt. Ik was van plan om mijn PWM-generatie timer-interruptcode te testen buiten een onderbrekende situatie op dezelfde manier als de manier waarop ik de seriële code van mijn hoofdlijn test. Ik denk dat zelfs als ik daar dekking voor heb, ik nog steeds de interactie mis. Ik veronderstel dat ik interrupts zou kunnen activeren vanuit de tests (het is gemakkelijk met de timer-interrupt, maar alle interruptcode kan worden ingesteld om te worden uitgevoerd op een timer-interrupt binnen het testharnas). Niet triviaal.
Ik begrijp u misschien verkeerd, maar ik probeer heel voorzichtig te zijn met het niet onderbreken en onderbreken van code-interacties. Ik zou waarschijnlijk lakser moeten zijn in mijn gebruik van atomaire operaties, maar het is nooit aangetoond dat het schade toebrengt op het niveau dat ik onze optimizer heb. PWM-generatie. Als je een extreem nauwkeurige snelheid nodig hebt, bijvoorbeeld door een Compare-module in je chip te gebruiken, en een andere interrupt is druk bezig met iets anders en vertraagt ​​je met 50uS, dan zou dat het einde van de wereld kunnen betekenen.
In sommige gevallen kunt u voorrang krijgen, of u kunt zelfs een interrupt zelf laten uitschakelen en intern globale interrupts opnieuw inschakelen, afhankelijk van het platform, maar de gemakkelijkste weg voor mijn eigen ontwikkeling is de tijd in interrupts beperken tot dingen die absoluut noodzakelijk zijn en normale code laten doen de rest van het werk.
Mijn huidige ontwerp wordt uitgelegd op mijn blog, evenals een voorgesteld nieuw ontwerp. Op dit moment heb ik 64 PWM-kanalen gegenereerd door een timer-interrupt en geen andere interrupts; serieel wordt gedaan door middel van polling. Dit betekent dat de PWM zeer solide is, maar de serie kan problemen hebben. Mijn nieuwe ontwerp zou interrupts voor UART gebruiken, evenals de timer voor het genereren van PWM en het zorgvuldig opnieuw inschakelen en blokkeren van interrupts om glitchvrije PWM en glitchvrije UART-verwerking te garanderen ...
Ik gebruikte de PWM als voorbeeld, het systeem waar ik dit probleem mee had, heeft 3 SPI-interfaces met 1 van de SPI-verbindingen met 3 chips die we erop gebruiken. Er zijn 4 verschillende poortonderbrekingen die informeren over de statusverandering van externe chips en een paar andere dingen die aan de hand zijn. Het probleem wordt erger naarmate je meer interfaces hebt.
Begrijpen. Ik weet nog niet hoe het mogelijk is om dergelijke interacties te testen. De belangrijkste reden voor de vraag was om erachter te komen of anderen betere ideeën hadden :)
Ja, ik heb uw vraag begrepen en vond het een uitstekende. Ik kon er geen toevoegen aan het antwoord, dus waarom zou ik de ruimte met vragen niet uitbreiden?
Amos
2009-11-12 18:16:42 UTC
view on stackexchange narkive permalink

Interessant. Na Kerstmis was ik van plan om wat Assembler met Pics te gaan doen, als ik wat meer tijd heb, zal ik je systeem eens goed bekijken.

Een manier die ik zou kunnen zien is om een ​​soort framework in een andere taal te scripten om de nepobjecten enz. te creëren en af ​​te breken, maar hoe je dit zou koppelen aan de chip / simulatie zou een probleem zijn.

Als het echter te zwaar wordt, weegt dat op tegen de voordelen van het testen van eenheden en maakt het u ook minder enthousiast om het te gebruiken.

Het aan het werk krijgen in de simulator was mijn eerste hindernis totdat ik erachter kwam hoe ik de code in aparte bestanden kon opsplitsen en simpelweg enkele van de labels waar ik naar zou springen in de echte code kon "bespotten". Ik zal het hele ding posten zodra ik klaar ben. Het achteraf inbouwen van de unit-tests in de code duurt even, maar het is de moeite waard geweest.
Nu ik een goede kans heb gehad om door uw methodologie te kijken, vind ik het vrij elegant. Misschien kijk ik na Kerstmis naar avrs, omdat er voor hen veel meer community-based dingen lijken te zijn dan voor de Pics. Enig idee wat een fatsoenlijke Linux IDE voor AVR Assembler-programmering zou kunnen zijn.
Er is een GNU-toolketen die u kunt gebruiken in plaats van AVR Studio (dit is de gratis toolset van Atmel). Het is waarschijnlijk mogelijk om dat op Linux te draaien, maar dat heb ik niet nodig.
Ik heb net deze link gevonden naar een Linux Journal-artikel over ontwikkelen voor AVR onder Linux: http://www.linuxjournal.com/article/7289
Mijn grootste zorg met dat artikel is dat het uit 2005 stamt en dus mogelijk verouderd is.
Ik doe de hele tijd AVR-GCC op Linux. Het werkt als een kampioen. (en als je Arduino op Linux hebt gebruikt, heb je het ook gebruikt)


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 2.0-licentie waaronder het wordt gedistribueerd.
Loading...