On 6 Oct 2008, at 20:18 , Joep Suijs wrote: > > Hi all, > > Until now, I assumed we'd only need two files to compose a test: > - a board file, which tells the type of pic, it's configuration (like > type and frequency of the oscillator) and it's connections. > - a test file, which tests a specific function.
Right now, most test files include the board information. I don't like this either, but that's the way it is. Board file pros: focuses on the board, includes a formal pinlist in hardware order includes libraries sets hardware/peripheral stuff like baudrate and spi_clock Board file cons: yet another file > But in some cases, there are more options. Some interfaces, like i2c > and serial, have multiple libaries. So this gives us 3 files: the > board, optional: the interface and then the test. How do we deal with > this? Multiple files are not a problem per se. Some of my test programs call 5 libs. > 1. create a test file for each interface > This gives more files with similar code. Not ideal and a bit > error-prone but not that bad. Test files for a certain function should be as easy as possible, and focus on that test. Example of my TC77 test: > forever loop > lcd_setcursor(0,0) > CS = low > tc77_read_raw(temperature_raw) > CS = high > print_word_binary(lcd, temperature_raw) > > lcd_setcursor(1,0) > CS = low > tc77_read_celsius_sbyte(temperature_8) > CS = high > print_sbyte_dec(lcd, temperature_8) -- prints minus if below 0 > lcd =" " -- to wipe out old digits > > lcd_setcursor(0, 20) -- row 3, position = 1 > CS = low > tc77_read_celsius_sword(temperature_16) > CS = high > format_sword_dec(lcd, temperature_16, 5, 2) -- width 6: -xx.xx > or xxx.xx > lcd =" " > > lcd_setcursor(1, 20) -- row 4, position = 1 > CS = low > tc77_read_celsius_sdword(temperature_32) > CS = high > format_sdword_dec(lcd, temperature_32, 7, 4) -- 8 wide: - > xx.xxxx or xxx.xxxx > lcd = " " > > delay_100ms(2) -- for proper display > viewing > end loop and yes, it needs an LCD as well. > 2. adapt the test file when you want an other interface > Quick and dirty (mostly dirty). Not suitable for automated tasks. Naah. > 3. have the to-be superscript support more then 2 files to compose a > test (3 or maybe more?). > Looks at the best option at first glance. But it also means we can not > define tests as simple 2-dimensional (test x on board y). The benefits > might not add up to the costs of the complexity induced. ??? > > But this is just my opinion. Please let me know your and let Seb > decide ;-) > > Joep > > > > --- ir EE van Andel [EMAIL PROTECTED] http://www.fiwihex.nl Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands tel+31-546-491106 fax+31-546-491107 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
