Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About mikew

  • Rank
  1. Oh, silly me!! The clue is in the message "inline". Doh! "Problem" solved...
  2. I have never used the PIC "sleep" instruction until now. But in BoostC Ver. 6.97 I get the error message 'can't get address of inline function sleep' I'm at a loss to understand what this means. Hopefully someone may be able to point me in the direction of an answer?
  3. Just wondered if there is any method by which PC real time may be imported into BoostC?
  4. Hi, Some delay in responding to your thoughts, and your mention of a virus scan is not far off the mark, but in the wrong direction! To cut a long story short, it turned out that it was my all-singing-all-dancing virus checker that was the culprit. The penny dropped when I attempted to re-install my version 6.97 toolchain; this was stopped because it declared it contained a trojan!! Ultimately, after a lot of faffing about, it simply required certain compiler files etc. to be excluded from any scanning. The culprit is F-Secure Safe, which I have been using for years; they obviousl
  5. Hi, Thanks for the response. The Boost C I have been using for years is Version 6.97 - I have never had the need to upgrade to Version 7.xx. So I can't think that this has anything to do with this sudden "relapse"!! Since I posted this, I've discovered that the compiler now actually does nothing!! Clicking on 'OK' in the message, it continues without any warnings, declares 'Success' and 'Done' but has not parsed the source file and has not produced a new .hex file. I'm thinking that a fresh install might cure the problem, but not sure if this is a bad idea without having
  6. I have been using Sourceboost C Version 6.97 for some time, without any problems. Today I re-compiled a file and obtained the following odd message:- Compiler executable was renamed from boostc.pic18.exe to boostc_pic18.exe If you see this dialog this means that you still try to use the old compiler name. Nothing has been changed in the installation in any way, and I am at a loss to understand what this error means. After choosing ‘OK’ the compile/link etc. process seemed to continue correctly. I am at a loss as to why this "error" message
  7. Hi, Thanks for the response. The webinar is interesting, but doesn't really give any clues as to my problem. I apologise for getting the PIC wrong - it should, of course, be 12F683. I've checked all the usual suspects, CONFIG, ANSEL, ADCON0 etc, but nothing changes the effect. I haven't looked to see if the effect is present on any other GPIO's; for my intended application these were the only two of interest. In the meantime I've solved the 'problem' by changing to a 12F615 - very similar but I wanted to use the EEPROM in the '683.
  8. Hi, I'm hoping someone with more knowledge and experience may be able to solve a riddle? I have discovered (the hard way!) a peculiar behaviour of this pic. Simply put, GPIO4 controls the operation of GPIO1. For example, if both are set high, when GPIO4 is then set low GPIO1 follows about 500ns ( 1 instruction time at 8MHz? ) later. I've looked at the code, SourceBoost C and the listing file and they are correct. I've scoured the Microchip documents and trawled the internet, but found nothing that I might have missed. At first I firmly believed it was the two chips I had that were just f
  9. Many thanks for your assistance, which has allowed me to solve the problem. However, having now successfully created the hex file I have encountered another problem! I have a TL866CS programmer that I have used without any problems for a variety of different PIC's. But with the 18F2520 a few bytes fail to program properly; programming followed by automatic verification succeeds for the code, but fails for the CONFIG section, and then performing another code verification fails. The failed bytes are always on a "page" boundary, i.e. 0x100, 0x200, 0x300 etc. I am trying to work out if this is
  10. I have successfully used the floating point library for PIC16F devices and wished to try an 18F2520 device. However, I discover that the compiler ( I have Version 6.97) flags an error that " incompatible .obj or .lib" found. The only information in the Float PDF is that the float.pic18.lib covers the 18F devices, but nowhere can I find a list of specific types that are covered. I wonder if anyone with more experience can provide any advice and information in order that I may now choose a PIC18F device that is supported by the floating point library.
  11. I have encountered a problem using the assembler within BoostC. I am trying to translate a Microchip assembler program to C, but wish to leave some parts as assembler, using the asm{} feature. This works fine, apart from one instruction, which BoostC flags as "unknown identifier" The identifier is a label in the assembly code, referencing a code memory address; this is then used with the movlw instruction within the same section, thus: TRFReset: ...... ...... movlw TRFReset and it is this last instruction that gives the error. I'm assuming the syntax is correct, and it is
  12. I may be hi-jacking this thread, apologies if so. My attempts to create a working program in Boost C for the 16F886 have met with dismal failure. I'm hoping that someone more versed in the use of this PIC may be able to help. I'm quite familiar with the 16F876, but my problem seems to be in configuring the '886 clock source, as well as the other features that are not present on the '876. I wish to use the internal clock running at 1MHz and have used what seem to be correct values in OSCCON, CONFIG1 and CONFIG2, but the result is a seemingly 'dead' PIC. Incidentally, I know it's not fau
  13. Hi, This is really a question for future reference. I have often used the 16F876 for projects, but it's now obsolete. I have a friend who has used a PICAXE, and that has a 16F886. So, I thought, that's probably one to try. However, I discover that neither of my programmers support this PIC, and my minimal research suggests that it's programming algorithm is somehow different from the rest. So, my question is, what is peculiar about this PIC? How is the programming different? And how might I modify a programmer to support it? BTW, I've been on to the makers of one of my programmers that
  14. Hi, Not directly related according to your description, but I had a similar problem with a PIC project. It had a 16F877a in a TQFP fairly close (~5cms) to a couple of relays switching 230VAC. Mostly it worked fine, but occasionally it was clear the code had gone berserk! I eventually discovered that an earthed aluminium screening can cured the problem, presumable by protecting the PIC from EMI produced by arcing at the relay contacts. You may consider doing the same, as you may have HF EMI emanating from any inductors or transformers?
  15. Hi, I've recently been attempting to use a 16F876A for I2C comms with an external EEPROM. I have used the examples posted in the links from this site by R S A Bear, for which I am much obliged. I've reduced the code to cut out the comms with the second PIC, leaving the EEPROM read and write routines. This example also uses the i2c_driver.h file in the boostc distribution. However, I can't get my code to work properly, and I wonder if anyone else has used these examples, or has some ideas to point me in the right direction? I find that the eeprom write function is almost correct; by
  • Create New...