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 are all "floaties" of variable width that open overlaying one another, differently for each file. Best Regards Peter L
  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 added. After nominating the SourceBoost folder as the "Base Directory" the types "SourceBoost C Compiler for PIC12 and PIC16" and "SourceBoost C Compiler for PIC18" are both listed as available in the "Type" dropdown box. OK, so I selected the PIC12 & 16 type and clicked OK, but when I restart and try to add the PIC18 type, the message "Base directory is currently in use by another toolchain" appears and the "OK button is greyed out. Trying it both ways, only one of the two types is allowed, unlike the screengrab in Pavel's PDF, which clearly shows both types resident in the same base directory. I found I could only get both types included if I duplicated the contents of the SourceBoost folder into another folder of a different name and used a different base directory for each. Don't think that's going to work! Tried uninstall/reinstall etc .. no joy. Apart from that, settling on one toolchain (PIC18) and loading a single port LED flasher of a few lines of working 18F452 BoostC code into the MPLABX editor, the thing raises errors saying it doesn't know anything about "tris" and "port". (red underline - unknown ...) MPLABX doesn't seem particularly intuitive ... or is it just me? Peter L
  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 of luck .. we've all been there!
  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 I don't know what the timing accuracy is like on the BoostC delays. Hopefully things will improve when I transfer to a PCB. I haven't found any information on port input impedances for the 18F452 and 4520 in the data sheets for these chips. The input is coming from the output pin of a LM311 comparator that is driving the oscillator LC "tank". The waveform is triangular with a swing from 0-4V. There is a 6.8K resistor in the line to the PIC. (This is an old much-built circuit, many versions on the web) Would you expect different impedances to pull or damp the oscillator to different degrees, changing the frequency, or just cause the counter to read higher on the waveform and skip counts? Best Regards PeterJL
  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 65536, and add the long and the short to give a frequency value in Hz. OK so far. The circuit works fine on a breadboard, values seem reproduceable and roughly match those I see on the oscilloscope. This is reading an LC oscillator running at around 650KHz. With a wire connected to Rc0 (Timer1 pin) on the 18F452, I get 0Hz when it's grounded, and 50Hz (presumably some mains hum) when it's floating. (Must add some more decoupling I guess). I was pleased to find that when I connect the wire to the OSC1 pin, between the 20MHz crystal and the capacitor, I get a count of 20.142MHz. Now, I'd like to use a 18F4520 for a couple of reasons. The 18F452 is obsolete I'm told, plus I'd like to use the comparator and voltage ladder that's on the 4520 to build up a all-in-one meter that measures frequency, Inductance and capacitance. The fact that the 4520 can run at 40MHz should help as well. At last ... to the point. When I take the exact same code that I have been running on the 18F452 and compile it for the 18F4520 (sure, configuration is different, but not much), the 18F4520 produces consistently lower counts from the same pair of oscillator sources. For instance - the 452 reads 648.691KHz and 20.142Mhz, while the same code on the 4520 reads 589.906KHz and 19.570Mhz for the same 2 sources. That's 3% off at high speed and 10% off at low speed. How can the 4520 be missing counts that the 452 detects under the same conditions? I haven't been able to even form a wild hypothesis that I can test. I'd expect the 4520 to have faster silicon, being the replacement for the 452, and so would have expected the results to be the other way. Suggestions anyone?
  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 oscillator can be replaced with the comparator on the 16F628. The unit has some limitations in the range of values it can measure because the frequency counter routine runs out of steam when it fills the 24-bit variables they use. (Recall that we have 32-bit longs in BoostC!!) I have a couple of 18F4520's (40-pin) burning a hole in my pocket and am fiddling with this design at present with the idea of using one of these or the smaller 25-pin 18F2520 version. The 4520 does 40MHz with lots of memory and it's own comparator, voltage reference ladder and counters. I think that it would be relatively trivial to add frequency measurement as well, making it a multi-purpose and quite useful instrument (You could check that unmarked crystal that you snipped out of the TV you junked, and maybe use it on your next Pic project).
  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, then use other code to deal with the flagged conditions. Does a compiler warning that indicates that I have written rubbishy amateurish code consititute a limitation of the compiler, or of me? Regards PeterJL
  • Create New...