Jump to content

DavidN

EstablishedMember
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DavidN

  • Rank
    Newbrie
  1. Does anyone have a USB stack for BoostC that works on the 16C765? I would be very greatful if you were willing to share. Thanks, David
  2. I am using an external GREP tool (AstroGrep, open source) that can open an editor to a search result by calling the editor with file name and line number on the command line. Does SourceBoost IDE have command line paramters to load a file at a specific line? Thanks, David
  3. You should advertise this pre-release in the "News" when the SourceBoost IDE starts. Please fix the integer array math soon. David
  4. There really isn't a good place to post this, so I will put it here. Please modify the forum search constraints to allow searching of words that are less than 4 characters. This is especially an issue for a software programming support site due to all the short source code words (rom, mod, %, asm, etc.). Thanks, David
  5. I have 16 files in my project. Everytime I build, all 16 files are compiled, even if only 1 file changed. Is there a way to perform an incremental build in which only the files that have changed (and the files that depend on them) are compiled? Thanks, David
  6. Dave, Thanks for the clarification. I understand what you are saying, but I would love to see some changes to rom in the future. I think it would be much better if it acted more like a type qualifier rather than a type. The function overloading is nice, but now I am required to have two functions for every function that takes a rom parameter. Not only does this unecessarily require extra code space, but it also means that I have two functions that differ only in their parameter definitions. If I make a change to one function, I now have to remember to also change the other. This does not promote good code structure. Maybe a good way to handle this would be to allow non-rom pointers to be passed in rom parameter locations (much like the const qualifier). Then the compiler could decide the correct way to access the memory. In addition, I would like to see rom pointers support pointer arithmetic and dereferencing with '*'. Using rom with other types (including structs and unions) and non-pointer variables would be another great feature addition. Perhaps a better way to handle this would be to use rom solely as a storage qualifier when defining variables to be stored in program memory. For instance, you could use "rom const char *s ="Hello". This would simply force "Hello" to be stored in program memory and s could be treated as "const char *" throughout the rest of the code. I may be missing something, but why not completely get rid of the rom qualifier and place all const variables in program memory? Don't all other compilers use this method? As an application developer, this would be my preferred solution. Thanks, David
  7. Is it acceptable to use const or should I always use rom? The compiler never complains when it sees the const keyword, but then usually has trouble with the const variable later in the code. Is const a valid keyword? How is it different from rom? If I use rom for a function paramter definition, can I still pass a ram pointer to that function? Thanks, David
×
×
  • Create New...