Jump to content

mikew

EstablishedMember
  • Content Count

    64
  • Joined

  • Last visited

Everything posted by mikew

  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
  16. 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
  17. 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
  18. 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
  19. Thanks for your speedy response! That's what is puzzling me; my program does use interrupts, but only from Timer1 to generate a time-of-day output. The sudden appearance of 'threads' seems inappropriate and unnecessary. My program is very straightforward, and I would have no idea how to incorporate threads into an embedded PIC program - I'm not using any OS. It seems to me that there is some sort of conflict between the FP routines (for example) and the I2C functions, since the I2C was the last thing I added to the program. I suspect that the message is spurious, in the sense that
  20. I have recently encountered the following message from Boostlink 6.92: Building CASM file Serious Warning: Possible sw stack corruption, function '__rem_8_8' called by more than one asynchronous thread (main/Task, interrupt, interrupt low) Memory Usage Report =================== RAM available:368 bytes, used:258 bytes (70.2%), free:110 bytes (29.8%), Heap size:110 bytes, Heap max single alloc:95 bytes ROM available:8192 words, used:7259 words (88.7%), free:933 words (11.3%) (I have edited out most of the other messages, which I can understand!) Perhaps someone who i
  21. Thanks for your assistance, Reynard. One assumption I have made is that all EEPROM's are the same, but different! The ones I have been using don't seem to have a page mode function, but a write protect on pin 7. I'd guess that the example code is intended for the multibyte mode; I didn't include all the code as it's already in the examples on the Sourceboost site. I've found another example that is much simpler, and obviously uses single byte read/writes with the I2C routines included, and which I can understand!! I'll pursue this for the moment and come back to the other one when I fe
  22. Thanks Reynard. To be honest, I don't know!! I've simply taken the example code and tried to use it to understand how I2C works. For information, the read and write routines are as below:- --------------------------------------------------------------------------------code---------------------------------------- //////////////////////////////////////////////////////////////////////////// // I2C Device constants //////////////////////////////////////////////////////////////////////////// // define External I2C slave (Hardware) addresses #define xee_slave 0xA0 // Base address of the
  23. As part of my voyage of discovery I decided it would be nice to add I2C to my latest project! I've started out by experimenting with the example code from the forum - which all works as I guess it should. But I'm hoping someone far more conversant with I2C can help me with what should be a simple problem - but I just don't get it, and the EEPROM data sheets don't shed any light. I wish to read/write to a 24C04 EEPROM using a 16F876 as master; the I2C routines in the example program read/write to the bottom 16 bytes OK, but so far I've not discovered how to access the rest of the EEPROM.
  24. Can any expert on PICs shed some light on this problem? I'm using a 16F877A as a central heating controller, with both Timer0 and Timer1 generating interrupts. The processor clock is 20MHz, and the desired combination of accuracy and divider ratio constraints leads to T0 interrupting 90 times a second and T1 20 times a second. The program will run fine for days, then 'randomly' fail. T1 is used to generate time of day, ie hours:minutes:seconds and the failure is apparent when the 'clock' stops. I have not investigated what limitations the PIC or BoostC places on interrupt stack depth, nor i
×
×
  • Create New...