Jump to content

davidb

EstablishedMember
  • Content Count

    134
  • Joined

  • Last visited

Everything posted by davidb

  1. 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. 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. 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: Regards davidb
  6. Try changing the last line of your #pragma data to #pragma DATA _CONFIG7H, _EBTRB_ON_7H Regards davidb
  7. 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. 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. I am guessing you haven't added the adc library file (adc.pic16.lib) to the workspace window. Regards davidb
  10. 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
  11. 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
  12. Has this issue been resolved one way or another yet? Regards davidb
  13. 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
  14. 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
  15. 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
  16. 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
  17. Joli, Try #pragma DATA _EEPROM, 1, 2, 3 ... Regards davidb
  18. 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
  19. Shree, AFAIK, apart from the different working voltage range and lower maximum operating frequency, the PIC16LF648A is functionally identical to the PIC16F648A so just use the PIC16F648A. Regards davidb
  20. o.p., It works on 16F & 18F but I must admit I haven't tried it on the PIC12F683. 'bit' is documented in the the BoostC manual V1.53 on page 45. Don't forget to set the port direction for the bit or bits you are trying to set to output i.e. trisio.5 = 0; Regards davidb
  21. Just drop the #pragma i.e. bit load @ 5.0 ; // variable (load) is being assigned to the pin 0 Check the reference manual for more info. Regards davidb
  22. 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
  23. 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
  24. Ian, Thanks for the reference. I suspect the 'problem' on the PIC18F might be hearsay. I don't like adding code to solve problems that may not exist but if in doubt... Does anyone know any more regarding this issue? Regards davidb
  25. 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...