Jump to content

davidb

EstablishedMember
  • Content Count

    134
  • Joined

  • Last visited

Posts posted by davidb

  1. Before anything thanks to the Sourceboost for answer me the questions i have post until now.

    As you certainly understand, the user can only evaluate a tool conveniently, after trying to do anything likely a real application with a several thousands of code lines and using the chip close to the limits in terms of physical resources, pseudo multitasking, communications, lcd and so on, that is the case with me at the moment.

     

    So, back to the question:

     

    The function list showed in the Workspace/Browse>Functions, not list the functions outside of myproj.c file.

     

    I mean! imagine i have a project named myproj.c with more two files: myproj.h and mylcd.c where, mylcd.c have InitLcd() and PrintString() functions.

    At first glance I expected to see these functions (InitLcd and PrintString) in the list, but not.

    Then i declared the prototypes explicitly waiting to see them listed, but no again.

    This assumes some relevance when we have several files with thousands of lines.

     

    This is really so or is there a specific procedure?

     

    Regards,

    Joli

     

    Joli,

     

    Make sure that you have added the required files to the project. Only *.c files are actually required. If they are not listed under workspace/files then the functions will not appear under workspace/browse. Having said that, the project will not link if they are missing.

     

    Also under workspace/browse try using group by file.

     

    I have several projects each with a large number of files (20+) and have never noticed any functions missing from the list.

     

    Regards

     

     

    davidb

  2. Since you haven't shown us the code for driving the LEDs or the target being used I suspect the problem may be there if you are manipulating the port pins directly.

     

    In this case it is probably our old friend the read-modify-write problem. If you haven't come across this before then there are plenty of references available.

     

    Try here for a good description: http://embeddedadventures.blogspot.com/200...s-and-sfrs.html

     

    Regards

     

    davidb

  3. Try to download latest 6.97 RC and use it to build your code.

    That fixed it.

    Thanks.

     

    A follow on question:

     

    How do you get the external clock for TIMER0 to work in the simulator for the PIC18F46J50?

     

    Charles.

    Looks like there has been more than one version of RC3 posted on the site!

     

    The config failed as above when I tried it this morning with a previously downloaded RC3.

     

    After downloading what I thought should be the same version (RC3) it now works!

     

    Regards

     

    davidb

  4. The .tdf file sets the config address at 0x0000FFF8 and not 0x00300001 as expected.

     

    Perhaps this device has a new feature that I have not seen before.

     

    Cheers

     

    Reynard

    Reynard,

     

    This family of devices seems to be different from other 18Fs in that the last four words of flash memory are used to store the config data which is then copied into the 'normal' config locations on power up or reset. These 'normal' locations are now volatile.

     

    It seems that the last four flash words must be reserved to prevent them being overwritten by the program. Presumably SourceBoost deals with this. See section 26.1.1 of the device datasheet for more info.

     

    Regards

     

    davidb

  5. Presumably you tried it in SB IDE and it worked?

     

    I had a similar problem in the past when creating an MPLAB project so it might be because of the way you created the project.

     

    Try creating the project again from scratch (delete all the old files in the project folder except your test.c file) and then do as follows in MPLAB:

     

    Project > New

    Project name > test

    Project Directory > the folder where your test file lives

     

    Configure > Device > 16F1936

     

    Now close MPLAB and save the workspace

     

    Now re-open MPLAB

    Project > Open test.mcp (navigate to the project folder)

    Right click on 'source file' in the workspace window > add files > open test.c

     

    The project should now compile and link as follows:

     

    Clean: Deleting intermediary and output files.

    Clean: Deleted file "test.OBJ".

    Clean: Deleted file "C:\SW_IN_PROGRESS\Forum\test.HEX".

    Clean: Deleted file "C:\SW_IN_PROGRESS\Forum\test.mcs".

    Clean: Done.

    Executing: "C:\Program Files\SourceBoost\boostc_pic16.exe" test.c -O1 -W1 -t 16F1936

    BoostC Optimizing C Compiler Version 6.97 (for PIC16 architecture)

    http://www.sourceboost.com

    Copyright© 2004-2010 Pavel Baranov

    Copyright© 2004-2010 David Hobday

     

    Licensed to Farn50598 under Single user Pro License for 1 node(s)

    Limitations: PIC12,PIC16 max code size:Unlimited, max RAM banks:Unlimited

     

     

    test.c

     

    success

    Executing: "C:\Program Files\SourceBoost\boostlink_pic.exe" "C:\SW_IN_PROGRESS\Forum\test.obj" -O1 -p "test" -t 16F1936

    BoostLink Optimizing Linker Version 6.97

    http://www.sourceboost.com

    Copyright© 2004-2010 Pavel Baranov

    Copyright© 2004-2010 David Hobday

     

     

    Optimisation level:1

    Building CASM file

    Memory Usage Report

    ===================

    RAM available:512 bytes, used:0 bytes (0.0%), free:512 bytes (100.0%),

    Heap size:336 bytes, Heap max single alloc:95 bytes

    ROM available:8192 words, used:11 words (0.2%), free:8181 words (99.8%)

     

     

     

    success

    Loaded C:\SW_IN_PROGRESS\Forum\test.COF.

    BUILD SUCCEEDED: Fri Apr 23 14:39:10 2010

     

    Regards

     

    davidb

  6. Hi,

     

    My code dont start up...

     

     

    i set a semaphore when new start.

     

    Buzzer task is must make a BEEEP for answer.

    But i dont see any thing... :rolleyes::)

     

    AND my compiler is say :

    WARNING: Overlapping user DATA at address : 0x0030000C

     

    Circuit is working with my old code... ( mean circuit dont have any problem )

    I want make with Novo...

     

    What i make wrong ?

     

    Thanks...

    Try changing the last line of your #pragma data to #pragma DATA _CONFIG7H, _EBTRB_ON_7H

     

    Regards

     

    davidb

  7. Hello all, I'm evaluating the C compiler to see if it will be suitable for a small project I want to do so first of all thank you producing it :)

     

    Now my problem, I have a pickit2 and the low pin count board that comes with it.

    It has a 16F690 chip and LEDs on portc bits 0-3 and a switch on porta bit 3

     

    As a simple test I've made the following program. All if is supposed to do is to flash one LED and have the other reflect the state of the input bit.

    However it only displays the state of the input bit. If I swap around the two lines that set the port bits then it only flashes. It's as if the first assignment to a bit of port C doesn't work.

    The point is that both the LED setting lines work individually but when I have them both one doesn't do anything.

     

    The board is working fine as the assembly language version works ok.

     

    Basically this is my first C program for this board and I'm wondering if I missed something somewhere...

    Could be the classic read-modify-write problem when writing individual bits to the port registers. Easily solved by using shadow registers. Look this up in the datasheet or find a good description (and ready made solution) by Ian Harris at: http://embeddedadventures.blogspot.com/200...s-and-sfrs.html.

     

    Regards

     

    davidb

  8. That was it..... Thank you. Why is that not mentioned in the help file? I mean, it states that the function is declared in the .h and defined in the .lib, but there is no statement to the fact that this file has to be added to the project. Am I just supposed to know that?

    The reference manuals (help) are not ideal and a sentence or so on creating projects with several files and the use of libraries would be helpful to newbies. There are a few references to this on the forum and also a mention about c and lib files in the Tip Of The Day.

     

    Basically any library function used must have it's .lib file added to the project. The only exception to this is the libc file which SourceBoost IDE adds automatically when linking. If you use MPLAB instead of the SB IDE then the appropriate libc must be added to the project as well.

     

    Despite the poor references and a few compiler quirks and ommisions I think you will find the overall package effective and very good value.

     

    Good luck with the rest of your project.

     

    Regards

     

    davidb

  9. Pavel,

     

    I know you state your code is untested and I haven't tested it either but I spotted an error in the following section:

    	//Configure serial port speed and interrupt
    ipr1.RCIP = ipr1.TXIP = ipr3.RCIP = ipr3.TXIP = 0; //use low priority interrupt
    txsta.BRGH = txsta2.BRGH = 1;	   //high speed
    txsta.BRGH = txsta2.BRGH = 64;	  //9600kbps/10Mhz

    I believe the last line should read:

    	spbrg = spbrg2 = 64;	  //9600kbps/10Mhz

     

    Although not strictly incorrect as is I would probably rewrite the whole section as follows:

    	//Configure serial port speed and interrupt
    ipr1.RCIP =  0; //use low priority interrupt
    ipr1.TXIP =  0; //use low priority interrupt
    ipr3.RCIP =  0; //use low priority interrupt
    ipr3.TXIP = 0; //use low priority interrupt
    txsta.BRGH =  1;	   //high speed
    txsta2.BRGH = 1;	   //high speed
    spbrg = 64;	  //9600kbps/10Mhz
    spbrg2 = 64;	  //9600kbps/10Mhz

    This avoids the code bloat associated with the x = y = z; type of assignment.

     

    Regards

     

    davidb

  10. Yes the Novo RTOS documentation has been updated.

     

    Regards

    Dave

    Thanks Dave.

     

    Apart from having a quick play I haven't made the jump and used Novo on a real project yet so the following may seem like ridiculous questions.

     

    With priorities enabled I assume that 15 levels are always available since there seems to be no way that you can choose the maximum number. Before the re-alignment of the documentation to the code it seemed obvious (at least to me) that you would always use 0 as the highest level and then as many levels as required with increasing numbers and decreasing priority (including equal priority).

     

    Since 14 is now the highest priority what should you do if you only require say 3 levels? Does using 14, 13 and 12 have any impact on the code or memory compared to using 2, 1 and 0 in high to low order? Is there any problem in using say 14, 5, and 0? Is it simply the order that is important rather than the absolute values?

     

    I think having a variable number for the highest priority rather than it always being 0 makes the code a little less easy to understand although maybe the levels could be redefined in some way to make it clearer.

     

    Regards

     

    davidb

  11. Thanks for the confirmation - my brain is now a little less confused :unsure:

     

    I am dealing with real time audio that is pushing the PIC's limits, so the effect was very obvious. Especially with some inefficient initial code.

     

    You folks have great products and I am very impressed with the level of support and quick responses.

     

    I am sure that whatever the issue, it will be resolved.

     

    Regards,

    Carl Petito

    Has this issue been resolved one way or another yet?

     

    Regards

     

    davidb

  12. As i understand by looking to the driver code, this is to use with RTOS (novo)!?

    If is the case, i'm sorry but right now is impossible to alocate time to do the necessary and apropriated tests.

    Anyway, thank you.

     

    joli

    I am sure the driver isn't intended for exclusive use with NOVO, it just happens that the demo code demonstrates the use of the driver with NOVO - killing two birds with one stone! Perhaps another simple demo is called for to demonstrate the driver without using the RTOS?

     

    Regards

     

    davidb

  13. Hello Wizards,

    I have got a requirement where by I want to charge a capacitor to 2000V in 30mSec or less. The capacitance value is 190uFD. I dont know how to calculate current required to charge this capacitor within this time and how can I check it using a controller?

    Regards

    Shree

    Shree,

     

    What you need is a capacitor charging supply and a pretty large one if you really mean 190uF, 2000V and 30mS.

    These are often resonant mode switching supplies with or without a PFC front end and are normally rated for peak power.

    Designing one of these for the performance you require is not a trivial task.

     

    The stored energy for your capacitor is 1/2C*V^2 or 380 Joules at 2000V. This in itself is not particularly large but charging in 30mS is not easy and requires high power electronics.

     

    The required peak power rating of the charger in J/S is (0.5 * Capacitance (F) * Charge Voltage * Power Supply Voltage Rating) / Charge Time (S)

     

    In this case if we assume that the power supply is rated at the required capacitor voltage then

     

    Ppeak = (0.5 * 190*10-6 * 2000 * 2000) / 30mS = 12666J/S

     

    The peak charging current is twice that of an equivalently rated DC power supply so

     

    Icharge = (2 * Ppeak) / Vrated = (2 * 12666) / 2000 = 12.66A

     

    or alternatively Icharge = (Capacitance * Vcharge) / Charge Time = (190*10-6 * 2000) / 30*10-3 = 12.66A

     

    As for monitoring the current, hall effect sensors are often used. Check out www.lem.com/

     

    I hope this helps

     

    Regards

     

    davidb

  14. Hi all - I found a bug in my I2C Slave demo code. State 3 & 4 are incorrectly defined. The following lines of code corrects the bug:

    Hi Bernard,

     

    I have a prototype PIC18F4520 slave apparently running OK with not too dissimilar code to yours.

     

    What exactly were the incorrect definitions and how did the bug manifest itself?

     

    I just want to make sure that I haven't made the same mistakes.

     

    Have you posted the incorrect I2C Slave demo code previously? Your file Version and date of the latest code are very old!

     

    Regards

     

    davidb

  15. Hello, I'm experimenting with the EEPROM of a PIC16F88. At the minute I'm trying to write an arbitary value to an address in the EEPROM. However I'm seeing the " error: left operand must be l-value" error message. I have a vague idea that this is something to do with trying to assign a variable to a constant but i'm stumped on as how to get around it. The code I have is:

     

    void eeprom_write()
    {
    
    EEADR=01111011b;												//write address to EEADR
    EEDATA=01110001b;												//write 8-bit data value to EEDATA
    eecon1.7=0;													//access data memory
    eecon1.2=1;													//allow write cycles													
    intcon.7=0;													//temporarily disable interrupts
    eecon2=01010101b;												//write 55h to eecon2
    eecon2=10101010b;												//write AAh to eecon2
    eecon1.1=1;													//Initiates a write cycle
    intcon.7=1;													//re-enable interrupts
    eecon1.2=0;													//Inhibits EEPROM writes													
    while(pir2.4==0)
    {
    	nop();												//wait for write to complete
    }
    pir2.4=0;

    Currently I just want to write values to the EEPROM, simulate the progam and check for correct operation. Any help is appreciated, thanks.

    Deckard,

     

    EEADR & EEDATA are the literal definitions for the associated variable addresses so you are trying to assign a value to a literal.

    BoostC uses lower case convention for register variables. Use eeadr & eedata for the registers. See the appropriate header file in the include directory, in your case PIC16F88.h, for all the definitions and declarations.

     

    Regards

     

    davidb

  16. Resistors.

     

    Use two in series between the 400V source and ground. Take the point between the resistors and send it to the PIC but put a 100 Ohm resistor in series with that.

     

    400V -/\/\/\/--A---\/\/\/\/\---GND

    At point A-----/\/\/\/\/\----PIC

     

     

    Call the resistor between 400V and point A R1, the resistor between A and GND R2, the resistor between A and the PIC R3. Make R3 100 Ohms to limit current to the PIC clamping diode in case some nut case puts 1KV on the input. To solve for R1 and R2 requires knowledge of what kind of load you can put on the 400V source. I'll assume it can handle 10K Ohms.

     

    Our buddy Ohm has a law that states the Voltage = Current * Resistance (V=IR). So at 400V we would like point A to have 5V so the voltage across R2 is 5V. The current is (I=V/R) or V/(R1+R2) or 400/10,000 = 40mA. R1 = V/I = 5/40mA = 125 Ohms.

    R1+R2 = 10,000 so R1 = 10,000-125 =9875 Ohms. The bummer is that you can't buy these values. The magic ratio you are looking for is 1/80 so R2/(R1+R2) is 1/80. You could use a 100 ohm for R1 and a 8.2K for R2 and get close (1/83). This would make 400V equal 4.82 at the PIC. This is a 4% error that you could get rid of with a lookup table or our friend y=mx+b.

     

    I hope this helps.

    Ted,

     

    If you use 10k for R1 then you will need to dissipate approximately 16W! Large power resistors are never very good for pot chains anyway and their range of values is small.

     

    In your last statement you say that R1 is 100R and R2 is 8k2. Something definitely wrong there!

     

    Shree,

     

    Apart from dissipation you also have to consider the voltage rating of R1. This needs to be at least 500V or use 2 or more resistors in series to make up the value.

     

    The impedance seen by the PIC ADC input needs to be kept as low as possible (lower than 4.7k - 10k for most PICs).

     

    You need to keep the voltage to be measured within the range of the ADC otherwise you will hit the end stop and get a false reading. This means that you must consider the range of measurement, the resolution required and the full scale reading possible. e.g. if you expect to read 0 - 400V then I would make the fullscale reading say 450V or even 500V. This does reduce the accuracy somewhat but if you only need to measure the 400V within a narrow band of say +/- 50V then you could use the -ref pin to provide an offset to make full use of the ADC range to improve the accuracy.

     

    For basic measurements of 0-450V simply use the 5V rail as the reference, make R1 = 440k (2 x 220k 1/2W in series), R2 = 4k94 (4.7k 1/8W + 240R 1/8W in series) and R3 = 100R 1/8W.

     

    For greatest accuracy use an accurate reference voltage such as a REF198 (4.096V) with say 0.5% or better tolerance resistors with appropriate values and place a non-inverting buffer amplifier between the chain and the ADC input to reduce the impedance.

     

    The 400V ground and the PIC ground MUST be common for the above simply circuits to work. If your SMPS supplying the PIC is truly isolated and everything is safely enclosed (i.e. nothing can be touched by the operator or poked through holes and safety clearances are maintained) then you should be able to connect the measured supply and PIC supply grounds together.

     

    If you need to have isolation between the PIC and the measured voltage then you need to look at either analogue isolators (NOT simple optos!) or carry out the measurement on the 400V side and transfer the result over an isolated digital link. In most isolation cases you will also need to provide isolated supplies for amps, PICs etc. which is always a bind.

     

    Regards

     

    davidb

  17. Shree,

     

    The way you measure the mains voltage and current depends on what precision and response time you require as well as how far you want to go with complexity and expense. If you need isolation then that is yet another factor.

     

    I would recommend using a current transformer for current measurements. Don't forget that current measurements in particular based on sinusoidal waveforms will be innacurate with anything other than pure resistive loads. If the voltage waveform is also distorted then you will have even more inaccuracy.

     

    If absolute accuracy and fast response is unimportant then a simple way to measure the mains voltage might be to use a small transformer for isolation followed by a full-wave rectifier, capacitive filter and small load. Depending on the capacitor value this should give a DC voltage approximating the peak of the mains but scaled by the transformer ratio.

     

    Pot this voltage down further to be within the AD range of the PIC for the expected maximum and minimum mains voltage. Take precautions against overvoltage etc. to avoid damaging the PIC input. If you include a factor of x 0.707 in the potential divider then the DC voltage at the ADC input of the PIC will represent the rms value (but not true rms). There will of course be ripple on the voltage but this can be digitally filtered by your PIC software if you take enough samples to obtain a smooth reading. You will obviously have to calibrate your particular setup to take into account any errors introduced by the rectifier diodes, transformer magnetising current etc.

     

    More accurate and hence more complex and expensive designs could include the HCNR201 or similar linear opto-isolator followed by a precision rectifier etc. You could also do the rms to DC conversion in hardware. Try looking at devices made by Linear Technology e.g. LTC1968, or Analog Devices e.g. AD637.

     

    Do as much conversion as possible in hardware and avoid floating point maths.

     

    I don't know how easy it is for you to obtain parts in your location but try Farnell, RS, Digikey etc.

     

    Regards

     

    davidb

  18. Shree,

     

    The way you are trying to monitor the mains is all wrong if you want accuracy AND isolation. Not ALL optocouplers are lousy - try looking at Avago (HP) HCNR201 datasheet and associated application notes.

    You also need to decide on what information you want to display and how to display it.

     

    Are you trying to build a mains power monitor? Try searching for such a beast, you may find some useful information on monitoring mains voltage and currents. An initial search found this:

     

    http://openenergymonitor.org/

     

    Not only will you have to worry about RMS, Peak, Average values etc. but Power Factor also comes into the equation if you are to display power.

     

    One final caution. I am sorry if I am wrong but I get the feeling from your posts that you may not have sufficient electronics knowledge (at the moment anyway) to play around with mains voltage. Use an isolation transformer whenever possible to supply your circuits so you can ground your test equipment to minimise the risk of working live. Please be extremely careful and don't take chances.

     

    davidb

  19. Microchip added the LATx registers to the PIC18 series specifically to cure this problem by allowing the output LATCHES to be read for a RMW instead of the pins. They didn't get it perfect though and the RMW bug crops up on PIC18s if you do bit operations on a TRISx register while the I2C module is 'fiddling' with tri-stating its pins!

    Ian,

     

    Do you have any references for RMW problems with the I2C Module and TRISx on PIC18Fx devices?

     

    I believe there was a problem with this on early silicon issues of PIC16Fx devices but not PIC18Fx (DS80131E).

     

    I have a prototype, apparently running without any problems, using a PIC18F4520 for both the I2C master and slave but I obviously need to confirm that a bug like this will not bite me when in production.

     

    Regards

     

    davidb

×
×
  • Create New...