Jump to content

ryeg

EstablishedMember
  • Content Count

    111
  • Joined

  • Last visited

Everything posted by ryeg

  1. Norton SONAR just deleted boostlink_pic18.exe from my machine without asking. What do I do now to get it back???? follow-on: Contacted Norton and they showed me how to unquarantine the file, but the compiler still doesnt build. Attached is and image of the error messages from SB. Rye
  2. Thanks for the comment -- it's got me thinking. I am starting to suspect a hardware problem too. Have a 256K eeprom hooked up and need to check wiring. Chip was OK in 877 circuit. The hangup happens in the i2c_stop routine; ...... volatile bit l_rcen@T_i2c_SSPCON2.i2c_RCEN, l_pen@T_i2c_SSPCON2.i2c_PEN, l_sen@T_i2c_SSPCON2.i2c_SEN; volatile bit l_rsen@T_i2c_SSPCON2.i2c_RSEN, l_acken@T_i2c_SSPCON2.i2c_ACKEN; l_bclif = 0; // initialise the collision flag for this command l_sspif = 0; if (T_MODE & i2c_HW) { // Hardware I2C implementation while (l_acken || l_
  3. I am trying to get an 18F4550 set up for i2c operation and I (foolishly) thought it would be a snap since I have i2c running solid on a 16F877A. I though all I would have to do is set up the template parameters for the 4550 but it still hangs up in the first call to the i2c_init at the i2c_stop function. I have revised the i2c #defines as follows: // template defs -- worked for 16f877 changed to 18f4550 // CHANGES FROM 16F877 #define e_MSSP_PORT PORTB // was PORTC FOR 877 #define e_MSSP_TRIS TRISB // was TRISC FOR 877 #define e_SSPCON1
  4. Got it! Just a matter of spending some time with the manual and a bit of messing around with the hardware. This setup works to give two separate comparators as shown in figure 12-1 of the manual: //comparator setup for two independent comparators using external reference cvrcon = 0x00; // voltage reference off cmcon = 0b00011011; //two independent comparators with outputs // ---- -011 two independent comparators with outputs // ---- x--- dont care // --11 ---- both outputs inverted // 00-- ---- set output polarity trisa = 0b00001111; //set up port configs
  5. I'm sorry, I forgot to put the A on the end. I am using a 16F877A and am using the manual you suggest, but just cant seem to get my arms around the problem. Rye
  6. I am having a problem getting the comparator C2 to work on a 16F877 and I believe that there is some kind of 'trick' I dont remember ...or maybe just not reading manual right. ...or maybe just dumb. I have set all of port A to input except for the comparator output pin with trisa = 1110 1111 I am using two separate comparators with CM2:CM0 = 010 with C2OUT = C1OUT =1 The internal reference is turned off with CVRCON set to 0x00; The external reference is half supply into RA2 Analog input is RA1 e.g. //comparator cvrcon = 0x00; // reference off cmcon =
  7. I am having trouble with V7.0 compiling an old project that was well behaved under V6.x. (I think) Whenever I #include the i2c_driver.h the compiler immediately issues: error: failed to parse input file makefile.i2ctest FAILURE: dont know how to parse the 'release\i2ctest.obj: i2ctest.c i2cddriver_16F877.h "serial.h" ' Here's the gutted code that exhibits the problem; </P> <P style="MARGIN: 0in 0in 0pt" class=MsoNormal> #include <system.h> #include <string.h> #include "i2c_driver_16F877.h" #include "serial.h"</P> <P style="MARGIN: 0in 0in 0pt"
  8. Hi Reynard: Thanks for verifying my thinking on the config1h setup. I had tried that several times before and tried it again.....and it didn't work again. Then it occured to me that it might be a hardware problem -- being a retired hardware engineer that seemed highly unlikely , but....... A detailed look-see of the crystal wiring showed that I didn't have pin 14 connected to the crystal. :angry: duh uh! Because of the apparent complexity of the config registers I was totally focused on them. Your comment somehow got me thinking in another direction. Thanks again. I now hav
  9. I am at the end my rope trying to get an 18F4550 to run with a crystal clock. I dont need the USB/PLL and just can't get the thing to work with the crystal clock. I can get it to work with the internal 8 MHz clock (thanks to RSABEAR) but cant seem to find the correct setup for a 20MHz crystal. My assumption is that the setup is buried somewhere in the config files, but I may be missing something is some of the other registers. Here's what works for my with the internal 8 MHz oscillator: // 8 Mhz Internal Clock #pragma DATA _CONFIG1L, _PLLDIV_1_1L & _CPUDIV_OSC1_PLL2_1L &
  10. After a little Google research and the correct search terms I managed to come up with two really helpful articles about making the transition from 'empty' channel noise (aka random 'data') to a serial data transmission using the little inexpensive "dumb" receivers. Micro Linear and RadioTronix Of course, it you are using the slightly more expensive receivers with RSSI you could probably get away with just that, but both methods might be better than just one. A belt and suspenders (and a good packet protocol) never hurt anybody. Rye
  11. I am driving the USART in a 16F877 from a little $5 garage door opener type of UHF receiver. When there is no transmitted signal the receiver puts out noise and the USART generates junk characters -- which I can accomodate with packet structure and initial transmission of a bunch of characters for the USART to sync up on. Somewhere -- I think it was in this forum -- somebody did some deep thinking and came up with an optimum string of characters to send that will allow the USART to sync quickly, but I can't seem to find it. Anybody got any thoughts on the optimal start up sync string
  12. Here's one for the books that cost me an evening of messing around. I was setting up some registers in a working program and things didn't work like they usually did. It turns out that I had set up the registers using hex rather than binary notation i.e. I was setting the registers to 0x10101010 rather than 0b10101010. The compiler didn't complain. I woke up this morning, took one look and found the problem. It's amazing how we see what we want to see sometimes. Rye
  13. Thanks Ian. That's cleared things up for me and, as you suggest, will probably keep me from getting hung up on the issue in the future. I've been pushing the limit for far too long and needed a little kick. Regards Rye
  14. and the answer is............... cmcon0 I neglected to set cmcon0 <0:2> to make all of the ports into digital i/o ports. It appears as if the chip thought that the comparators were active and that was messing things up. Adding: cmcon0 = 0b00000111; fixed the problem. And yes, the manual clearly points it all out in section 4.1........................................ Live and learn Rye
  15. Thanks to everybody who replied to my last post on this situation. I think I now know how to avoid the problem, but it's still kind of interesting. It appears as if manipulation of port gpio.4 by main( ) has an effect on the gpio.0 which is driven from the interrupt. The .jpg scope image attachment shows the outputs of gpio.4 (bottom), which is driven by main( ), and the output of gpio.0 which is driven by the interrupt. Note that gpio.0 gets clobbered whenever main is driving gpio.4, but the timing seems to remain OK when things come back to 'normal' and main ( ) is running the math
  16. I am trying to get an interrupt driven timer working on a 12F683 and have encountered a perplexing problem. When nothing is going in in main(), the interrupt seems to work, but if I insert anything into main it stops working. In the code below the interrupt generates a 500ms ticks and flashes the LED accordingly. It works fine when there in nothing happening in the main() function, but inserting the code shown makes the interrupt erratic. #include "system.h" #include <stdlib.h> #pragma DATA _CONFIG, _FCMEN_OFF&_IESO_OFF&_MCLRE_OFF&_WDT_OFF&_INTOSCIO #pragm
  17. Thanks Reynard, that what the problem was. My version of the manual (which I thought was current) still has the old file names. It looks like the compiler tried to correct itself since the Link name was changed, but the compile name was still the old one. I'm up and running and getting ready to fire up a PIC Kit 3 after using my beloved Wisp628 and the really nice SourceBoost IDE for years. I am hoping that the debugging capabilities of MPLAB will be helpful now that I am getting better with the PICs. I feel like a traitor leaving the SB IDE, but I am still a strong supporter of the C
  18. I am trying to setup and get MPLAB working with BoostC using the manual instructions and get the error message when I try to build Source Boost Message Compiler executable was renamed from boost.pic16.exe to boostc.pic16.exe. If you see this dialog this means that you still try to use the old compiler name. ? ! Thanks
  19. Until recently I have been writing programs on one machine and doing the programming on another machine -- so I could not take advantage of the one click Compile, Link, Program option provided by the IDE settings>options>tools. Now I am trying to do it all on one machine using my well behaved WISP628 programmer and XWISP software and I am having a problem getting the whole sequence to happen all with one click. My command line is: c:\program files\xwisp\xwisp com7 go When I try it, I get the following: Building... BoostC Optimizing C Compiler Version 6.95 (for PIC16 archi
  20. Thanks for clearing that up for me guys. I had seen the stuff in the manual (yes, I occasionally read the manual) but the examples were a bit obscure in this case. I might suggest that Dave and Pavel consider beefing up the manual on this. Particularly the use of the .h file references. Regards Rye
  21. What do these statment mean? volatile bit adc_go @ ADCON0 . GO; volatile bit adc_on @ ADCON0 . ADON; It's one of those mysteries that I can't seem to find in the books. Rye
  22. Thanks Pavel. As usual you guy are always there to help when I get in a jam and that's what sets you apart from the bigger guys. I wish you continued success. Regards Ryeg
  23. I couldn't find rand.lib in my distribution, but did find rand.pic16.lib and suspect that's what the manual means. When you say that I should "include" the library into my project, I assume that what you mean is that I should add the library file to my list of project files in the IDE -- not #include <rand.pic16.lib>. ...or at least the former seems to compile. Am I correct? Rye To paraphrase Lewis Carroll: My words mean exactly what I want them to mean, no more, no less.
×
×
  • Create New...