Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Reynard

  1. Have you told the compiler your clock frequency ? #pragma CLOCK_FREQ so it can calculate the correct delays. When you turn on the ADC module or change channel, you have to allow an aquisition time to allow the sampling capacitor to charge up to the input voltage before starting the conversion. Do not do 'adcon0.2 = 0'. The flag will reset itself to zero when conversion is complete so poll for it to happen before reading the result register. Writing a 0 may abort the conversion. Cheers Reynard
  2. Hi Philippa, SourceBoost C does not support the use of floats in the way other compilers do. :angry: There is the float library use can use to build trig functions although a bit long winded. Send me a personal message with an email address and I can send you something from another compiler that you could look at to get some ideas how to do it with the boost float functions. Cheers Reynard
  3. Reynard

    Broken Enum?

    Dan, An enum name is not a variable but a data type. Whether it is a unsigned char or int will depend on the size of the enum values. i.e. if you have BYP_CLOSE=1000, then the compiler will make the variable (fred) a unsigned int. The compiler will use the smallest data type it can. #include <system.h> enum Bypass_Position {BYP_OFF,BYP_OPEN,BYP_CLOSE}; enum Bypass_Position fred; void main() { fred = BYP_OPEN; } Cheers Reynard
  4. Well explained reason Bill. A simple 'Invalid Symbol' or something would have explained the error better though. Cheers Reynard
  5. It looks like the compiler errors on the C and forgets about the rest of the line giving the odd-ball error codes. ;///////////////////////////////////////////////////////////////////////////////// ;// Code Generator: BoostC Compiler - http://www.sourceboost.com ;// Version : 6.89 ;// License Type : Full License ;// Limitations : PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only ;///////////////////////////////////////////////////////////////////////////////// #include <system.h> enum Bypass_Position {BYP_OFF,BYP_OPEN,BYP_CLOSE}; unsigned char fred1; unsigned int fred2; void main() { fred1 = BYP_OPEN; 0004 0E01 MOVLW 0x01 0006 6E03 MOVWF gbl_fred1 fred2 = BYP_CLOSE; 0008 0E02 MOVLW 0x02 000A 6E01 MOVWF gbl_fred2 000C 6A02 CLRF gbl_fred2+D'1' } 000E 0012 RETURN //////////////////////////////////////// // Code with no source :-) //////////////////////////////////////// 0000 EF08F000 GOTO _startup 0010 _startup 0010 EF02F000 GOTO main I am using V6.89 and PIC18F4550 with no problem on your enum. Cheers Reynard
  6. Remember that some single character names, such as C and D, are already defined as register bit names (see pic header file). enum Bypass_Position {BYP_OFF,BYP_OPEN,BYP_CLOSE}; This enum works for me ! Cheers Reynard
  7. Take note that your "getc()" function is a blocking function. That is, it will not return until it receives a char from the serial port. That is probably why you are not outputting "start" every 1 second. You are waiting for that character to arrive. IOC Interrupts are still active so you are still outputting "ends". The IOC pins are not Schmitt triggers so you need a fairly fast rise and fall time from your IR sensor. A possible cause of double "ends". A bit like contact bounce. Cheers Reynard
  8. Hi Baixue, The compiler should have warned you that you are calling "put(s)" from different threads. It is OK to do this if you know you have it secure so that put(s) cannot be called simultaneously (not in your case though). Does your IOC switch input have a pull-up resistor on it. If not you could be picking up alot of noise when the switch goes o/c. Use the internal weak pull-ups if you don't. You will also have to consider the possibility of contact bounce from your switch. This can cause multiple IOC interrupts giving double output strings. You may want to consider not using the IOC feature and instead poll the switch, say every 10ms, and incorporate some form of contact bounce elimination method. IOC is nice but has its problems. To quote the manual: "If a change on the I/O pin should occur when the read operation is being executed (start of the Q2 cycle), then the RABIF interrupt flag may not get set." IOC is good if you have some form of portable device that sits in sleep (very low power) mode waiting for someone to press the ON button or keypad to awaken the device for use. Cheers Reynard
  9. Remember that delay_ms(t) takes only an unsigned char therefore the maximum value is 255 otherwise you will be short changed. Also, use #pragma CLOCK_FREQ 4000000 to tell the compiler your clock frequency so it can calculate the correct delays. You can set the clock rate in the IDE, but it is more complete to use the pragma. Although you only have a single interrupt source, get into the habit of qualifying your interrupt flags: if (intcon.RABIF) { ... } or if you turn some interrupt on and off within your program: if (intcon.RABIE && intcon.RABIF) { ... } Cheers Reynard
  10. Hi Carlos, I can see nothing wrong with the data you are receiving. Your transmitter seems to be sending each character as 2 ascii hex nibbles. It is your job to recombine these nibble pairs back into the original data. Cheers Reynard
  11. Yes a PIC can do this type of work. If you search the web you will find a few examples. If you are designing the transmitter and receiver, then you can do whatever system you like. You can buy chips which will do the modulation and demodulation, but the PIC can do it with a bit of software. There are standard coding systems depending on manufacturer of the TV, DVD player etc. The modulation frequency is around 38kHz and can vary a couple of kHz either way, again depending on manufacturer and chip set used. If you get yourself a photo diode and fet op-amp you can see the data on a scope when you aim a TV remote at it. A photo diode with a built in IR filter recessed into a dark tube should work well to get rid of daylight swamping the diode. Cheers Reynard
  12. Info is thin on the ground for this one. From what I read, the FRC is not recommended on low device clock rates due to digital switching noise unless the device is put to sleep during conversion. I would have thought this noise would only effect the accuracy and not freeze the device. How do you read note 4 in the data sheet ? Cheers Reynard
  13. Have you tried modifying the device PICxxxxx.tdf file in the config directory to limit the top address range to 1E7F ? Configure ProgramMemory { AddressRange = 0000h -> 1FFFh; } Cheers Reynard ps. What about the -rt linker switch. (Forgot about that).
  14. It's the fine print that gets you every time Reynard
  15. Hi Baixue, Good to see you are making progress. Here are a few more tips. unsigned char current, history; void main { // Use bit names to make code more readable. // Remember, at reset all intcon bits are = 0 so you don't have to reset them. set_bit(intcon,GIE);//enable all interrupts set_bit(intcon,PEIE);//enable all peripheral interrupts clear_bit(intcon,T0IE);//disable the timer0 interrupt clear_bit(intcon,INTE);// disable the RA2/INT exteranl interrupt set_bit(intcon,RBIE);//enable the interrupt(RABIE) .... history = portb; // initialise history to current port value. .... while (1) { .... } } void interrupt { current = portb; // read and sync match register in one go. clear(intcon,RBIF); // clear change interrput flag. .... // Process current data and led's. // Don't work with the real portb data as it may change, use the current snapshot. .... history = current; } Cheers Reynard
  16. Works for me using BoostC 6.89 PIC16F876 unsigned char test; asm { movlw 5 0008 3005 MOVLW 0x05 movwf _test 0009 1283 BCF STATUS, RP0 000A 00A0 MOVWF myFunc_00000_1_test movf _test, W 000B 0820 MOVF myFunc_00000_1_test, W rlf _test, F 000C 0DA0 RLF myFunc_00000_1_test, F } I have seen problems in the past with instructions end in ,W and ,F. Adding a semicolon to the end of the line appeared to solve it. Sure your BoostC version is up to date and your target is correct ? Cheers Reynard
  17. IOC will generate only a single interrupt. When you enter the interrupt service routine you should read the IOC port (assuming RBIF is set) into a glabal variable which will automatically reset the interrupt flag (RBIF). Set a flag bit and let the main processing loop deal with the change. interrupt routines should be kept short and sweet. The main processing loop will see the flag set and process the new port input data. The new data is compared with an older sample (history) to see which bits have changed (XOR). Now a change can be high-to-low or low-to-high, so it is up to you which condition you turn on/off your LED. Once you have processed all the changed bits, make the new port inputs value the history value ready for the next change. You may want to disable IOC interrupts (RBIE) while you are processing the new data during the compare just in case another IOC interrupt occurs and changes the data before you are finished with it. If the IOC is generated from a pulse, make sure the pulse is wide enough that it is still present when you read the port during the interrupt service routine. The minimum pulse width will depend on your clock speed and level in the interrupt polling list. I hope this adds to some ideas. Cheers Reynard I said the RBIF is reset automatically. This is not the case with this peripheral and should be done in software after reading the port. Sorry about that.
  18. This possibly should be moved into the bug section but it is probably a typo. Header file novocfg_pic16t3e1ts2.h contains: #define MAX_TASKS 6 #define MAX_EVENTS 4 The naming convention fell over a bit here. The .lib is also built with these parameters for those who are wondering where all their RAM has gone (sucks up 80 bytes for the scheduler). Cheers Reynard Version 6.89
  19. Sorry Dave. Been working with Pre-emptive RTOS's too long. Regards Reynard
  20. If a task can be switched by a task with higher priority than the running task, both calling 'strcpy', then you may still have problems. Look at disabling interrupts around non-reentrant functions, write reentrant functions or write unique functions to do the same function as you did with the interrupt version of 'strcpy'. Some would same why are you doing 'strcpy' during an interrupt ? You could look at using a semaphore system if you are sharing a resource between tasks. You could try making tasks that use the same resource the same priority level. The RTOS may then wait for a yield point before swiching. Cheers Reynard
  21. Many learn the PIC using kits at college which have the PIC16F84 or similar basic device. These basic devices of course do not have fancy peripherals such as the ADC module, hence you do not learn how to use them. I can only presume the ADC inputs are default so the PIC resets into the lowest possible current mode (with perhaps the exception of the oscillator). A lot of PICs are used in portable, lithium coin cell powered devices. These devices usually sit in sleep mode waiting for someone to press the ON button to wake them up. Before entering sleep mode, the program shuts down all peripherals (internal and external), drops the clock rate to LC, makes output pins inputs. Only port pins that are required to wake the device up remain active (ON button for instance using an interrupt). Switching input pins to analogue mode also saves input pin current making the batteries last longer. I too have forgotten to turn off analogue mode several times, but you soon learn about it. Reading the PIC data sheet about the ports is always helpful. I/O ports are not all equal. Some pins are input only, some open drain, some have pull-ups, some have interrupts, SOME HAVE ANALOGUE INPUTS. Cheers Reynard
  22. Baixue, Here is something that I should have picked up on straight away. The analogue adc channel are selected on chip reset. Try setting ANSEL = 0 and ANSELH = 0 to turn all I/O ports into digital signals. Cheers Reynard
  23. Although adding the library by default may be a good thing it is not always required. The original question does not show any unresolved references. The original text does not show the linker being called up: success Executing: "C:\Program Files\SourceBoost\boostlink.pic.exe" "D:\PIC Projects\CAN\Boost\MPTest.obj" -O1 -p "MPLabTest" -t 16F877A BoostLink Optimizing Linker Version 6.89 http://www.sourceboost.com Copyright(C) 2004-2008 Pavel Baranov Copyright(C) 2004-2008 David Hobday Cheers Reynard
  24. Have you checked your language tool location path to the linker is ...\boostlink.pic.exe ? Cheers Reynard
  25. Your code runs OK using the simulator. The GIE bit is set (enabled again) automatically when the return from interrput instruction is executed so you have to do nothing. If you have the equipment check your oscillator is running correctly and other hardware connections. Cheers Reynard
  • Create New...