Jump to content

mikew

EstablishedMember
  • Content Count

    61
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mikew

  • Rank
    Regular
  1. 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 obviously snook in an update which then caused me to waste 2 days going round in circles. Grrrrrrrrr! Again, thanks for taking the time and trouble to respond. (I never got anything from Sourceboost support) Mikew
  2. 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 some idea why it has suddenly happened for no apparent reason.
  3. 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 has suddenly appeared for no obvious reason. In this case I can't blame Windows 10 updates!! Perhaps someone more knowledgable of Boost C can shed some light?
  4. 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.
  5. 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 faulty, but two more from a different source behave exactly the same. Any ideas, anyone?
  6. 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 a code problem, ( very unlikely, I think ) or a programmer problem, (most likely?) or a PIC problem ( possible, until I get more devices for comparison.) Any light the experts can shed on this could save me a lot of wasted time, especially if anyone has experience of this programmer, which seems to be well made and a popular gadget.
  7. 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.
  8. 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 the BoostC assembler that is problematic? Although I'm not convinced that as given it is correct. 'W' is an 8-bit register and the full address referenced by the label is 13 bits, so am I missing something here? Incidentally, the address is used to modify the program counter for entry into a jump table. Any suggestions would be most welcome.
  9. 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 faulty as a hex file I found on another project page for the '886 works fine. I even tried using the values in this code, but no different result. I have this nagging suspicion that there is something about this PIC that I'm missing, but despite studying the data sheet from start to finish it has eluded me! Any suggestions welcome... M.
  10. 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 I think would only require a firmware update, only to be informed that "no updates are planned in the foreseeable future", but no other information forthcoming. Any suggestions? M.
  11. 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?
  12. 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 looking at the eeprom contents in a separate eeprom programmer the first two bytes written are always incorrect - the rest is fine. Which is a puzzle! I wondered if the SCL speed was too high at 100kHZ and tried reducing it to 50kHz, but this makes no difference. The eeprom read function doesn't work at all, that is, totally corrupted data is returned. However, the returned data is always the same, which again is a puzzle. I am outputting the data to an LCD, but also viewing the SDA and SCL on a DSO and the waveforms look OK. At this stage I'm loathe to drag out the logic-state analyser, and I'm not convinced it would shed any light on my problem. As this is my first encounter with I2C I get this funny feeling that I'm missing something really simple! Regards, MikeW
  13. Thanks for the replies all of you, despite not having ESP!! After spending (wasting?) a further 20 mins scrutinising the code I decided the best way was to back-track and start over. Hey presto - problem solved, or at least eliminated. However, I'm still not sure what the error message means; perhaps the file had become corrupted in some way and hence was spurious? Regards, Mike W
  14. Please can anyone help with this problem? I have a program which I have been modifying and which has now produced an error message: Parameter buffer overflow about 20 times, even for comment lines. ending with: Fatal unexpected end of file Obviously I have made a silly mistake, but since the first set of error messages are meaningless to me I don't really know where to start looking! I have looked carefully at every line and cannot see any semantic errors. Hopefully someone can point me in the right direction rather than post the whole source code here, although it's not very big. Thanks.
  15. Thanks, Pavel. Is this a new feature of 6.92, since it's the first time the message has appeared? But it explains the reason, as I have indeed used the % operator in both main and interrupt. Is there a (simple) way to eliminate it from the ISR? Or may I ignore the warning and hope for the best? Regards, Mike W
×
×
  • Create New...