Jump to content

JorgeF

EstablishedMember
  • Content count

    287
  • Joined

  • Last visited

Everything posted by JorgeF

  1. Hi There is one thing in your logic that you might want to re-evaluate. I wouldn't trust a compiler to organize the code space in a continuos block, most of the ones I know do spread chuncks of code all over the place just to optimize for the addressing scheme of the PIC (mnimize pagging). The same spreading, for the same reasons, might be found with RAM usage. If you intend to use some part of your flash memory for data you would better reserve it. Use the "-rt" command line switch to limit the maximum address available for the program and use the flash above that address for runtime data (NVM). A work around for your initial question can be to adjust the top of rom (-rt) close the the actual size of your release code and calculate the CRC from "0x0000" up to your "-rt" value. You can calculate the CRC verification from the data on the HEX file as it is a byte image of what will be recorded in the program flash. BTW: Make sure you do program your release code on blank chips so you can use the erased value of the flash in your CRC calculation. Just my 2 cents of it.... Best regards Jorge
  2. Hi I usually find that kind of information on the HEX file used to program the PIC. If you tell us what is your goal, maybe there are other ways, besides finding the last used flash address, to achieve it. Best regards Jorge
  3. License Registration not working

    Hi Assuming those object files are part of your code, the linker might be trying to reuse them without a new compilation. Just force a full recompilation of all the source code. Best regards Jorge
  4. Hi Yes I wrote that, but I also worte... And this comes from my assembly programming experience. When it comes to 8 bit PICs, I have a lot more finished products written in ASM than in 'C'. Bit scanning needs often surface whenever you have an array of sensors, a keyboard or even LED arrays like in 7 segment displays. On all those situations, no matter how many tricks i come up with, the individual bit access ends up being more costly (instruction cycles and program memory) than bit mask based operations. So my experience showed me that it can be done but its not worth the effort. I don't se this as an universal truth, simply an 8 bit PIC specific (hardware architecture and instruction set) conclusion. Give me a different microcontroller and I would, probably, end up with a different conclusion. I also have a large experience in high level programming on desktop systems (C, C++, VB, Java, ...) and I happily port algorithms and code design accross different hardware platforms and operating systems. But programming an 8 bit PIC is a totally different ball game, there is no hardware abstraction at all. The ball game also changes deeply when moving from 8bit PICs to 16bit PICs or to 32bit PICs. The platforms are so different that even using "C" or "C++" one needs to adjust the algorithms, data structures and even the whole conceptual approach to program design. Just my 2 cents.... Best regards Jorge
  5. Hi Your codding seems a bit odd, to say the least. Assigning independent addresses to the fields of a struct is against the basic semanthics of a struct. I suspect the compiler is simply ignoring it and a warning is missing, maybe some inactive (disabled) warning. In terms of assigning fixed addresses to variables, what you can do is to assign an address to a variable of type struct (MyPortStruct) but the internal organization of the struct is out of control. If the 2 port addresses are consecutive, you can place a 2 byte variable (int) on top of them and access the individual bits of that variable, anyhow, the BoostC compiler will not accept a variable bit index like in your for loop (another thread). My solution to access computed individual bit ports is to use the loop counter to generate a bitmask and use a bitwase operation. Best regards Jorge
  6. Hii jartim Why are you commenting a post from 2010. That guy "naim" has probably gone for long, the post above is his first and only since 2010. Best regards Jorge
  7. Hi I think you are guessing right! And in doing so the compiler saves one instruction, as you can see in your openning post the second form (not preserved) is one instruction shorter than the first (preserved). Best regards Jorge
  8. Hi Are you sure that in the context of the whole program, the value of "trembler @ 0x47" still needs to be preserved for the remaining code after 0x020B ? Best regards Jorge
  9. Hi If code can be generated to compute indexing of arrays, struct fields, ponters and so on, for sure it can also generate code to access a given bit in a byte or word from a variable. My guess is that a piece of generic code to do that would be heavy and ineficient, so they choose to leave it to the programmer, to write optimized code for each use case. Just my 2 cents.... Best regards Jorge
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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 16.1.2.4 @ 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).
  23. 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
  24. 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
  25. Hi I'm running Win 10 Pro and add no problems installing it, Both on a machine upgraded from Win10 home to Pro and on another with a native install of Pro, everything went fine. Try to download it again, you might have an error in the install package. BTW: I used the "exe" download. Best regards Jorge
×