Jump to content

John P

EstablishedMember
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About John P

  • Rank
    Newbrie
  1. I use a Lenovo B575 which cost a magnificent $300 in 2011, but last year I spent $200 to replace the motherboard (dubious economy there, but I didn't want the hassle of shifting everything over to a new machine--the hard drive was OK, so no issues concerning lost data). Boostc runs way slower than other compilers, and I'm just used to it being the way it is. Most of my programs are pretty small, anyway. By comparison, MikroC is almost instantaneous. I don't think it has much to do with the machine you run it on.
  2. It does say: @ 912: MESSAGE: "Warning: ICD2 Reserved ROM address range:0x1F00-0x1FFF (use linker -rt option)" I don't use ICD2, so I don't know how to interpret this. Is it a likely cause of the program not compiling? You could try removing the #include line temporarily, and see if it compiles OK then.
  3. It isn't necessary to "debounce" a switch at all, as long as you don't read it too frequently or allow it to create an interrupt. You just have to make sure that you poll the switch input bit(s) at some interval that's longer than the bounce time. If you don't need extremely fast response, 50msec is pretty generous. So you set up a timer to give a repeated overflow, which you can respond to either in an interrupt, if you already have one running at some fixed rate, or if your main() routine features an endless loop, you can just poll the overflow flag there, as long as you clear it once it's f
  4. I need to make an addition to the message I posted last month. Yes, you can subsitute your own code for the Boostc interrupt function. But if you do, you can't do it the way I showed. Where I failed was using local variables in my function, and when I thought about it (prompted by mysterious bugs) I realized that it had to be a mistake. The issue is that to the compiler, that block of code is just a function called from main(), and its local variables only have to be selected so as not to interfere with variables in use by main(). But in fact it's an interrupt which can be executed from anywhe
  5. Just dealing with that last question, yes it's possible to do this and I just figured it out for a program I've been working on. What you do is to avoid telling the compiler that you have an interrupt, but locate your code at address 0x0004. If interrupts are enabled, we know that the PIC jumps to address 4, so anything that you've placed there will be executed. Here's a section of my program that contains the start of the interrupt, and you can see I've commented out the original "interrupt" designation and replaced it with my own function name called "rupt()". Note that you do have to call "
  6. OK, thank you for taking an interest. Here is the routine in which I'm having the problem, and a 1-line main() function which calls this routine and does nothing else. Please understand that this version is made to compile but not run! It's for the PIC16F690 and I have version 7.20 of the compiler. What I'm seeing is first, if the asm{} construction isn't used with my list of GOTOs, they don't compile. If I do use asm{}, it compiles but it's very inefficient in terms of the amount of code produced, and time to execute. What I think is wrong is that the number of sequences of BCF 0x3, 0x5
  7. I'm going to call this a bug, although it doesn't exactly cause failure. BoostC disdains to create a Switch-Case setup by manipulating the program counter. Instead it forces a long list of compare operations, which gets time-consuming if one of the last cases tests true. So I tried to write my own version, like this (I'm only showing the first 3 cases): i = packet_out_count++; pcl += i; asm { // Jump table must fit within 256 byte block of addresses goto POC0; goto POC1; goto POC2; goto POC3; goto POC4; goto POC5; goto POC6; goto POC7; goto POC8;
  8. Thanks for the reply, Jorge--I don't think I'd ever have noticed that little switch. I could try writing some experimental code and see if it handles it differently. Then I'd have to see if my Pickit2 programmer will work with the processor; it's not on the list of supported parts. Edited to say that yes, the PicKit2 will do this if you have the right file of parts for it.
  9. I haven't tried this, but maybe someone here knows. The PIC16F1824/1828 has some added features compared to most other 16F parts. It has 2 File Select Registers (FSR, location 0x4) and it can do indexed jumps, not just skip a single line, and various other new things. There are added instructions (49 available, versus 35) to control the new features. Does BoostC produce code for optimum use of the new hardware and software possibilities, or will it just treat the 16f1824/16F1228 like an older equivalent?
  10. That last suggestion shows some lack of knowledge about how code for microcontrollers is used. Here we are on a discussion forum about a compiler; I don't object to compilers! The advantages to using one are too obvious to be worth discussing. On the other hand, there are times when part (just part!) of one's code needs to run at the highest speed, or needs to run at some speed that's predictable on the basis of how the program was written, on a finer scale than you could ever get simply using an interrupt. That's when the user would consider using a brief section of assembly, and then it'
  11. I wrote some of my program in assembly for the reason that people usually do--to get completely optimized code where I'd know exactly how long everything will take. So here's a line of C code that I rewrote into assembly: MOVLW 0x40 // portb = 0b01000000; MOVWF _portb Now when I compile/assemble the program, I find that the compiler insists on setting the register bank to zero. Doing this adds two extra instructions! And the wasted lines are added again and again, just in case I sneaked a bank change in when the compiler wasn't looking. Like this, in the "View D
  12. I'll stick with the assembly language block then. And thanks for the reminder about fixing the function address. That's definitely needed with the way I've written this.
  13. Hi Dave. Thanks for the prompt response. I did download 7.11, and I was all set to report back that it didn't make any difference. But it's more interesting than that. It still won't compile my block of GOTO's. But then I tried a workaround that failed with the previous version (I have 7.05). And that seems likely to work. What I did was take some of the jump table and put it in an asm{} block, like this: bit_set(porta, 1); // A flag for the scope, to see how long this takes pclath = 1; pcl += bitc; // Computed GOTO: jump 0-179 lines ahead // NOTE! This jump table must not sp
  14. I'm trying to convert a program from another compiler, and I have got it to compile under BoostC. But the program includes a jump table which is entered after the PCL is changed--a computed GOTO in other words. What I'm finding is that the compiler simply generates no code for any of the GOTO statements, then it resumes at the next address after the last GOTO. Here are the last few lines before the table and the first few lines of the table: bit_set(porta, 1); // A flag for the scope, to see how long this takes pclath = 1; pcl += bitc; // Computed GOTO: jump 0-179 lines ahe
×
×
  • Create New...