Hi Matt, A pic does not have much ram, you probably don't have the space to buffer the amount of data you want. Also, you application (the one you're debugging) needs ram. So that's a limitation you have to live by.
Also, provision for stuff like this does not belong in the debug library. It's the way you create the stream (device) you write to. But be aware the measures are proportional. E.g. writing to an 23k256 takes time too and might save little time over printing to serial in the first place (and USB may even be faster!). I use Rob's serial-interrupt library with a queue of 64 or 128 for demanding debug. This way a full line of text can be queued and sent while the program resumes. This brings the debug speed close to the acual baudrate (115k2 in my case, but it should be possible to raise this up to 1 Mbps. As for you queue modification options, I don't see what you intend to. What I do know is that the queue library is interrupt safe in the way that put and get do not interfere. If you write to the same queue from both interrupt and main, data might get lost. As I said before: the queue is based on long-used and well-tested code and changing the core is not recommended. An other thing is that queue supports both blocking and non-blocking put. So you can choose what you want when the queue is full: take the time (delay you app) until there is space available or keep up to speed but loose chars. I always choose the first since incomplete debug info is useless and can be deceptive. Joep 2010/9/14 mattschinkel <[email protected]>: > 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. > > -- 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.
