HDTChecker ReadMe ----------------- This utility will analyse a given *.hex file containing a compiled HDT. The utility is written in C and requires the following RoBIOS header files: const.h, types.h, hdt.h, hdt_sem.h HDTChecker is a command line tool that accepts a filename as parameter. On start it will read in the HEX file which contains the well known ASCII S-Records. These are processed during loading and used to build a binary version of the contained HDT image in the PC memory. This memory block can be accessed by the tool like RoBIOS accesses its HDT in the FlashROM. Thus it makes it quite easy to step through all the HDT entries and fill up an internal list of used TPU channels, In/Out latches and the PortE pins. If a double assignment is found, the info about the corresponding two HDT-entries is printed on the screen. There are also some extra checking rules in it, since for example the PSDs are allowed to use the same TPU channel for generating the timing and can use the same DO-pin for triggering the PSDs all at once. Some problems are only reported as warnings since they might work but should be double checked by the user. There are some more options you can pass to the program: -l This will produce a list of all contained entries in the HDT with their type, semantics and name. -v Verbose mode. In this mode a lot of comments are printed out, so that the user can exactly see what the programm has checked and what information it has found in each corresponding data structure. -s This will produce a summary of used ressources which will be sorted by the ressource type, so that it easily can be seen which channels or pins have not been used yet. And it can be used for documentation purposes. All options can be set in a single call (HDTChecker.exe -l -v -s test.hex), so that the resulting output will contain all three information blocks. Since there can be a lot of info printed on the screen it is helpful to use the redirection into a file by using the ">" operation: HDTChecker.exe -l -v -s test.hex > report.txt I know that the source of the core test routine is a bit lengthy and can be optimized by exporting some functions that are used over and over again inline in the test function. I left it that way, so that I could easily include extra rules and use adapted text outputs. Example output of the HDTChecker -------------------------------- Checking the HDT-File "hdt4std.hex": [ERROR] SERVO "SERV01" uses the same TPU channel (2) as QUAD "LEFT" [ERROR] SERVO "SERV02" uses the same TPU channel (3) as QUAD "LEFT" [ERROR] SERVO "SERV03" uses the same TPU channel (4) as QUAD "RIGHT" [ERROR] SERVO "SERV04" uses the same TPU channel (5) as QUAD "RIGHT" [ERROR] COMPASS "COMPAS" uses the same TPU channel (13) as SERVO "SERV12" [ERROR] COMPASS "COMPAS" uses the same inlatch channel (0) as PSD "P0-F" Checked 28 HDT-entries Found 6 errors and 0 warnings Summary of ressource allocation: -------------------------------- Ch.Type"Name"(TypeID:Semantics) [TPU channels] 0.MOTOR"MotA-L"(-100:-101) 1.MOTOR"MotB-R"(-100:-100) 2.QUAD"LEFT"(-400:-400) 3.QUAD"LEFT"(-400:-400) 4.QUAD"RIGHT"(-400:-401) 5.QUAD"RIGHT"(-400:-401) 6.SERVO"SERV05"(-300:-355) 7.SERVO"SERV06"(-300:-356) 8.SERVO"SERV07"(-300:-357) 9.SERVO"SERV08"(-300:-358) 10.SERVO"SERV09"(-300:-359) 11.SERVO"SERV10"(-300:-360) 12.SERVO"SERV11"(-300:-361) 13.SERVO"SERV12"(-300:-362) 14.PSD"P0-F"(-200:-200) [Inlatch channels] 0.PSD"P0-F"(-200:-200) 1.PSD"P1-L"(-200:-205) 2.PSD"P2-R"(-200:-210) 3.PSD"P3-LD"(-200:-203) [Outlatch channels] 0.PSD"P0-F"(-200:-200) 2.COMPASS"COMPAS"(-900:-900) 4.COMPASS"COMPAS"(-900:-900) [PortE channels] 0.MOTOR"MotA-L"(-100:-101) 1.MOTOR"MotA-L"(-100:-101) 2.MOTOR"MotB-R"(-100:-100) 3.MOTOR"MotB-R"(-100:-100) 4.PSD"P5-BK"(-200:-212) 5.PSD"P4-RD"(-200:-204) ------------------------------------------------- Klaus Schmitt, April 2005