Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About izakdude

  • Rank
  1. I was worried about that, whether or not it would keep the labels unique between inline function calls... However, I don't think it's a problem; I tried it quickly in a program and here's a snippet of the assembly in the debugger: nop2(); 00E3 28E4 GOTO label268437437 00E4 label268437437 nop2(); 00E4 28E5 GOTO label268437443 00E5 label268437443 the labels are unique.
  2. That helps, thanks. Is there any reason that something like this would cause a problem? inline void nop2() { asm { goto label label: } } that should give me the advantage of saving space, while being very easily readable in use. (a simple function call to nop2(); as I had mentioned earlier)
  3. A bit slack of me for not pointing this out - but who in their right mind would use a 16F today? :-) <{POST_SNAPBACK}> Actually, I am using 16F series. None of the stuff I am doing thus far requires the priority interrupts, higher clock speeds, etc. that the 18F series provides. I'm certainly not biased against the 18F series, but all I currently have on hand are 16F's, and all my experience thus far is on them as well. as a sidenote, what 18F-series PIC would be the best to start with after primarily using the 16F88? the 18F1320 seems similar. Well I guess it's
  4. it uses the same amount of program space? I was under the impression that it counted as only a single instruction in memory, but took 2 cycles to execute. If it takes up as much space as two NOPs, then I guess that makes my question pointless, since it's less readable as you say and is thus useless without any advantage.
  5. Okay, I will first admit that I haven't tried to do MUCH with the inline assembly feature yet. However, I tried doing this: asm { GOTO $+1 } which is something i'd seen used in assembly to get the effect of two NOPs with only one line of assembly, ie - more efficient. I also tried it with a lowercase 'goto' but that didn't work either... the term 'goto' was highlighted blue since it's a C command also, which led me to think that it might just be a name conflict... Is there any way I can modify this to make it work? are there any other limitations to assembly commands th
  6. Yeah, I actually have that article of EPE too, however it's done with the microchip C18 compiler so it's not as useful, but still some very good general info...
  7. man, you guys are great. yet another reason that I can't believe anyone still uses other PIC C compilers... maybe if I get this example project working and show it to some of my friends I can get a few more converts keep up the excellent work! -Evan
  8. Excellent!! thank you I just went and found the related article at the circuit cellar website and purchased it. Too bad it's not a free article so it can't be linked with the example code. But the article and code together make a great example program... just hope it compiles the same now that sourceboost has skyrocketed from version 2.1 to 6.21 since the article But I would suggest that anyone else who's looking to use this as an example program to get started with USB, go buy the article and read it. It's only $1.50, and you can get it at this page: http://www.circuitcellar.c
  9. I am interested in trying to use the USB features available on some of the 18F series PICs... has anyone actually gotten USB working under BoostC? if not, does the compiler support everything that is needed to do so? I would really love to find an example somewhere, because the USB stuff is too complex for me to just try diving in from scratch... The drivers and stuff available from microchip look like they could be a very big help, but I'd really rather not have to switch to the C18 compiler... using BoostC for both 16F and 18F PICs is much more convenient! Even just a simple "hello
  10. Alright, bringing this one back up again with another question. How about being able to use a variable as the index? ie: char a, i; a=01010101b; for(i=0; i<8; i++) { if(a.i) { //do something } } that seems to be the only barrier left to total freedom with this bit accessing scheme... not that it's terribly hard to achieve the same goal by just accessing a specific bit like "a.0" and then using the rotate operator to cycle through... but I thought i'd point it out anyway. of course, if it would produce crazy code overhead to do it at run time then careful planni
  11. if you look in the include files for CC5x, you will see that all the important named bits of the special function registers are declared (mapped) in the include file for each device (since it's different for each) first off, you'd have to use lowercase gie, not uppercase GIE, since GIE is a value set with a #define. secondly, I don't think gie has been declared as a bit in intcon1; in the device header file, intcon1 is declared as a volatile char, and GIE is #defined to a value representing which bit it's in... however I don't believe it's defined anywhere that gie is in intcon1 (at le
  12. I'll second that, you guys have made BoostC a great compiler, with a nice IDE, and continue making it better. keep up the great work and thanks again for adding that bit-accessing scheme
  13. Awesome! while this may seem like a weird question, since I know that using this nomenclature in different situations involves different things in terms of compilation, I'll ask this: what about these, will they work?: bit a; char b; b.3 = a; a = b.3; a = !b.3; b.3 = !b.3; if( b.2 ){} if( b.2 && !b.3 ){} basically, will the nomenclature allow us to use a certain bit of a byte in all the ways we would use a normal bit variable? I was holding out on buying a license until this feature was added, however I got a little impatient and bought one anyway... glad to see that
  14. Take a look at the help menu in SourceBoost. There is an overview of BoostC, including what features are supported, what special functions are defined, etc. Also look in the directory where SourceBoost is installed. There are some example programs in there. And also check out the page of example programs at the picant website: http://picant.com/c2c/examples.html Since you already have experience programming the PIC in assembly, and an understanding of C, you should have no trouble learning to use BoostC
  15. Hey, just curious if this was any closer to being implemented. I was working on some code today, porting it over to BoostC, and I translated this code: (CC5x) value.0=DB0; value.1=DB1; value.2=DB2; value.3=DB3; value.4=DB4; value.5=DB5; value.6=DB6; value.7=DB7; into this: (BoostC) value=DB7; value*=2; value+=DB6; value*=2; value+=DB5; value*=2; value+=DB4; value*=2; value+=DB3; value*=2; value+=DB2; value*=2; value+=DB1; value*=2; value+=DB0; (which, by the way, i haven't tested yet, since oth
  • Create New...