Jump to content

John P

EstablishedMember
  • Content Count

    17
  • Joined

  • Last visited

Everything posted by John P

  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
  15. OK, a delay as I don't have full-time access to both the computers I used. The first one, which I didn't mention in detail, is an HP Pavilion with 64MB of RAM, about 6 years old and still running Windows 98. The IC_Test program took 2 minutes and 45 seconds on this machine. I thought well, maybe this is what I ought to expect with this relatively old machine, so I tried again with the other computer. It's a no-name model with Win2000 Pro and 425MB of RAM (but only 111KB "available") and I just can't find out what the processor speed is. "X86 Family 6 Model 6 Stepping 0" if that helps. Agai
  16. I downloaded the trial software and tried to compile the examples that came with it. The file LCD.C wouldn't run at all because it was too big for the trial version's capability. The file IC2_Test.c compiled, but it took about 2 minutes and 30 seconds to produce the word "Successful" on the screen. In fact I stopped the program a couple of times because I thought it had hung up, before I finally realized it was actually still alive. I've tried this on 2 different computers and they were about the same, so I'm fairly confident that it wasn't some kind of defect in one machine. That IC2_
×
×
  • Create New...