Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About PeterJL

  • Rank
  1. Hi acroty .. I'd expect that your UART settings are OK if your single-character Tx works OK. While it's true that a string should be null terminated, try this anyway.... it works for me on the 18F24K22 (ps: txreg and txsta are both duplicate-mapped to the txreg1 and txsta1 addresses) Best of luck Peter L
  2. Pavel, Fixed!.. The problem certainly wasn't SourceBoost, it wasn't even Microsoft (this time), it was due me not looking carefully at what was on the screen. When one selects either the "Tiled" or "Cascaded" option from SB the screen drops into the "Restore Down" mode where both the code and browser windows float, overlap and need to be resized on re-opening the project. All that was necessary of course, was to maximize the window. ... Dumb huh? Best Regards Peter L
  3. Hi Pavel, Thanks for your attention. The problem is reproduceable, I installed SourceBoost 7.05.1 on my PC, it showed the same effect as on the original install on the laptop. However, a system restore back to a week ago, plus full uninstall and delete of the remnant SourceBoost folders followed by a new install seems to have fixed it. It started when I flipped between cascaded and tiled mode under the SB Window option. Most likely suspect is the most recent Microsoft update for Windows 7 64-bit downloaded this month, probably KB2718704. The screenshot is hopefully attached - the windows
  4. I'm finding the "new look and feel" a bit irritating to work with. For years I've worked with an edit window and the workspace panel window open and docked adjacent to each other. I find now that the edit window automatically adjusts to the maximum line length present in the code, but not the maximum screen height available. ... So now I find I have to set the window sizes and positions every time I reload a project. Is there any way for a grumpy old man to configure and save the default window sizes and positions ? Kindest Regards Peter L
  5. Lots of gripes about MPLAB X in some areas on the Microchip forum. I'd guess that the folks at Microchip are rather preoccupied at the moment. Consensus opinion there seems to be that the move from the "mature" version 8 written in C and C++, to X using Netbeans was a mistake, and that MPLAB X was rushed into release too soon. Peter L
  6. Go for it! Once you get it working - check out the circuit in Silicon Chip magazine February 2005. I kept the op-amp signal amplifier side of it and modified the rest of it and wrote BoostC for a PIC 18F4520 to do both pulse rate and 2-line realtime ECG to a laptop via USB - works well. Now just waiting for my coronary!
  7. Hi Chuck, Congratulations, sounds like you're doing a lot better than me. Gave up on MPLAB 5 years ago, and have since (more or less happily) using BoostC standalone without MPLAB integration, I thought I'd like to be able to do in-circuit debugging using the PicKit3. So .. paid up and upgraded to SB 7.05.1 and downloaded MPLAB X 1.1, but it seems to me so far that MPLAB is just as plug-ugly as it was then, (but then I guess, so am I). Pavel's carefully prepared PDF instructions for MPLABX integration (in the installation file set) worked fine right up to where the "toolchains" are a
  8. Hi Noob - Nope, can't do it like that. "Float" means just that - you are detecting the stray voltage on the pin drifting up and down. You have to either ground it and pull it high with the button or vice-versa. I guess what your schematic didn't show was that all the portB pins can have a "weak pullup" applied in software to all those pins on portB that are set as inputs. Do that by clearing RBPU in the option register (ie: "option.RBPU=0") (See p34 of the Microchip datasheet for the for the 16F628A) Then you can detect your grounded button by either polling or interrupt as you like. Best
  9. Hi Carlos Thanks for your comments, most helpful. Although .. where I thought I had just one problem, in fact I had two!. I had no idea how what sort of accuracy to expect from a 20MHz crystal, the one in question was marked "SIWARD 20.000". Of course, you are correct, I had left a software error in the LCD print routine that converts the raw count to MHz. The 100mS count for both of 2 different 20MHz crystals converts to 20.042730 MHz, 43KHz off, still more than the 10-15KHz you mention. The circuit is running on a plastic prototyping "breadboard", so lots of stray capacitance about, and
  10. I have been playing with some straightforward BoostC code to measure frequencies of oscillators, and have struck a problem that I can't understand. Using an 18F452, I enable Timer1 as a counter for 1 second (delay_s(1)). Each time the high byte rolls over to 0, the ISR kicks a 32-bit Rollover variable by 1. At the end of the 1-second delay I disable the clock and interrupts and read the Timer1 Hi and Lo byte registers (using the one-gulp RD16 method - ie. read lo then hi, write hi then lo). I use MakeShort() to combine the high and low bytes into a short, multiply the long rollover count by
  11. Here's one that I haven't built personally, but lots of others have. See this site .. http://electronics-diy.com/lc_meter.php ... or else Google for "LC meter". An LC meter measures values of inductors (coils/chokes - in microHenries) and capacitance (of capacitors). Useful if you are into electronics or ham radio, or just want to check some part values. This circuit has been around for years, and is still being sold in kit form by various suppliers. Most are still using a 16F84A, and most recent talk is about upgrading to a 16F628 (Wow!) ... so that the LM311 comparator that drives the
  12. Pls remove the limitation asap. I will not recommend to use BoostC if the limitation still there. Dave Let's not get too excited here. One can pay out A$1000 for HiTech PICC and try calling the same function from inside and outside an interrupt. Same limitation, similar error message. The local C gods (ie. C acquired with university degree rather than self-taught) shake their heads when they see the rubbish code I have managed to get working inside an ISR. I'm told that the "correct" approach is to modify flags, clear the interrupt and get the hell out of it as soon as possible,
  • Create New...