Jump to content


New Member
  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About KM1

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This really is a nice little program to confirm operation of the xpress board! I forgot to check the stdio redirect option in for the eusart module in MCC and so was stuck for a couple minutes! One question is with regard to how the uC is programmed. Does the program go into ram on the xpress board? I have not looked in depth yet, but the program seems to go away when the board restarts. Keith
  2. KM1

    Home Offices!

    Like the red-green easy adjust tech
  3. Thank you both for your very helpful suggestions and the time you are putting in to sort out this issue. I will be out of the office today and tomorrow, but will have time at the end of the week to do some more investigating at my end. Keith
  4. I enabled the timer0 interrupt because it appeared to be a requirement to run the rtcount example. I don't understand how the callback would use the interrupt routine without my enabling the interrupts? The eusart is to be used for debugging and the spi code is to allow the use of an ethernet interface module which is the primary goal for this project. I have not done anything with either as I was testing the rtcount module first. I very much like the approach used in the recount example. Keith
  5. The problem is the output is set high but goes low without a command saying to do so. I have zipped the project and have added it to the file download area
  6. KM1


    Version 1.0.0


    Keith's version of the RTCOUNTER example
  7. Hello, I have run into a strange (for me) issue with the rtcounter module as provided by MCC and shown by the example program in the blog area of this site. I am using MPLabX and XC8, both up-to-date versions and I am trying the example on a pic18F47k40 xpress board. The issue is I set an output (RA4) in main after initializing the pic and then enter the while(1) loop where the rtcount_callNextCallback(); is called. The output now is turning on and off. The off duration is typically ~60u seconds, and on time can be varied with changes to the timer interrupt settings (I use a 1mS timer0 in 16 bit mode) and the number sent to the callback. Approximately every 3mS, the off time increases such that that cycle (only) is approx 50% duty cycle. Turning the output on or off in the callback routine has no effect - I initially wanted to toggle on and off at a speed visible to the eye. Commenting out the callback in the main loop stops the output from going low. I have checked errata and used the data sheet to confirm register settings, I tried moving the current-limited LED from RA4 to RA2, and I have studied the example program looking for obvious differences that may cause this behaviour. I would appreciate thoughts and/or suggestions. Keith
  8. KM1

    Melbourne Weather

    After a very mild winter to date, our first cold snap has started here in British Columbia, Canada. It is -17.5C with gusty winds and a wind chill of -31 this morning.
  9. I like the image of the book alongside the feedback from someone who has found the book useful. I added several of these books to my "to get" list. Are their costs to the forum owners to run this page? Would it be worth looking at Amazon affiliation (for example)? I would certainly consider purchasing a product if I knew there was a benefit to the forum itself. Keith
  10. Perhaps leave the main list alone and post a reply for each book title and paragraph?
  11. Thank you Orunmila and N9WXU. I appreciate you taking the time to answer my questions. Keith
  12. My main goals with this project: replace the original asm code with maintainable C - I am using MPlab X and the v2 c compiler. I have the asm source code and will be working with it, but it is the product of many years of tweaking by an (older and very smart) engineer now retired. simplify the current board circuitry - one example is to eliminate an external AD converter and use the built in. I believe there is no need for special features provided by the existing converter (Texas Instruments TLC1543, 10-bit, serial output), I believe the converter has been in the design since before on-board AD was commonly available (mid to late 90's)? I think I can reduce my overall BOM cost by approximately 15-20% The PIC's main job is to read 5 channels of AD, perform some relatively simple math, provide data to the user via LEDs and 7 segment displays, and store some data for calculations. There is a serial interface to an optional device, calibration data stored in EEPROM, and a simple user interface. Longer term, I hope to add wireless connectivity, an improved UI, and possibly combine the optional device with this one to market a combination unit which may have appeal. I have looked at the 18fxxk42 family and will be getting some to try in addition to the 18877s I have just received. Keith
  13. Hello, This forum is very refreshing - good content and respectful users! I have a good amount of experience with PIC products, but not full-time day in and day out. My question is regarding the pros and cons of using the advanced versions of the PIC16f family vs the 18f family. I really like the analog peripherals amongst other features and I wonder what others think for new project development? For example, I am looking at a redesign of a product that currently has been using the PIC16f887 for the last 5 years. I am looking at the PIC16f18877 as a replacement unit and have spent some time wading through the 600+(!) page data sheet looking for opportunities to simplify the original circuit design and take advantage of some of these features. I am not looking for a way to avoid reading the data sheet, just some other points of view. Keith
  • Create New...