Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Sparky1039

  • Rank

Profile Information

  • Location
    Colorado USA
  1. Pic18F26K22 Eusart Receive Bug

    // In the include file "pic18f26k22.h", "RC1REG" is defined as a constant with the value "0xfae", the address of the receive register for EUSART1. The register itself is accessed with "rc1reg". Yes, you are right about the RC1REG identifier. I had it upper case and as you pointed out it needs to be lower case. This is was an artifact of porting back and forth between SB and XC8 and hence the illusion of being a bug. I'm surprised SB didn't flag this as a warning. If anything I wish there were more consistency by compiler makers on hardware register naming conventions. Either way good catch on this. The clue was right there in front of me when the received byte was 0xAE. If I had only put the register address and the truncated result together I could have saved myself a lot of grief and delay. // BTW, you don't need the 20 uS delay, the transmit and receive sections of the EUSART are independent, so there is no risk of chocking it by overlapping operation. Yes I know. I added the delay and extra variable for debugging purposes only so I can set a break point more easily vs. through a watch window conditional in order to view register and variable contents. // Another thing to keep an eye on. The PIC18F26K22 errata shows 2 silicon bugs on the USART (section 6 @ page 5). I am aware of these and currently using A4 silicon with no problems. Thanks for the help
  2. Pic18F26K22 Eusart Receive Bug

    The problem is my UART functions are a compiled library so there isn't much to see. I have been using this library for years without issue on many different 8-bit PICs (16F and 18F). It's only with the recent use of the 26K22 have I encountered this problem. I've ported my project over to Mchip XC8 and everything is working fine so I don't have high incentive to spend much effort on debugging this problem. However when time permits I may put together a special simplified test code block example. UPDATE: test code below. // UART receive bug test code. // Target: PIC18F26K22 // SourceBoost C V7.30 #include <system.h> #pragma CLOCK_FREQ 12000000 #pragma OPTIMIZE "1" #pragma config FOSC = HSMP, FCMEN = OFF, IESO = OFF, PLLCFG = OFF, PRICLKEN = ON #pragma config BOREN = OFF, BORV = 250, PWRTEN = ON #pragma config WDTEN = OFF, WDTPS = 256, PBADEN = OFF #pragma config MCLRE = EXTMCLR, HFOFST = ON #pragma config STVREN = ON, LVP = OFF, XINST = OFF #pragma config DEBUG = OFF, CCP2MX = PORTC1, CCP3MX = PORTB5 char tempByte = 0; void main () { trisa = 0x00; trisb = 0x00; trisc = 0x90; ansela = 0x00; anselb = 0x00; anselc = 0x00; pie1.RC1IE = 0; pir1.RC1IF = 0; baudcon1.BRG16 = 1; spbrg = 25; // 115200 baud spbrgh = 0; rcsta = 0x90; txsta = 0x24; while (1) { while (!pir1.RC1IF) asm nop; tempByte = RC1REG; delay_us (20); txreg1 = tempByte; // echo back char delay_us (20); } } SB UART Test.zip
  3. Pic18F26K22 Eusart Receive Bug

    I believe I have uncovered a compiler bug with the EUSART receive peripheral on the PIC18F26K22. Working on a larger application I found that my tried and true UART receive library functions were not working properly. However, the transmit processes do work correctly. Thinking I may have made some simple mistake I wrote a smaller test application to validate that my project code wasn't the culprit. This test code exhibited the same problems, lack of receive response. I then ported this test code over to another compiler and it worked perfectly. Analyzing the problem with Proteus VSM the SourceBoost version is not reading the RC1REG register. I see the RC1IF interrupt flag get set but when the code reads the RC1REG receive register I see garbage. On top of this, since it's not reading the register contents the receive interrupt flag never gets auto-cleared. So my code is stuck reading the same garbage bytes (0xAE) forever, locking up the PIC from processing other tasks except for higher priority interrupt processes. When I monitored the test code with Proteus from the other compiler I see proper operation. As a secondary check I also tried this test code on real hardware and the behavior is exactly mirrors Proteus. I haven't studied the ASM output in great detail to maybe see where the problem lay, and honestly don't have time to do it. I need to focus on porting my application over to another compiler so I can get my project completed on time. Hopefully the SB authors can take a look into this area and offer a quick fix saving me a lot of work porting.
  4. Sorry, I mistakenly placed my bug report in the wrong place. It has now been moved to the appropriate forum location.
  5. Thanks Jorge. After pondering the issues it became very obvious that it wasn't possible to do this kind of number crunching with a small 8-bit PIC. Exponentiation generates such enormous sized numbers that 64-bit variables are a must. Even if I could get the 8-bit PIC to deal with this math it would take equally large amounts of time to process it, completely negating the whole purpose of the exercise. Even a big lookup table would seen lightning fast in comparison. So that was the route I have taken, and by applying a binary tree search process it actually isn't so bad time wise. Cheers.
  6. I couldn't find anything in the documentation indicating that SB supports the C math library which has the POW(x,y) function. What I'm trying to do is compute this equation... y = 52080 x^-0.8754 (note X is an unsigned integer variable) It is a curve fit formula of a non-linear transform. My goal is to see how computationally intensive this is and if it's worth developing a look-up table as an alternative approach. The issue with the lookup table is the amount of memory I have available (both ROM or RAM). External RAM/EEPROM may work but the timing delay involved scanning a couple hundred points could be prohibitive. On the other hand perhaps someone has a better approach to efficiently compute this equation. Thanks
  7. SB UART library is designed only for those PIC's that contain a UART (EUSART) hardware module. See users manual for details. It does not offer software UART capability. To create you own software UART transmit output, it's really a simple matter of applying a timer set up to generate an interrupt every 416uS indicating when to write a data bit to a port pin (+ start and stop bits too).
  8. V7.11 Rc1

    Will there be a version log update for this release? I'm interested to know what the fixes/changes are before using. thx
  9. Silly Ide Typedef Question

    Thx. Didn't think so but want to check anyway. Perhaps this could be a feature added to the IDE whereby user defined typedefs could be added to the highlighter list.
  10. Is there a way to tell the IDE to highlight a user specified typedef? For example the declaration "unsigned char" will be highlighted in a different color, but if I declare typedef unsigned char uint8_t the new typedef name will be normal text color. Any way to make uint8_t get the color highlight too? thx
  11. Thanks Reynard. I went with this and it seems to work correctly and is very fast. However I may revert to the example you provided for the long term since it's more flexible for different data types. unsigned int sqrt32 (unsigned long n) { unsigned long c = 0x8000; unsigned long g = 0x8000; for(; { if(g * g > n) g ^= c; c >>= 1; if(c == 0) return g; g |= c; } }
  12. Unfortunately Boost C math library doesn't support the square root function for a data type greater than unsigned int. I'm looking for some suggestions or code examples on how to accomplish the square root of an unsigned long. Currently working on a project where the customer has requested code enhancements that calculate standard deviation of 12-bit ADC sensor readings. The averaged sum of squares value can be quite large hence the unsigned long data type. Any help would be appreciated. thx Sparky
  13. Dual Clock Frequencies?

    I suspected as much. I just want to be sure I wasn't missing a PP directive somewhere that allowed for this capability. In my case it's not a big deal to scale the delays appropriately (in this case 6x). With most PIC's hosting multiple clock sources nowadays I thought maybe industry compiler developers would have offered this kind of flexibility to support them. Thanks
  14. Question, does Boost C support dual clock frequencies for the final compiled code? I looked in the help file and found nothing, but wanted to ask here. My project uses two primary clock frequencies, one at 2 MHZ (INTOSC), and another at 12MHZ (external crystal). It's a ultra low power sensing device that uses the 2MHz clock for data gathering from sensors (SPI, internal ADC ect...) and periodically will switch over to 12MHz for high speed serial coms (230.4Kbaud). I use a bunch of delays in code for both clock frequencies and I wish to preserve the values as they are. But obviously if I compile for 12MHz delays the 2MHz delays will be fast and vice versa. So the question is can I compile using PP directives for both clock frequencies and keep the delays correct? Of course I can always scale the requisite delays to match the fast/slow clock frequency but this seems messy and prone to mistakes because each are hand tweaked and I could easily forget one. Any suggestions? thx
  15. Preprocessor Error

    Thanks Pavel. Explaining what to look for made finding the error easier to spot, which I did in less than 2 mins worth of searching.