Jump to content

trossin

Moderator
  • Content Count

    243
  • Joined

  • Last visited

Posts posted by trossin


  1. My suggestion is to turn off some of the plugins and see if that works. I turn them off by renaming them from .dll to .dlx. Having developed a few plugins, I have found that a goof here or there will make SourceBoost crash sometimes here and sometimes there. If I disabled a few of the plugins, the problem would go away for a bit until I found the real problem in my code. It is a rare event so I have no real science to back it up but thought it might be worth a try.


  2. Thanks for the heads up on the API change. I took a brief look at the differences and found:

     

    1. Plugin.def: Added plgNumber which changed all the following values
    2. PluginAPI.h changed version from 200 to 300 and changed the functions to accept HWND parent
    3. PluginApp.h: Added PLUGIN_INSTANCE_NUM
    4. PluginData.cpp: Added another pin (m_pin2) to the example
    5. PluginView.cpp: Added Visual C++ code to handle a new button (looks like to zero voltage)
    6. PluginView.h: defined new functions for the new button
    7. plugin.rc: Made the form taller and added a push button
    8. Pluginhookup.cpp: pushing throught the parent window on all the function calls
    9. resource.h: Added the button

     

    So, it looks easy to port to version 7. Just copy over the version 7 plugin.def, PluginAPI.h PluginApp.h and Pluginhookup.cpp and it should compile without problem as I never modified code in these files. The changes made to the PluginData and PluginView were just to enhance the example (these are the files that users put their value added). All the other files changed but just to update the copyright date to 2010 so I can do that as well.

     

    I'm glad I don't have to recreate and insert the value added into the template project.

     

    The big bummer is that version 7 API plugins cause SourceBoost V6 to crash and burn(reading memory from bad location). I turned off some of the other plugins (changed names from dll to dlx) and now it runs but says the plugin version 3.00 is incompatable. I turned the plugins on again one by one (changed dlx to dll) and it no longer crashes. Head scatcher there.

     

    So this means that the plugin developers will need to provide and maintain two versions of their plugins until everyone has moved up to SourceBoost V7. I at least hope that SourceBoost V7 will load V6 plugins as some folks may not be able to upgrade if they can't use their favorite plugins.

     

    It would be lovely if the code inside SourceBoost V6.98 could be upgraded to support the V3.00 plugin API but limit the number of plugin instances to 1 (so folks have another reason to upgrade) so the plugin developers will only need to support one version. Just a wish not a need.

     

    My biggest future need is for SourceBoost to work with MPASM source projects (nudge nudge).

     

    Thanks for making the plugin API available. This is a huge value added to the complier environment which allows code to be developed and the hardware optimized before flashing memory and laying out boards (or solder wire).


  3. JBr,

     

    Does BoostC++ expect extended mode instructions to be enabled in the device config?
    No they need to be disabled

     

    Regards

    Dave

     

    Why do the extended instructions need to be disabled? From what I can tell from the data sheet they are encoded as 0xe8??,0xe9??, 0xea??,0xeb?? and 0x0014 and the standard instructions do not use these opcodes. It seems to me if BoostC does not generate code for the extended opcodes then it does not matter if the processor is enabled or not for them. Am I missing something?

     

    If disabling the extended instructions is how it has to be, I'm ok with it. I was just curious if there was a hardware reason.

     

    While we are on the subject of config settings, it seems that if I enable MCLR to be input portE[3] in the config register and drive the pin with a 1 in the simulator, the simulator always returns 0. I think the same goes for the extra portA bits if I configure the internal clock. Are the extra ports pins not supported and might they one day?


  4. Glad to hear that you like the plugin. Sorry, I didn't see your question. I updated the plugin 5 days after you posted this message with a change to the sampling load. It works fine with buttons I create in my plugins but does not seem to work with the button nor button block plugin. I'll try to lighten up the load that the VCD probes place on the signals and see if that works. I think our SourceBoost friends recommended 10M Ohoms and I only used 10K Ohms as I wanted to see floating signals as 1. I think this was a mistake.

     

    Ok. I changed from 10K to 10M and the button now works. I posted the new version on my web site (V0.2 1-21.2010).

     

    Thanks for letting me know about the bug and thanks for letting me know that you are using this as it makes posting it worth the effort. Also, let me know if it is still busted. You can email me at my yahoo address. My name is ted_rossin. Hopefully, a spam sifter can not find me in those two sentences.


  5. I wiped my disk of SourceBoost and MPLAB and did a fresh install of MPLAB v8.43 and SourceBoost v6.96 and found no way to simulate an MPASM project. The default settings in the tool selection dialog box do not work and there is no documentation to describe how to set this up. The error message I get is Can't load file 'Myproj.cod'.

     

    I've previously got this to work with trial and error of settings such that MPASM is run with this command line when I press the old English font A button:

     

    c:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe /pPIC18F4620 /q /aINHX32 /rDEC /t3 /x B1802_18F.asm

     

    If I uninstall version 6.96 of SourceBoost and install version 6.89, I'm almost able to debug an MPASM project if I run the mp2cod utility in the MPASM directory. I'm able to simulate and look at the PIC state but I'm unable to look at symbols. The hover and watch windows do not work.

     

    If I wipe my SourceBoost and MPASM and install version 7.31 of MPLAB and version 6.89 of SourceBoost everything works fine as the old version of MPASM produces a cod file in a format the this older version of SourceBoost decodes.

     

    If I wipe my SourceBoost and install version 6.96, then I get the Can't load file 'Myproj.cod' error and am unable to simulate.

     

    In summary:

    Sourcboost MPLAB Results

    ------------------------------------------------------------

    6.89 7.31 Perfect system that works with plugins

    6.89 8.43 Requires running mp2cod tool. Works except no symbolic debugging

    6.96 7.31 Can't load file 'Myproj.cod' error (Unusable)

    6.96 8.43 Can't load file 'Myproj.cod' error (Unusable)

     

     

    I uploaded my project here: http://forum.sourceboost.com/index.php?sho...amp;#entry16726

     

    There is more info about experiments that I have tried and the results.

     

    I'm plugging along on 6.89 and 7.31 for now but would like to upgrade one day. I also would like to share my work with others and turn them on to this great product but can not as if they download the latest tools my project will not work for them.


  6. Thanks for the info. After playing some more I noticed that the cod file produced by mp2cod allows me to simulate with 6.89 but does not allow me to look at named symbols (holding the mouse over a variable or displaying them in a watch window). Both 6.89 and 6.96 generate an error if there is no cod file (Can't load file 'B1802_18F.cod'). If you would grep through your source code I would bet you would find some code that appends cod to the project or source file basename and tries to load it. This is only true for assembler projects. If I create an 18F4620 C project then only a .cof file is produced and the simulator is happy with that. For fun I renamed the C project .cof file to .cod and I got the Can't load file 'blah.cod' error again. Changing it back to cof made it happy.

     

    Changing the assembler project from COD to COF resulted in the Can't load file 'B1802_18F.cod" error in V6.89.

     

    Just more info to hopefully make some sense of what I'm observing.

     

    Thanks for taking a look.


  7. OK. I updated MPLAB to version 8.43 which got me version version 5.35beta (beta!) of MPASM and as was predicted, I no longer get a cod file. I also reupdated to V6.96 of SourceBoost. It was suggested that I run MPLINK to get the cod file. I read the options in the manual and can not figure out the secret. I got a coff file named a.out which I copied and renamed it to cod and both 6.89 and 6.96 are unable to read it. So my 2 questions are:

     

    1. What are the options to turn a .O (object) file into a .cod file

    2. Is there a way to integrate that into SourceBoost IDE?

     

    I see there is a mp2cod.exe file in the microchip pack. Maybe I can run this somehow?

     

    Any help would be really nice to have.

     

    Update: I ran mp2cod on the .O file produced by MPASM (mp2cod B1802_18F.O) and got a B1802_18F.cod file. I tried to simulate this in SourceBoost v6.96 and got the original problem of "Can't load file 'B1802_18F.cod'.

     

    This is the command line I used and the response from the tool

     

    $ '/cygdrive/c/Program Files/microchip/MPASM Suite/mp2cod' B1802_18F.O

    MP2COD 4.35, COFF to COD File Converter

    Copyright © 2009 Microchip Technology Inc.

    Errors : 0

     

     

    I'm still cooked.

     

    Update2:

    I downgraded to SourceBoost 6.89 and I am able to simulate the cod file produced with MP2COD. I still claim this to be a SourceBoost 6.96 bug. Anybody else able to simulate assembler projects with 6.96? I have no reason to upgrate today so I'll deal with it but one day I might want to upgrade (or even pay money for version 7).


  8. The error was about the cod file and the cod file was in multiple direictores. I did not change my version of MPASM. All I changed was the version of SourceBoost. When I reinstalled 6.89 everything worked fine again (without reruning MPASM). I really believe someone changed something on your side not Microchip's side. I uploaded the project so you can take a look.

     

    Are you able to reproduce the problem? I'm using MPASM version 5.02. I think I just downloaded it a month or two ago. If I'm the only one seeing this problem then maybe I have a corrupted plugin that is corrupting SoruceBoost. I can get the latest version of MPASM from microchip and do a fresh install of SourceBoost (wipe my old directory) and see if it works correctly.


  9. Hey what is up with 6.96? Is there a new setting for ASM projects that I need or has simulation and plug fun ended for ASM projects?

     

    This is killing me. I really am hooked on it.

     

    When I hit the debug button I get the message:

    Can't load fille 'B1802.cod'

     

    I uploaded the project files. I see that there is a B1802.COD file in my directory so I tried renaming it to B1802.cod and it still is unable to load it. No path is given in the error so I copied the file to c: and to the sourceboost install directory but still no go.

     

    I'm thinking this should be marked as a bug and not a question but I'll leave it as a question for now.

    B1802.zip


  10. I've been bashing my head over this off and on for a few days now and by dumb luck got a plugin to start working by using 5 Ohms instead of 0 Ohms for the driver resistance. Here are the words from the plugin guide so I guess I should have known but it is not obvious.

     

    void SetConnectionR( HANDLE hConnection, int ohm )

     

    Set the externally applied voltage levels impedance. “0” means that pin voltage is exactly the external voltage value. “-1“ means infinite impedance so the pin voltage is whatever is generated inside the PIC. When driving a pin from outside use typically 5 to 50 ohm and when trying to read the voltage on a pin 10M ohm:

    ...

    SetConnectionR( hConnection, 50 ); // for typical instrument drive

    SetConnectionR( hConnection, 10000000 ); // for typical instrument input load

     

    I tried implementing a bidirectional data bus (tri-state) such that when a signal named nMRD was zero my plugin would drive 8-bits onto port D and when nMWR was zero my plugin would read 8-bits from port D. When I used a value of zero for SetConnectionR, the plugin would never drive the port D while nMRD was zero. I changed to the plugin code to always drive port D with a certain value to try to debug the problem. What I found was that when the PIC had the port in input mode(TRISD=0xff), the LED block and the simulator would sense a value of 0xff. When I had the PIC in output mode (TRISD=0x00), my plugin would drive the bus. This is completely backward.

     

    By trial and error changing this and that I finally found that changing SetConnectionR from 0 Ohms to 5 Ohms solved the problem and the plugin would now overdrive the bus all the time as expected. Putting my original code back but using 5 instead of zero made the plugin would correctly and drive the bus while nMRD was zero and sense the bus when nMWR was zero.

     

    I was raised thinking that an ideal voltage source had a Thevenin resistance of 0 Ohms not 5 Ohms. Is this a bug in the plugin that should be explained in the documentation or am I reading the words wrong? I will admit that the docs do say use 5 to 50 but it would be nice if others did not have to stumble into this problem. It would be nice if 0 does not work that the plugin system would check for it and bump it up to 5 until the problem can be repaired.

     

    The open plugin system which allows me to create custom plugins for my projects is of huge value to me. I'm just a hobbyist playing with PICs for fun and it saves me lots of time over trial and error hardware/software design. I would think that folks that are doing this for a living would jump all over this advantage. Why wait for your hardware when you can simulate, develop and refine your design in parallel.

     

    I can create a tiny example to demonstate the problem if that will help. Otherwise, I can provide my current plugin and PIC project which I can light switch happy and sad mode by changing a 5 to a 0.

     

    I'm using version 6.89 of SourceBoost IDE. The plugin code example that I based all my plugins on has a copyright of 2003-2004 but I could not find any version information. It looks like the same code that is on the web with files dated May 19th of 2004 so I believe I have the latest code.


  11. I uploaded my latest plugin that I wish I wrote a year or two ago. You can find it here:

     

    http://tedrossin.x10hosting.com/Electronics/Pic/Pic.html

     

    This plug in will allow you to hook probes to all the ports of a pic and rename them to meaningful names. Once started, the plugin will log into a value change dump file any signal that changes and the time that it changed so that a standard VCD viewer can be used to examine the "waves" like a logic analyzer. Gtkwave is one tool that will do it and I have a link to a tool that I wrote (I think mine is easier to use for those new to waveform viewers) next the the link to the plugin.

     

    I didn't provide source to the plugin as I am trying to add more features. I attached a small image of my VCD viewer displaying the results of a simulation of a PIC simulating an antique microprocessor.

     

    Let me know if you have questions or complaints.

    post-1034-1261091298_thumb.jpg


  12. A few years back we talked about the fact that TIMER 0 is not a good choice for a clock as there is an inherent error in reloading the counter. Since you are using a device that has newer timers (TIMER 2) you should use the new timer since you can set the compare value once and just recieve an interrupt at the desired rate. TIMER 0 is fine for keyboad debouncing but not for real-time clocks.

     

    I attached Clock.c and Clock.h that implements a clock using timer 2 that I used for a timelapse photo machine ( http://www.tedrossin.x10hosting.com/Electronics/Pic/Pic.html ) . The code includes a fine adjust to calibrate out crystal errors. The parts per million error on a cyrstal > 1MHz is usually pretty bad (20 to 50) such that your clock will lose or gain 10 to 20 seconds a day. A tuned 32KHz cyrstal connected to be a timer source is another way to get a good timebase. These cyrstals have very low PPM errors.

    This code has more than you want but should at least show you how to modify your code to use timer 2. If it is confusing, never mind as what you have may be good enough if you don't plan on leaving it running for more than a few days.

     

    If you want the ulitimate in accuracy on the cheap, go for sampling the power line (dropped down in voltage of course) to get a very reliable 60 or 50 Hz depending on where you live. The power companies control the beats per day to keep good old synchonous clock motors on the right time.

     

    I tried to search for the thread on this subject but could not find it. We had a blast a few year back about this issue.

    CLOCK.C

    CLOCK.H


  13. I guess I'll start with the basics as you did not show all the code.

     

    Did you initialize messageOffset and dataIndex to 0?

    Did you simulate and display the values of the variables?

     

    To be picky, you should use unsigned char instead of char as you don't seem to want to think of 0xe0 as a negative number.

     

    Hello All,

    I have this bit of code in one of my functions:

    for (messageIndex = 0; messageIndex < registerCount * 2; messageIndex++)
    {
    // Get all of the registers requested
    responseBuffer[messageOffset++] = (char)normalized_value[dataIndex++];
    }

     

    normalized_value is declared as global arrays in the main file and responseBuffer is declared as a global array in the file where the above pasted code is:

    int normalized_value[10]	   =  {3584,0,0,0,0,0,0,0,0,0}; // in main file.
    char responseBuffer[10]; // in the file where the code pasted above is.

     

    I was expecting responseBuffer[0] to get the value of 0x0E (3584 is 0x0E00) in the first iteration of the for loop. But both responseBuffer[0] and responseBuffer[1] are getting 0x00. What is happening? I am using PIC18F4520.

    Any help much appreciated.

    Regards,

    Sudhi


  14. I used Visual C++ under Visual Studio 6 to create the GUI. The waves are just GDI calls. The big brother to this, VcdView, uses GDI as well but does bitblts to draw the screen for better performance. This tool is to view Verilog or VHDL simulation results:

     

    http://www.tedrossin.x10hosting.com/tools/Other/Other.html

     

    I should have used OpenGL but I'm saving that for my next SourceBoost plugin. OpenGL crud can be found here:

     

    http://www.tedrossin.x10hosting.com/Demos/Demos.html


  15. I'll admit that I have not tried this but I believe that the weak pull-ups are tiny little FETs that act like 10K or 20K resistors to VDD. This should limit the current in an LED to such a low value that it will not emit light. The data sheet for a 16F874 says the Port B pull-up current is less than 400uA at 5V. This should not light an LED connected to ground.

     

    P.S. The dang forum keeps logging me out. I've been here for 15 minutes and had to log in twice. This sucks and at least I've learned to copy my posts before hitting Add reply.


  16. Thanks Reynard. I did some reading at the back of the 1978 edition of K&R's C programming language and found the rule you described. I also found some fuzzy words about chars being signed but unsigned can be treated as signed if desired.

     

    I think the biggest problem is that ints are supposed to be the native word size of the target machine. This makes the statement about smaller types being converted to ints before doing math make a lot of sense. Problems arise when making ints larger than the native size of the machine. BoostC and I did this in that ints are 16-bits.

     

    To get around the math needs to be done in int land rule, I check the equation to see if it contains an operation that will notice the difference. I call them reducers (/, >> or %). For example, (B + A) >> 1 or (B+10)/3 can not be performed with 8-bit math even if the result goes into a char as B+A or B+10 could be greater than 255 but the >>1 or /3 could reduce the answer down to fit into 8-bits. If I do not see a reducer I do the math in 8-bit land. If I do and I see an increaser before the reducer, I implement the equation with 16-bit math. I have noticed that the professionals at SourceBoost do someting similar as I've seen both 8 and 16-bit math pop out as appropriate.

     

    This is something that until last week I was unaware of and will think about when trying to write fast code. Sometimes it is beter to use intermediate variables to lead the compiler to produce 8-bit code. For example, if I know that A + B will always be less than 256, I might get faster code if I do T = A+B; Z=T>>1; than T=(A+B )>>1; Although BoostC does fancy stuff like use the carry bit in this case so it still does a fantastic job with the full equation. Multiply or divide might be a different matter.

     

    I'll stop rambling but just wanted to say thanks for the info about the subtle features of C.


  17. I don't know if this is a bug or it is up to the compiler to decide.

     

    I've been working on a C compiler for an RCA 1802 vintage microprocessor (mid 70's) because no one else would and I've always wanted to try.

     

    http://www.tedrossin.x10hosting.com/Electronics/RCA/RCA.html

     

    Lately, I've been testing my equation engine by generating random equations and comparing the results between my 1802 simulator running the code produced and that produced by gcc. I ran into a disagreement with the following code:

     

    unsigned char A=2,B=8,Result;

     

    Result = ~A % B;

     

    With my compiler, I get the answer 5 = ~2 % 8 = 0xfd % 8 = 253 %8 = 5.

     

    With gcc under cygwin, gcc under Linux and Visual C++, I get the answer 253.

    I think the other players are doing 253 = ~2 % 8 = -3 % 8 = -3 = 0xfd = 253.

     

    So I figured I would try BoostC. BoostC gave the answer 5 not the odd answer that the other compilers give which seem to be due to ~2 being turned into -3 before doing the modulo calculation and getting the result -3 which is then turned back into an unsigned char. I would think since all the variables are unsigned it would treat the intermediate values as unsigned but it does not seem to do that.

     

    If I switch to unsigned int, gcc under cygwin, gcc under Linux and Visual C++ all return the answer 5.

     

    So my question is this. Does BoostC and I have a bug in that math on unsigned chars should be promoted to signed math then back to unsigned while math on unsigned ints do not need this or do the other guys have an odd bug that has been copied for years and years?

     

    #include <system.h>

     

    void main(void)
    {
    unsigned char A=2,B=8,Result;
    
    Result = ~A % B;
    while(1);
    
    }


  18. Not really BoostC stuff but I use this tool to help me develop with BoostC so maybe others will find it useful as well.

     

    I updated the GUI for my $10 logic analyzer to add support for busses, pretty colors and help. I put a little plug in for BoostC in the notes section of the screen dump.

     

    http://tedrossin.x10hosting.com/Electronic...l#LogicAnalyzer

     

    Here are some other projects. Most were implemented using BoostC

     

    http://tedrossin.x10hosting.com/ElectroArt/ElectroArt.html


  19. The problem is your switch debouncing code. You assume that the switch will only bounce once. The secret to dealing with switches is to wait after a change has been detected before continuing with the code. Switch bouncing can last a good while depending on the quality of the switch. To be safe, I would use 50 to 100 ms (1/20 to 1/10 of a second.

     

    One trick I use, since you have an interrupt handler, is to add a rate divider counter (in your case t1 or t2) in an interrupt handler that checks the swithes only when the rate divider expires such that it looks every 1/20 of a second.

     

    if(t1==152){ // Adjust for desired delay

    S0 = (portb.0==1) ? 1 : 0;

    S1 = (portb.1==1) ? 1 : 0;

    }

     

    This way, if the switch was just pushed before t1==152, it may not see the switch pushed down. But, the next time t1==152, it will see the switch down as it is hard to push a switch for just 1/20 of a second. When the switch is released, the same thing happens.

     

    The main code can now just look for S0 or S1 and they will be very clean signals that show the state of the switches.

     

    I hope this helps.


  20. I think the problem is that you do not filter the input with a capacitor. I'll assume you used a full wave rectifier to convert AC to DC. This produces a signal that looks kind of like the absolute value of a sine wave. If you randomly sample this signal you get a random voltage. If you asynchronously periodically sample at a rate much higher than your line frequency and average the values, it will settle down and the average voltage of the wave.

     

    What you would like to do is use a 100uF cap to store the peak voltage and hold it while you are reading the value.

     

    Line voltage--> Transformer --> rectifier --> Cap to ground in parallel with PIC A/D input.

     

    A voltmeter will be your friend. Put it in AC mode and measure the voltage on the output of the rectifier before you add the capacitor (Make sure you get a 35V cap as 14VAC will turn into about 20 VDC when rectified [VAC is usually measured as Root Mean Squared (RMS) and not peak-to-peak]). Anyway, I'm guessing you will see a value similar to the noise you are seeing (about 1/2 to 1 Volt) without the PIC attached, you may see 10 Volts AC. Add the 100 microFarad capacitor between the PIC A/D input pin and ground and you should see this value drop down to zero. Switch the meter to DC and you should see a nice stable non-zero voltage.

     

     

    Here are some fun links that draw nice pictures and use better words than I did above:

     

    http://www.allaboutcircuits.com/vol_3/chpt_3/4.html

     

    http://www.play-hookey.com/ac_theory/ps_rectifiers.html

    http://www.play-hookey.com/ac_theory/ps_filters.html


  21. Yahoo is trying to save/make money and is killing off Geocities free web hosting October 26th so I moved my site here:

     

    http://tedrossin.x10hosting.com/

     

    My pic stuff is here:

     

    http://tedrossin.x10hosting.com/Electronics/Pic/Pic.html

     

    My crap is still at the old site but I'll only update the new site. Yahoo claims that on October 27th it will all be gone. The good news is that the new site has no ads.

     

    Let me know if I broke something.


  22. As usual, it all depends on what you are trying to do. If you only need a low precision value of the external voltage, you can still use the 16F627. The secret is to use the comparator along with the on-chip voltage reference (CM2:CM0=2). The comparator can tell you when your external voltage that you apply to the chip is above the reference voltage. Since the reference voltage is programmable, you can write software to find out what voltage your input signal is near using successive approximation (this is how the A/D converter hardware works on the PICs that have them). You just have to code it up yourself for the chip you have. You end up with less precission as you only get 4 bits to play with. But, you get two ranges to try. See the data sheet Section 11.0 Voltage Reference Module.

     

    I have never coded this up but wanted to try it out one day but what could go wrong? Here is what you could do.

     

    1. Select the proper comparator mode (2) CMCON[C2OUT=0,C1OUT=0,C2INV=0,C1INV=0.CIS=0.CM2:CM0=2] or CMCON=0x02;

    This should set it up so that if Vin- is > Vin+ (the reference voltage) C1OUT will be 1. If Vin- is less than the reference voltage the C1OUT value will be 0.

     

    2. Enable the reference module: Set Vren=1 to turn on the module, VROE to 0 to turn off the output on RA2, Set the VRR to 1 to select low range. This can detect a voltage between 0 and 3.125V (if you power the chip with 5 Volts).

     

    3. Be lazy and do a linear search with a for loop from 0 to 15. Set VR3 to VR0 to the value of the loop counter. Wait for the reference voltage to stabalize and the comparator to come up with an answer (you will have to look at the data sheet for this. I can't find it with a quick look). For now just wait 1ms. Now check the value of the comparator output. If it is zero keep looping. If it is one remember the number and break out of the loop and go to step 5.

     

    4. If you made it to the end of the loop without seeing a 1, then repeat steps 2 and 3 but use the high range (VRR=0).

     

    5. The voltage applied to the comparator from the external device is based on whether you broke out of the loop with the high or low range:

     

    If Low range(VRR==1): V=SavedLoopCount/24*5V [0 to 3.125V]

    If High range(VRR==0):V=(SavedLoopCount/32 + 0.25)*5V [1.25 to 3.6V]

     

    The words are uglier than the code but I hope this helps. As you can see high range will give you a more precise answer then low range but it will only go down to 1.25V. It is perfectly fine to just use the Low range if you can limit your input voltage. This can be done with a simple voltage divider. Take two 1K Ohm resistors and connect them in series. Connect one end to your voltage source and the other to ground. Connect the center point to the pic. This will make it such that if your voltage source is 5V, the PIC will see 2.5V. If the input is 2.5V, the PIC will see 1.25V. It is just a linear scale.

     

    The end result is that the comparator and reference module can be used to create a 4 bit A/D.

     

     

     

     

     

    P.S. Your avitar is creepy. I really like it!

×
×
  • Create New...