I made modifications you suggested, and more. See my sample. I changed debug lvls from constant bytes to variable bits and...
I also added support for a fast debug array which would hold debug data, and that data will get dumped when the user calls debug_read_storage(). So, if you are running something with timing requirements you may want to use this feature. However, I am still not quite sure about this new feature. Should it be a array or a queue? There are some options: 1. Use a array: An array can be larger, much larger (with my large array lib or 23k256 array lib). Debug strings can take up a lot of space. only first data gets logged, if more data is stored then the size of the array it will be lost. The user will get a debug error message. 2. Use a Queue. A queue is only 256 bytes (I don't think that's enough). Data first logged will get lost (and user can have an error message), new data will overwrite old data 3. Make a queue. Same as #2 but queue size can be larger (like #1) 4. Change queue library, to allow for a larger array (like #1), by using if !defined(array) in the lib. if !defined(queue01_data) then var volatile byte queue01_data[queue01_size + 1] end if I may be able to let the user choose weather to keep old data or new data in the queues. All of the above options are probably not interrupt safe. I don't think we have to work that hard on this :) Is #4 ok with you guys? I think it is the best solution. Matt. On Sep 12, 5:22 am, Joep Suijs <[email protected]> wrote: > Hi Matt, > > Good job! > > > I added the debug lib + sample. Joep, would you like your name to be > > added as author? > > No, your idea, you did the work so you deserve the credits. > > > Good: When I change the major constant to false to turn off the > > library, none of the debug code is in the ASM file. So, this will > > require no extra processing power when turned off. > > Good indeed! > > > Bad: I have some problem with print_string/debug_string. Can someone > > please test my sample? the debug string does not seem to get carried > > correctly to the print_string lib. > > This is a bug related to pragma inline (at least I think it is - if > you remove it, it works like it should). Create a small program to > demonstrate, but it (with all required libraries and the asm + hex > output) in a bugreport directory under casulaties and ask Kyle to > check. > > On 'debug_enable': > - I see you use capitals, which implies it is a constant. The good > thing about debug_enable is that is allows runtime enable and disable > of groups. And there is little reason to make it a constant, since > this won't remove debug statements when a group is disabled. So I > suggest to make it lower case. > - In addition to this: the array was my first idea, but since we don't > have bit arrays, I suggest to use a single (word) variable, not an > array. The check would be to 'and' debug_enable with debug_level and > execute when the result is non-zero. > const DEBUG_0 = 1 > const DEBUG_1 = 2 > const DEBUG_2 = 4 > const DEBUG_3 = 8 > .. > const DEBUG_15 = 32768 > > A single statement is: > debug_print(DEBUG_0, "testing"); > > But at the same price you can do: > debug_print(DEBUG_0 | DEBUG_3 | DEBUG_7, "new frame"); > > Joep -- 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.
