Jump to content

cac001

EstablishedMember
  • Content Count

    183
  • Joined

  • Last visited

Everything posted by cac001

  1. Asking for this kind of help means this LCD project is too complex for your level of experience. Use a very simple project to gain understanding of how to use the SourceBoost tools.
  2. I tried what you suggested but I cannot get TIMER0 to count from and external input. The next thing I tried was to use a PIC18F4550 as the target and RA4 as the T0CKI input. I connected a button plugin to RA4 and toggled it on and off but never saw TIMER0 count. Maybe I do not know how to get the simulator to see a change on T0CKI. There does not seem to be much in the way of details on how to use the simulator in the SourceBoost IDE documentation.
  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.
  4. Dave, I looked at the \SourceBoost\config\PIC18F46J50.tdf file and it does have issues. This is at the end of the file TargetConfig FOSC { // Oscillator Selection bits: ConfigRegAddr = 0x0000FFF8; ConfigBitMask = 0b00001111; ConfigSettings = 0b00000000, "LP","LP oscillator", 0b00000001, "XT","XT oscillator", 0b00000010, "HS","HS oscillator", 0b00000011, "RC","External RC oscillator, CLKOUT function on RA6", 0b00000100, "EC","EC oscillator, CLKOUT function on RA6", 0b00000101, "ECIO6","EC oscillator, port function on RA6", 0b00000110, "HSPLL","HS oscillator, PLL enabled (Clock Frequency = 4 x FOSC1)", 0b00000111, "RCIO6","External RC oscillator, port function on RA6", 0b00001000, "INTIO67","Internal oscillator block, port function on RA6 and RA7", 0b00001001, "INTIO7","Internal oscillator block, CLKOUT function on RA6, port function on RA7"; } This is just wrong. It's likely wrong in all of the PIC18F parts that use this new method of addressing the configuration bits. I checked the rest of the configuration word addresses and bit positions and they seem correct but the cinfiguration words generated by the compiler and linker are still wrong. Your implementation of the Microchip "#pragma config" is bad. It does not work and fixing the .tdf file does not help. This is a bug. This code works in C18: /* Author: Charles Ader Date: 2010-APRIL-28 File: main.c Target: PIC18F46J50 OS: WinXP, SP2 MPLAB 8.50 Compiler: C18 v3.35 */ #include <p18Cxxx.h> #pragma config XINST = OFF #pragma config STVREN = OFF #pragma config PLLDIV = 2 #pragma config WDTEN = OFF #pragma config CP0 = OFF #pragma config CPUDIV = OSC2_PLL2 #pragma config IESO = OFF #pragma config FCMEN = OFF #pragma config LPT1OSC = ON #pragma config T1DIG = OFF #pragma config OSC = INTOSCPLL #pragma config WDTPS = 32768 #pragma config DSWDTPS = G2 #pragma config DSWDTEN = OFF #pragma config DSBOREN = OFF #pragma config RTCOSC = T1OSCREF #pragma config DSWDTOSC = INTOSCREF #pragma config MSSP7B_EN = MSK7 #pragma config IOL1WAY = OFF #pragma config WPCFG = OFF #pragma config WPEND = PAGE_WPFP #pragma config WPFP = PAGE_63 #pragma config WPDIS = OFF void main( void ) { /* wait here forever */ for(;; ); } This code fails with BoostC: /* Author: Charles Ader Date: 2010-APRIL-28 File: main.c Target: PIC18F46J50 OS: WinXP, SP2 SouceBoost IDE 6.97RC3 Compiler: BoostC Optimizing C Compiler Version 6.97 (for PIC18 architecture) */ #include <system.h> #pragma config XINST = OFF #pragma config STVREN = OFF #pragma config PLLDIV = 2 #pragma config WDTEN = OFF #pragma config CP0 = OFF #pragma config CPUDIV = OSC2_PLL2 #pragma config IESO = OFF #pragma config FCMEN = OFF #pragma config LPT1OSC = ON #pragma config T1DIG = OFF #pragma config OSC = INTOSCPLL #pragma config WDTPS = 32768 #pragma config DSWDTPS = G2 #pragma config DSWDTEN = OFF #pragma config DSBOREN = OFF #pragma config RTCOSC = T1OSCREF #pragma config DSWDTOSC = INTOSCREF /* #pragma config MSSP7B_EN = MSK7 ** this pragma config does not work **/ #pragma config IOL1WAY = OFF #pragma config WPCFG = OFF #pragma config WPEND = PAGE_WPFP #pragma config WPFP = PAGE_63 #pragma config WPDIS = OFF void main( void ) { /* wait here forever */ for(;; ); }
  5. Here are four methods to toggle bit RA0: while (1) { lata.0 ^= 1; delay_ms(2); } 00E6 label4 00E6 7089 BTG gbl_lata,0 00E8 0E02 MOVLW 0x02 00EA 6E0C MOVWF delay_ms_00000_arg_del 00EC EC0EF000 CALL delay_ms_00000 00F0 D7FA BRA label4 while (1) { lata ^= 0b00000001; delay_ms(2); } 00E6 label4 00E6 0E01 MOVLW 0x01 00E8 1A89 XORWF gbl_lata, F 00EA 0E02 MOVLW 0x02 00EC 6E0C MOVWF delay_ms_00000_arg_del 00EE EC0EF000 CALL delay_ms_00000 00F2 D7F9 BRA label4 while (1) { lata.0 ? lata.0 = 0 : lata.0 = 1; delay_ms(2); } 00E6 label4 00E6 A089 BTFSS gbl_lata,0 00E8 D002 BRA label5 00EA 9089 BCF gbl_lata,0 00EC D001 BRA label6 00EE label5 00EE 8089 BSF gbl_lata,0 00F0 label6 00F0 0E02 MOVLW 0x02 00F2 6E0C MOVWF delay_ms_00000_arg_del 00F4 EC0EF000 CALL delay_ms_00000 00F8 D7F6 BRA label4 while (1) { lata.0 = ~lata.0; delay_ms(2); } 00E6 label4 00E6 0EFF MOVLW 0xFF 00E8 B089 BTFSC gbl_lata,0 00EA 0EFE MOVLW 0xFE 00EC 6E0C MOVWF CompTempVar592 00EE B00C BTFSC CompTempVar592,0 00F0 8089 BSF gbl_lata,0 00F2 A00C BTFSS CompTempVar592,0 00F4 9089 BCF gbl_lata,0 00F6 0E02 MOVLW 0x02 00F8 6E0C MOVWF delay_ms_00000_arg_del 00FA EC0EF000 CALL delay_ms_00000 00FE D7F3 BRA label4 The method you are using seems to generate the most code. This code will cause the delay to be just a bit longer than you may expect but I do not see a reason for the delay to be incorrect. All of them seem to toggle RA0 at about 250Hz. Perhaps there is something else in your complete code that is affecting the delay function.
  6. Bug description: The #pragma config for the PIC18F46J50 fails to set the configuration bits correctly. Steps to reproduce: Use this configuration: #pragma config XINST = OFF #pragma config STVREN = OFF #pragma config PLLDIV = 2 #pragma config WDTEN = OFF #pragma config CP0 = OFF #pragma config CPUDIV = OSC2_PLL2 #pragma config IESO = OFF #pragma config FCMEN = OFF #pragma config LPT1OSC = ON #pragma config T1DIG = OFF #pragma config FOSC = INTIO67 #pragma config WDTPS = 32768 #pragma config DSWDTPS = G2 #pragma config DSWDTEN = OFF #pragma config DSBOREN = OFF #pragma config RTCOSC = T1OSCREF #pragma config DSWDTOSC = INTOSCREF /* #pragma config MSSP7B_EN = MSK7 ** this pragma config does not work at all **/ #pragma config IOL1WAY = OFF #pragma config WPCFG = OFF #pragma config WPEND = PAGE_WPFP #pragma config WPFP = PAGE_63 #pragma config WPDIS = OFF Load the HEX file with MPLAB observer that: PLLDIV is not set correctly CPUDIV is not set correctly DSWDTOSC is not set correctly WPFP is not set correctly WPEND is not set correctly The problem 100% reproduceable. IDE version: SouceBoost IDE 6.97RC3 Compiler: BoostC Compiler version: BoostC Optimizing C Compiler Version 6.97 (for PIC18 architecture) Target device: PIC18F46J50 OS: WinXPsp3
  7. If we regard the exit code in hex it is: 0xC0000005 I searched google with "windows hresult C0000005" or this link. After looking at a few of them this error may be a result of a failure of some other service in your windows system. You should check the event log to see of there is something odd going on.
  8. I'm sure that tejaswiyvs appreciates your reply. The content of your reply is a tad short on helpfulness. You could have mentioned that the header files for BoostC follow a long accepted convention where #define constants are always UPPER_CASE though the other popular C compilers for the PIC16F targets define the Special Function Registers with upper case. You may have gone farther saying that BoostC is more correct in the wider sense it is more trouble for a beginner to PIC and C programming because example source code from other PIC environments will not compile without changing the case of the Special Function Register names. Just trying to help.
  9. Picixe, danmc77, The PLL in the 18F4550 is a little more finicky. It is designed to multiply a 4MHz input to 96MHz. This is a 24x multiply. For this PLL to work well the input must be very close to 4MHz. Anything faster or slower runs the risk fo the PLL locking on to an alias of 4MHz. When using the PLL you are limited to crystals or oscillators that are 4MHz multiples of the PLL Prescaler selections of divides by 1, 2 , 3, 4, 5, 6, 10, and 12. This means frequencies of 4, 8, 12, 16, 20, 24, 40 and 48 MHz. If your crystal is not one of these then the PLL may not work. If you are going to use USB then you must use the Primary oscillator at one of those frequencies and set the PLLDIV configuration bits correctly.
  10. cac001

    Bit Access Bug...

    Definitely not a bug: ;Address Opcode Disassembly ; 052 1623 BSF 0x23, 0x4 ; 053 14A4 BSF 0x24, 0x1
  11. Not portable code - if you are worried about that sort of thing. I would go for something like: char x = 0; do { ... ... } while( --x != 0 ); Regards Dave This is just a little more portable: char x = 0; do { ... ... } while((++x & 0xFF) != 0 ); Most compilers implement char as 8-bits. I am working with an embedded platform that has no 8-bit addressable registers or memory. Your example is not portable to this implementation.
  12. It may not be possible to alter configuration words from the bootloader context. Are you sure that your PIC is able to change configuration words while a program is running?
  13. I would like to help but there are some choices that only you can make. Depending on what you choose the fuse setting will become obvious. The PIC18F2550 has support to expose a USB endpoint. If you are developing a USB device you cannot use the internal oscillator as a clock source for the USB function block. You must use an external crystal or oscillator. If you are not using the USB and do not want an external crystal then the internal oscillator is your only clock choice. The maximum frequency available with the internal oscillator is 8MHz. So now you need to decide what you need the PIC18F2550 to do for you. Will you need USB? How quickly does the PIC need to respond to inputs? How fast does the output need to be? When you have made these choices, plus a whole bunch more you will have an good idea of what way the configuration need to be set.
  14. You may want to look at this site too: http://www.electronic-engineering.ch/micro...s/projects.html
  15. A reset should not be required, but a lot of USB hosts will power down when the last device disconnects. This is not too common on desktops but is typical for laptops. If your device is not self powered then when the host powers down the port your PIC will loose power too.
  16. Joachim, This is the wrong place to ask for example programmes using FlowCode. FlowCode is a graphical programming language made by Matrix Multimedia. You should be asking your questions here: Martix Multimedia FlowCode forums
  17. The answer is simple. The 16F88 has analog I/O that is enabled by default. This code is from the Microchip datasheet (DS30487C), section 5.1: BANKSEL PORTA; select bank of PORTA CLRF PORTA; Initialize PORTA by ; clearing output ; data latches BANKSEL ANSEL; Select Bank of ANSEL MOVLW 0x00 ; Configure all pins MOVWF ANSEL; as digital inputs MOVLW 0xFF ; Value used to ; initialize data ; direction MOVWF TRISA; Set RA<7:0> as inputs Try changing your init function: static void init( void) { porta = 0; ansel = 0; // <--- add this to your init fuction. cmcon = 7; // <--- add this to your init fuction. portb = 0; trisa = 0b00100100; trisb = 0b11000001; osccon = 0x72; }
  18. You did not seem to get a response from Dave or Pavel, so here is my work around: ;///////////////////////////////////////////////////////////////////////////////// ;// Code Generator: BoostC Compiler - http://www.sourceboost.com ;// Version : 6.81 ;// License Type : Pro License ;// Limitations : PIC12,PIC16 max code size:Unlimited, max RAM banks:Unlimited ;///////////////////////////////////////////////////////////////////////////////// // File: bug22.C // Target: PIC16F88 // OS: WinXP, SP2 // SourceBoostIDE: 6.81 // Compiler: BoostC 6.81 // Reproducible: always // Expected behavior: // ALL (or no) instances of the local variable "byte" // should have been replaced by "CompTempVarRet495". // // Workaround: // change bit set to bit-wise or // #include <system.h> unsigned char input_byte( void ); volatile unsigned char out; void main() { out = input_byte(); 0011 2003 CALL input_byte_00000 0012 0822 MOVF CompTempVarRet495, W 0013 00A0 MOVWF gbl_out for(;;); 0014 label268438922 0014 2814 GOTO label268438922 } #define WORK_AROUND #define DATA1 porta.2 //I/O #define CLK1 porta.1 //out #pragma OPTIMIZE "a" unsigned char input_byte( void ) { unsigned char j; unsigned char byte; // The do { ... } while form is shorter // for ( j = 0; j < 8; j++ ) j = 8; 0003 3008 MOVLW 0x08 0004 1283 BCF STATUS, RP0 0005 1303 BCF STATUS, RP1 0006 00A1 MOVWF input_byte_00000_1_j do 0007 label268438906 { byte <<= 1; 0007 1003 BCF STATUS,C 0008 0DA2 RLF CompTempVarRet495, F #ifdef WORK_AROUND if (DATA1) byte |= 1; 0009 1905 BTFSC gbl_porta,2 000A 1422 BSF CompTempVarRet495,0 #else byte.0 = DATA1; #endif CLK1 = 1; 000B 1485 BSF gbl_porta,1 CLK1 = 0; 000C 1085 BCF gbl_porta,1 } while ( --j != 0 ); 000D 03A1 DECF input_byte_00000_1_j, F 000E 1D03 BTFSS STATUS,Z 000F 2807 GOTO label268438906 return byte; } 0010 0008 RETURN //////////////////////////////////////// // Code with no source :-) //////////////////////////////////////// 0000 2815 GOTO _startup 0015 _startup 0015 118A BCF PCLATH,3 0016 120A BCF PCLATH,4 0017 2811 GOTO main I hope this helps a little.
  19. It looks like a bug when bit-wise operators are used in a case expression. /* File: bug21.C Target: PIC16F876A OS: WinXP, SP2 SourceBoostIDE: 6.81 Compiler: BoostC 6.81 Reproducible: always Expected behavior: compile without error Description: case statment reports a compile error when bit-wise operator is used in expression. "case (I2C_STATE_1):" reports an error "case ((1 << S | 1 << BF)):" reports an error "case (0x08 | 0x01):" reports an error changing #define for I2C_STATE_1 to an enum is a work around */ #include <system.h> #define SSPSTAT_MASK (1 << D_A | 1 << S | 1 << R_W | 1 << BF) //#define I2C_STATE_1 (1 << S | 1 << BF) enum { I2C_STATE_1 = (1 << S | 1 << BF) }; void main(void) { } void I2C_SerialInterrupt(void) { pir1.SSPIF = false; // clear interrupt flag. switch (sspstat & SSPSTAT_MASK) { // case ((1 << S | 1 << BF)): // case (0x08 | 0x01): case (I2C_STATE_1): break; } // end switch. } void interrupt(void) { if (pir1.SSPIF) { // I2C interrupt ? I2C_SerialInterrupt(); // yes, process I2C interrupt. } }
  20. ra68gi is a most honorable person. Thank you for the check that arrived today. Regards, cac
  21. The pointers for the "rom" storage class do not work like other pointers. There are several limitations that are not obvious. See this thread: http://forum.sourceboost.com/index.php?s=&...post&p=7891 And this thread: http://forum.sourceboost.com/index.php?s=&...post&p=7886 cac001
  22. The C standard lib function "puts" appends a carriage return and line feed to the string on output. This is a snippet from rs232_driver.h from the SourceBoost includes: void puts(char *source) { while (*source != 0) // wait until tx register is empty putc(*source++); putc(0x0d); putc(0x0a); } The code above shows where the CR and LF are comming from.
  23. The difference is that _INTOSC provides the FCYC clock output on the RA4/AN3/T1G/OSC2/CLKOUT pin. This should have no affect on the ADC but perhaps your circuit has something connected to the RA4 pin that will be an issue if the PIC were to drive this with a 1MHz clock.
  24. Using both IDEs (MPLAB and SourceBoost) and I compiled this code: // File: t3254p12300.c // Target: PIC16F684 // OS: WinXP, SP2 // MPLAB IDE: 7.62 interim // SourceBoostIDE: 6.80 // Compiler: BoostC 6.80 #include <system.h> unsigned int minimum = 0xFFFF; //local variable to store minimum time char i,j; //counters unsigned int sensor_time[5]; //array to store processed sensor measurement void main() { sensor_time[0] = 0x093D; sensor_time[1] = 0x08CD; sensor_time[2] = 0x08DE; sensor_time[3] = 0xFFFF; sensor_time[4] = 0xFFFF; for(i=0;i<=4;i++) //find minimum value of sensor_time[i] { if(sensor_time[i]<minimum) { minimum=sensor_time[i]; } } for(;;); } It does not display the fault you described. You may have a bug somewhere else in your code.
  25. These PICs have very limited RAM and stack. You may want to think about using assembly to the 12F510/16F506 PIC. They are just like the 16F54 type PICs with just a little more program space. It does not seem that BoostC supports the low end 12-bit, 2-level stack PICs.
×
×
  • Create New...