Comfortabel ontluizen

Simon Voortman legt uit hoe dat kan

Heeft u dat nu ook wel eens, dat u een programma aan 't schrijven bent, en het wil maar niet goed lukken? En dat u dan vertwijfeld zoekt naar een oplossing om de inhoud van variabelen te tonen, op het scherm te zetten, zichtbaar te maken of wat dan ook?

Soms kun je dan gebruik maken van hulpjes zoals !Reporter, maar als je programma telkens crasht net voordat je een Wimp_Poll hebt kunnen doen? Of er zit een fout in je Wimp_Redraw routine? Of je zult maar net een (oud) BBC BASIC programma onderhanden hebben, wat het hele scherm overneemt, en dat blijft doen totdat je het programma weer afsluit...

In dat laatste geval zeker, maar ook in veel andere gevallen is het misschien een idee om de seriële poort te gaan gebruiken om de informatie die u nodig heeft, op een andere computer zichtbaar te maken.

Veel mensen hebben nl. meerdere machines, meestal één of meerdere RISC OS-machines en vaak ook nog andere desktop dan wel portable machines, maar doorgaans hebben ze allemaal wel een seriële poort en een terminalprogramma beschikbaar. En dat is al genoeg!
Afhankelijk van het terminalprogramma kunt u overigens de tekst ook nog opslaan (via de Spool functie) en op die manier alsnog een logbestand aanmaken of de tekst afdrukken.

Met de hier beschreven routines (in BASIC en C) die als library aan het programma gekoppeld kunnen worden, kan op een hele eenvoudige manier deze functionaliteit aan een programma toegevoegd worden.
De eerste versie van deze library is in

en
, en alleen geschikt voor de interne seriële poort. Er komt ook nog een BASIC/C versie voor de blockdrivers, deze verschijnt in een van de volgende nummers.

De opzet van het geheel

Wat is er nodig:

Er zijn twee computers nodig: de computer met het te debuggen programma, en de computer met het terminal programma. Tussen die twee computers is er een nul-modem verbinding nodig: dat kan een nul-modem kabel zijn, al zou je ook met twee modems (en eventueel een huistelefooncentrale) kunnen werken. Nul-modem kabels zijn te koop bij uw plaatselijke computer-hardware-leverancier voor een paar euro; het schema staat ook in de Kabels-bestanden (van Henri Derksen) op een (lokaal) Aconet-BBS.
Belangrijk te bedenken is: beide computers moeten dezelfde seriële snelheid aan kunnen, probeer dus geen verbinding (bv. >19200 bps) te maken tussen een A300/A400 serie en een RiscPC.

Gebruik van de routines

Dat is heel simpel. Ik geef gelijk maar een

programma. Het test de goede werking van het library-deel:

Regel 10 is de naam van het te debuggen programma en zorgt ervoor dat het opgeslagen kan worden met het commando SAVE (zonder dat er een naam opgegeven hoeft te worden).
Regel 20 zorgt ervoor dat het programmadeel SDebugLib (van SerialDebugLibrary) als Library (dus zoals een boek uit een bibliotheek) geleend kan worden uit een collectie van programma-fragmenten. Hierna zijn alle functies en procedures uit SDebugLib gewoon te gebruiken.

(Aangezien ik hier alleen de bestandsnaam van SDebugLib opgeef, moeten beide programma's in dezelfde map staan, en moet de huidige map hier naar toe verwijzen. Stel dat u ze om te testen op de ramdisk gezet heeft, dan moet u door *ram<enter> en eventueel *dir $<enter> de map goed zetten.)

Regel 30 maakt hier gelijk gebruik van, door de functie 'sdl_open' uit de zojuist geïnstalleerde collectie aan te roepen. Dit moet precies één keer in het hele programma gebeuren. Aan deze procedure worden 4 parameters doorgegeven:

  1. De snelheid waarop de seriële poort ingesteld moet worden,
  2. De naam van het programma wat van SDebugLib gebruik gaat maken,
  3. De versie van dit programma, en
  4. Een letter (token) ter herkenning van dit programma. (bv. S voor SDebug)

Het laatste lijkt misschien overbodig, maar is handig als u meerdere programma's tegelijk aan het testen bent, die allemaal uitvoer via de seriële poort sturen.

Er komt ook nog wat terug, nl. de waarde die als snelheid opgegeven was (in het voorbeeld 57600) als alles goed gegaan is, en de waarde -1 als de snelheid niet ingesteld kon worden.
Regel 40 en 50 sturen wat tekst via de seriële poort naar de andere kant, en regel 60 tenslotte sluit het programma netjes af.

Wat komt er aan de

op het scherm?

Als eerste een lege regel, om het begin van deze sessie aan te geven.
Daarna een regel die wat informatie geeft over het te debuggen programma: De naam, het versie nummer, de datum waarop deze sessie gestart is,
Een regel die begint met het token S, de tijd, en de tekst van regel 40,
En tenslotte een regel met token S, de tijd, en de tekst van regel 50.
Stel dat u twee verschillende programma's hebt draaien, die alle twee via de seriële poort ont-luizen, dan krijgt u bijvoorbeeld

Overigens gaat dat natuurlijk alleen goed als ze beiden dezelfde snelheid van de seriële poort gebruiken! En u kunt natuurlijk ook desgewenst het kopje met de startdatum weglaten.

Hoe zit de

in elkaar?

Op regel 40 begint de definitie van functie sdl_open, met de 4 al eerder genoemde parameters: speed, program, version en token. Variabele sdl_token$ is nodig om de waarde van token te onthouden voor de er op volgende aanroep van sdl_report.
Regel 50 is een opsomming van bitrates in 'OS_SerialOp 5/6' volgorde.
Regel 60 vertaalt de opgegeven snelheid naar een getal tussen 1 en 18 wat nodig is voor OS_SerialOp, en geeft -1 terug als geen combinatie mogelijk is.
Regel 70 stelt de ontvang- en zendsnelheid in, en stuurt als eerste een lege regel over, waarna regel 80 het kopje met de datum produceert.

Via regels 110 t/m 130 wordt een te rapporteren regel voorzien van token en tijd en doorgestuurd naar PROCline.
Regel 150 start de definitie van PROCline, dat is een (intern te gebruiken) procedure met als doel een regel te versturen via de seriële poort. Zou overigens ook gebruikt kunnen worden om debuginformatie 'kaal' naar de andere computer te versturen, dus zonder token en tijdsaanduiding.
De regel in l$ wordt byte voor byte verstuurd, waarna een CR en een LF verstuurd worden.

De versie in C

Deze bestaat uit twee bestanden: sdebug.c en sdebug.h, deze bestanden zijn van voldoende commentaar voorzien.

Compileren:

cc -c c.sdebug dit produceert het library-object,
cc -dTEST c.sdebug dit produceert het uitvoerbare sdebug programma

Om gebruik te maken van sdebug moet u in eigen programma's opnemen: #include "sdebug.h"

Daarna linkt u het bestand o.sdebug aan uw eigen programma.

Reacties

Dit was het dan voor deze keer, volgende keer gaan we de routines geschikt maken voor het gebruik van de blockdrivers. In de tussentijd kunt u natuurlijk deze routines proberen, en uw reactie daarop geven.

Simon Voortman
Aconet#77:8500/100.1, of via email:
simon_voortman@aconet.org