Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Reynard

  1. 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
  2. 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
  3. Well explained reason Bill. A simple 'Invalid Symbol' or something would have explained the error better though. Cheers Reynard
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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).
  13. It's the fine print that gets you every time Reynard
  14. 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
  15. 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
  16. 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.
  17. 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
  18. Sorry Dave. Been working with Pre-emptive RTOS's too long. Regards Reynard
  19. 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
  20. 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
  21. 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
  22. 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
  23. Have you checked your language tool location path to the linker is ...\boostlink.pic.exe ? Cheers Reynard
  24. 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
  25. I will add some more suggestions to the pot. I think I read somewhere that all 18F chips are flash and therefore can write to their own program memory. As said above, you can use a SD memory device with a FAT system on board but this is a large overhead on the bootloader as asmallri says. A parallel external flash device is not practical due to the large pin count needed for the address and data lines. There are plenty of serial flash chips with an SPI interface built in. These come in 8 pin packages (SO8 or similar) and many are 3.3Vish so watch out if you are using a 5V system. SPI flash chips are usually paged into 256 byte blocks. The SPI interface has a small command set to allow you to specify which page to write to or read from etc. The bootloader would be installed into your PIC starting from the reset vector (address 0000) up to say 0x07ff, which seems to be common although 2K may be a bit large for a simple bootloader. It hay have something to do with code page protection size. Some PICs have a bootloader section that can be protected from inadverant writes. Check the data sheet for the PIC use intend to use. Page 0 of the flash chip may contain your product identification record. The first 8 bytes could be a set data pattern that the bootloader recognizes as a valid flash chip for your particular PIC application board. The rest of the record could contain software version, dat/time stamp, start/end addresses etc. The rest of the pages from page 1 onwards will contain your program data. You may wish to create a record system within each 256 byte page giving: load address, record length, data block, CRC-16 for data integrity. At start up your bootloader will try to read the first 8 bytes from page 0 to see if there if a device out there that it recognizes. If not, it checks if there is a an application program installed. If so run the application starting at say address 0x0800. If there is a recognizable flash device out there, read in the id record, check if it is newer than the installed application (if there is an installed application), read and flash the new application into the PIC, flag application installed and run it or wait for the flash card to be removed and reset to run the application. Note: You cannot run code from EEPROM within the PIC as it is only 8 bits wide and not directly accessible by the CPU. You will also need a programmer and PC application to take the BoostC hex file and write it to the mobile flash device. I hope this adds to your collection of ideas. Cheers Reynard
  • Create New...