Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About JorgeF

  • Rank
    Super Enthusiast

Profile Information

  • Gender
  • Location
    ES @ Europe, third rock from the Sun
  1. Preprocessor Macros Do Not Work In Mplab-X V4

    Hi If my memory is not tricking me, that "item 2" refered a problem with the Sourceboost IDE and has nothing to do with MPLAB integration. Just my 2 cents... Best regards Jorge
  2. Update To Test_Bit

    Hi Any special reason to not use the bitwise not operator (~) or does it generate the same code^? Using a logical operator induces the compiler to do a type cast on the result of "test_bit" to a logical type (char or int) before checking its value. In strict 'C' the "!test_bit(...)" expression translates to something like "!(char)test_bit()" or "!(int)test_bit(...)" How about droping the old "test-bit()" and similar macros and using direct bit indexing, If I'm not worng its available since the first release of BoostC 7.xx AFAIK the "test_bit", "set_bit" and "clear_bit" macros have been deprecated several years ago. EDIT ADD: "semantics do matter!" Best reards Jorge
  3. Hi Thank you Pavel. So, if I understood it correctly all the important things are acounted for, its only missing optionals. All the registers relating to oscillator configurations, interrupts, memory paging/banking and other core features are defined. The compiler and linker do handle interrupts (context), the memory maps (ROM pages / RAM banks) and config words correctly, including the tricky dispatching code used by Novo. All I have to take care by myself are the peripherals. Good enought for me! EDIT ADD: BTW, I mostly use MPLAB 8/X Best regards Jorge
  4. Hi Pavel What exactly means "limited support" in the version log? Its something to do with the core processor or its only a libraries thing? Best regards Jorge
  5. Hi There is a awful lot of temporary variables. You are probably nesting several functions with many parameters. Can you show your code, we may be able to suggest some improvements. Best regards Jorge
  6. Pic16 Boostc Far Array Indexing Error

    Hi The problem must be related to the index size (-idx) of the compiler and linker command lines. But the option for an index size of 2 bytes is only available on the PIC18 compiler (large memory model). Looks like this RAM access improvement on the PIC16F1xxx family as created a problem for the PIC16 compilers. The pointer workaround works because the maths are done on the pointer variable and not on the indexing SFRs. Just my 2 cents on guessing... Best regards Jorge
  7. Pic16 Boostc Far Array Indexing Error

    Hi you can use a pointer as a workaround, it generates correct code. #include <system.h> unsigned char uc_arr[192]@0x2270; void main(void) { unsigned char cnt; unsigned char *ptr = uc_arr; for(cnt = 0; cnt < 192; cnt++) { *ptr++ = cnt; } } generated code (lines reordered in program flash address order) //////////////////////////////////////// // Code with no source :-) //////////////////////////////////////// 0000 2819 GOTO _startup for(cnt = 0; cnt < 192; cnt++) { 0009 01A0 CLRF main_1_cnt 000A label1 000A 30C0 MOVLW 0xC0 000B 0220 SUBWF main_1_cnt, W 000C 1803 BTFSC STATUS,C 000D 0008 RETURN *ptr++ = cnt; 000E 0822 MOVF main_1_ptr+D'1', W 000F 0085 MOVWF FSR0H 0010 0821 MOVF main_1_ptr, W 0011 0084 MOVWF FSR0L 0012 0AA1 INCF main_1_ptr, F 0013 1903 BTFSC STATUS,Z 0014 0AA2 INCF main_1_ptr+D'1', F 0015 0820 MOVF main_1_cnt, W 0016 0080 MOVWF INDF0 0017 0AA0 INCF main_1_cnt, F 0018 280A GOTO label1 } } 0019 _startup 0019 3180 MOVLP 0x00 001A 2804 GOTO main
  8. Hi Another detail. If your new system is Win10, its not enought to log in as administrator or with an account with administrator rights. You have to use the "command prompt in administrator mode". HIH Best regards Jorge
  9. Hi Most likely. I have a native 7.x licence that I already moved accross PC reinstalations, upgrades and even from one machine to another without any issues. Also I've seen the same behaviour in licencing on other software products, the upgrade licence needing the previous existence of the base licence. HIH Best regards Jorge
  10. Hi The problem is not to join the 2 ports under a single 16 bit variable as long as the 2 ports have concecutive addresses in RAM, , like exemplified by richardc. The real problem is beeing able to scan all the bits in a loop. The dot (.) operator when applied to bit access has a serious limitation, it doesn't acept a variable for the bit number. So you can access all 16 bits (x.0 to x.15) but you can't use the loop index to do it, only compile time constants. Best regards Jorge
  11. Hi Nice job, as a first approach for newbies. But exactly because it was published as a first trial example, I would leave here a few comments and sugestions about it for the newbies that will use it has a guide. = MASTER = Code is using RA1 as SS signal but schematic shows RA1 unconnected. What seems to be the SS signal is connected to RA2 in the schematic. In communications in general we do not assume the timing of the slave. What I suggest is that after sending the request, you keep sending "NULL" (0x00) repeateadly up to an sensible timeout, until the reply arrives. In a more elaborated application send the request as soon as possible, do any other stuff, ask for the reply (send NULL to generate the clock) only when necessary. Even so send the NULLs repeatadly until the reply is received or a sensible timeout occurs. For SPI comms is more eficient to test for the end of a transmition before sending and not after. This way you send one byte, go do something usefull while the SPI hardware does its job alone, and check for the end of transmition before trying to send the next byte. Chances are that when you get back to send the next byte you don't need to wait because the transmition as already finished. Instead of sspbuf = dat; while(!test_bit(pir1,3)){}; do it this way while(!test_bit(pir1,3)){}; sspbuf = dat; = SLAVE = Code is listening to RA7 for the SS signal from the master, but that pin doesn't even exist. What seems to be the SS signal in the schematic is conected to RA5. Code is oscilating RA0 with 150mS period but there is nothing connected to it. If it was for flashing a LED then its connected to RA1. = PIC = The PIC18F4520 features accessible output latch registers (lat_) so instead of writing to the "port_" we should write to the "lat_". = BOOST C = As of ver 7.xx of BoostC the macros "set_bit", "clear_bit" and "test_bit" are deprecated. Versions 7.xx of BoostC support the dot (.) syntax for accessing the bits in a byte, like if the byte was a structure. = C = You don't need an empty blocks "{}" when there is nothing to do. = PROGRAMMING ANY LANGUAGE = Don't use "magic numbers" in the code, they make it very confusing even for yourself when you get back in a couple of months. Its better to define sensible names for any used constants, and even better to use them when they were already defined for you, like with the PIC pins and SFR register bits. Given the above: set_bit(porta, 0); would become porta.RA0 = 1; and while(!test_bit(pir1,3)){}; should be while(!(pir1.SSPIF == 1)); To me it looks much more readable. EDIT ADD: The SPI bus is supposed to be shared by multiple slaves. So in order to be shared by several slaves, each slave must keep its SDO line in high impedance (input) until it detects its the SS signal. Then it can set SDO to output for the duration of the SS signal, and then set it to input again. Don't forget to keep an eye in the SS signal the whole time as it can be removed even with the communication in progress due to an hardware failure or the master aborting the communication. BTW, SDO (serial data out) id the naming convention for the I2C protocol, the correct name for that line in terms of the SPI protocol is MISO (master in slave out). But has the MSSP of the PICs implements both protocols, the mix is acceptable in the context. EDIT CORRECT: Missing "!" in the last example. Just my 2 cents.... Best regards Jorge
  12. Pic18F26K22 Eusart Receive Bug

    Hi Yes, I've BTDT, and still do it from time to time. But I tend to agree with the SB approach. One of the least disputed "de facto rules" of code stiling is that full uppercase names are for constants. This rule was already out there when I started to learn programming, more than 35 years ago. And I never saw it discussed on anything I've read about code stilling and its evolution since then. But some "enlightened brain" in Microchip decided that the names of the SFRs should match the way they are written in the datasheet, a kind of an "housewife approach" that, in M$ theory, would make it easier for the user. Like any big company they act like they own the world and the truth, and we get stuck with their silly ways. As for flagging it with a warning, or better, not flagging it, its perfectly correct, besides beeing an error in this specific situiation (program logic), its not an error in "C", neither syntatic or semantic, its simply an assignement of a constant value to a variable wich is perfectly legal. EDIT: Typos corrections. Just my 2 cents... Best regards Jorge
  13. Pic18F26K22 Eusart Receive Bug

    Hi I spotted at least one bug in the posted code that is enought to mess things. You are loading "tempByte" with the address of the receive register and not with its contents, and echoing back that value (truncated to the lower 8 bits) instead of the received character. 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". Extracted from "...\program files\sourceboost\include\pic18f26k22.h" #define RC1REG 0x00000FAE ....... volatile char rc1reg @RC1REG; The SB convention is uppercase for numeric constants (addresses) and lowercase for the variables that access the registers at those addresses. Just like with "pir1","ansela", "anselb",....., and so on (Boost C user manual). Besides that, by not reading the contents of the receive register RC1IF never gets cleared (can't be cleared in code only by reading the receive register - section @ page 265 of the datasheet), so the PIC will send back an endless string of garbagge (0xae) after receiving the first character. Another thing to keep an eye on. The PIC18F26K22 errata shows 2 silicon bugs on the USART (section 6 @ page 5). 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. HIH Best regards Jorge Another thing to keep an eye on. The PIC18F26K22 errata shows 2 silicon bugs on the USART (section 6 @ page 5).
  14. Pic18F26K22 Eusart Receive Bug

    Hi Well... I'm not one of the authors, but... Can you show us show code, maybe from one of the small test apps you made. Best regards Jorge
  15. Hi I would not expect to find a math library for an 8 bit PIC with more than the 4 basic operations and even so only for integers. Floating point powers are a bit too hard for an 8 bit PIC. That is a job for a 16 or 32 bit PIC. Given that, I already faced such a chalenge in a real world application (a lab tool). But by looking at the forest rather than the tree, I end up with a PIC for raw data aquisition and a PC for the heavy processing. I've also seen another approach by someone else, an 8 bit PIC for data aquisition and a "Raspeberry Pi" for the heavy work (maths+storage+network). If you "really" need to use the PIC for the maths, than a mix of processing and data tables can do the trick. Remember your maths, in special logarithms and exponentiation. You can reduce the "pow" to product/quotient and the product/quotient to sum/subbtration. Also the floating point numbers can be reduced to fixed point integers to a given precision. This way you may be able to do the trick with only a logarithmic table. In terms of table sizes, I frequently manage to keep them in a controled size by simulating the problem in a spreadsheet and reducing the ranges and resolution to what is really needed for a given project. Another thing that helps in saving processing time is to keep in mind what kind of precision is "really" necessary for a given application. Just in case you need a quick refresh.... https://mathvault.ca/logarithm-theory/#scale HIH Best regards Jorge