Jump to content

Sparky1039

EstablishedMember
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Sparky1039

  • Rank
    Regular

Profile Information

  • Location
    Colorado USA

Recent Profile Visitors

618 profile views
  1. By the lack of any forum activity or updates from the compiler authors over a significant amount of time it appears SourceBoost products are now abandon ware. Too bad... 😡
  2. Can some one tell me what error code 133 "failure" means? I keep getting this error when trying to compile a project. It's associated to a *.h file line #133. I'm not sure what I did to break my code which compiled ok before, but after a bunch of edits I can't seem to figure out what I did to generate this error. The error "failure" seems a bit vague. Using SB 7.42 Also is there a document listing of all the error codes this compiler can generate? thanks Edit. I found the problem: I had mistakenly declared an emum element the same as a function name.
  3. // 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 o
  4. 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 // Source
  5. 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 Sour
  6. Sorry, I mistakenly placed my bug report in the wrong place. It has now been moved to the appropriate forum location.
  7. 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.
  8. 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
  9. 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).
  10. Will there be a version log update for this release? I'm interested to know what the fixes/changes are before using. thx
  11. 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.
  12. 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
  13. 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; } }
  14. 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
  15. 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
×
×
  • Create New...