I thought it would be useful, but I'll take it out anyways. I could do the same within another lib, or leave it up to the user.
I still think we need a solution for larger queues. 256 bytes is not very much compared to PIC sizes these days. The PIC's I use have 4kb ram, this gives me space for the program and debugging. Matt. On Sep 14, 2:05 am, Joep Suijs <[email protected]> wrote: > 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 > > athttp://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.
