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 fol
  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
  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 =
  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
  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) * Cha
  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
  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 unimpo
  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
  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...