Jump to content

izakdude

EstablishedMember
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

0 Neutral

About izakdude

  • Rank
    Regular
  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 good to know i'm not crazy regarding the program space issue, too bad there's no way to implement it in BoostC (in CC5x, there was a compiler function nop2(); that would just put in a 'goto $+1' for delay routines), but it's not a huge deal, after all, I'm not exactly running out of program space in most of my PIC projects.
  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 that I can use, or does most everything in the 'asm' brackets get copied verbatim into the .asm file? (like, can i take any normal assembly routine that I have written and use it inline, provided it doesn't rely on any MPLAB macros or anything, or are we limited to only some assembly functions?)
  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.com/magazine/178toc.htm
  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 world" app like setting the PIC up as a HID and toggling an LED or something would do me (and anyone else who's interested in USB) a world of good. The HID mouse emulator example program that microchip provides for the C18 compiler is an ideal example program, but I think I'd be in way over my head if I tried porting it to BoostC, since I don't have any real understanding of how it works, I'd be completely lost if I had to try to debug it if my ported version didn't work immediately.
  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 planning and use of rotates would be preferable anyway.
  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 least as far as the compiler knows) you should be able to just add the declarations (at least for the bits of interest) to the appropriate device header file... such as: bit gie @ intcon1.GIE; or #define gie intcon1.GIE or, of course, you could add the line at the top of your program instead. It would be kind of nice to see those declarations in the include files, however I know I sure wouldn't want to be the guy who has to type in hundreds of declarations to each of the over 300 device include files, so personally I don't hold it against them for not adding it, as I'm sure they've got better things to work on
  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 it's still on the way oh, and jtribbet... is that you justin? from UMaine?
  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 other compile errors are preventing me from testing it on the actual PIC circuit, but it seems to me that it should at least work) The first one sure looks cleaner. oh, and feel free to point out any better methods for implementing that better than the way I did it... anyway, I'm keeping my fingers crossed for this addition
×
×
  • Create New...