Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About mikew

  • Rank
  1. 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.
  2. 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?
  3. 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.
  4. 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.
  5. 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.
  6. 16F886 Programmer

    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.
  7. 16F886 Programmer

    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.
  8. Mind Boggling Emi Problem With Pic

    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?
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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 it emanates from (for me) unwanted functionality in the i2c_driver.h that I have taken from the BoostC distribution without a full inspection of its content. It works on its own in a separate program, where, incidentally I sussed out what was missing to make it work before. I now have some 24FC1025 eeproms that expect a 16bit address in two bytes. I'll now go and wade through the .lst file and find out what __rem_8_8 is doing!! Regards, Mike W
  14. 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 is more conversant with BoostC (and a better programmer) can shed some light on what the serious warning means? The function __rem_8_8 presumably comes from either the I2C header or the floating point library, both of which my program uses. My particular problem is not understanding the term 'asynchronous thread' in the context of BoostC. Please, help!! Mike W
  15. 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 feel I have the time. Again many thanks for your help. Mike W