Jump to content

JorgeF

EstablishedMember
  • Content count

    278
  • Joined

  • Last visited

Everything posted by JorgeF

  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 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).
  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
  16. 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
  17. C++ Porting Issues

    Hi Xelix First of all, you should open a new topic, not steal an old one. Second, can you show us the code? I could try to help, but I have no idea of what you are looking for. Best regards Jorge
  18. !!!!!!?????? Best regards Jorge
  19. Boostwizard: Failed To Parse Wizard Script

    Hi Last time I saw it working, I was testing Sourceboost for the first time, with a free install of some 6.xx version. It had a very limited list of PICs to choose from, only a handfull of them, not even close to the list of suported devices. The results I got from it, was a very simple skeleton to start, Very far from something really usefull. It gave the impression of a first approach to something that never passed the "alfa" stage, and nobody really cared about. I never bothered too much with it, and it didn't stop me from buying a BoostC licence. Anyhow, I'm still to find a wizard that produces, at least, a half-decent piece of code. And this doesn't aplies to Sourceboost only, It aplies to most of the "microcontroler" dev tools. In the desktop and web worlds, things are a little better, but nevertheless, its still easy to write smaller and faster code than what wizards produce. Just my 2 cents..... Best regards Jorge
  20. Lcd Module

    Hi No need to thank for anything. I'm glad the existing library suits your needs. Anyhow, if it didn't, I had already found, among my projects, a piece of code that suits your needs. Best regards Jorge
  21. Lcd Module

    Hi We are speaking the same language. only you are mixing compiler with libraries. The BoostC compiler, or any other one, have no limitations regarding any LCD module by the simple reason they "know" nothing about LCDs. All a compiler knows is how to generate PIC binary code from a "C" source. OTOH the libraries are pieces of "C" code that you can add to your program. Given that, they were written by someone who certainly made a few choices and assumptions like we all do whenever we write a program. Any features and limitations of the library would be depicted in the relevant manual. BTW Do you know why I never use ready made libraries? By the simple fact that I had never seen one that I could classify as "perfectly usable". They are all great for "school code", "teach yourself examples" and "beginner DIY projects", But when it come to real life professional projects, things are a bit more tricky. For something as simple as a character LCD driver I don't even bother to look at the ready made library. I never even used exact copies if my own code accross projects. For other heavier stuff, like an RTOS, I do use it after a good look at it and a few test programs. Thats how I found a bug in NOVO has you can see in other topic in the forum. In the forum you can also find an interesting topic about the EEPROM libraries. Bugs in libraries do happen, and its not a Sourceboost exclusive. The first one I found was in a RTOS from Intel, when I was still a simple university student, back in 1985. Since then I found many more on all sort of environments and programming languages. Best regards Jorge
  22. Lcd Module

    Hi Yes, it does a lot more sense since you put the actual issue on the table. After all its not a matter of compiler capabilities or PIC resources, its a question of library limitations. Well, I have a very special position about ready made libraries for small microcontrollers. Up to now I never used one and I'm not planing to ever do it. But I recon that 4x40 is a reasonable limit for a library that, most probably, was designed to be used with LCD displays using the HD44780 controler or any of its many clones. As you seem to have special needs in terms of the LCD, you would better choose it first and then check if it uses the HD44780 or compatible controler. If it doesn't, there is a real chance that you won't find a ready made library for it. If the LCD of your choice does use an HD44780 controller but its so large that the available libs don't handle it, you have to do it "my way". Either recode the library or do it yourself from scratch. It doesn't take much, all there is to be done is the LCD initialization and sending bytes/nibbles to it Anything besides that is largelly application dependent so you would code it yourself anyway. You can find everything you need in terms of sample code and explanations in the net. Just be carefull because the amount of online garbagge is, at least, as large as the amount of usefull stuff. I would suggest the Microchip forum as a good starting point. Best regards Jorge
  23. Lcd Module

    Hi What exactly do you mean by "BoostC/C** support"? AFAIK any limitation would be from the PIC resources, not from the compiler. Best regards Jorge
  24. Wdt Desactivate In Code

    Hi Your IDLOC question has nothing to do with WDT control. BTW, why are you ressurecting all those old threads? If you have any question of yours, just open anew thread, instead of ressurecting threads that are several years old. Look at the dates! Best regards Jorge
  25. Mplab .cof Problem

    Hi Never had any issue with, either MPLAB 8 or MPLAB X. At least issues that can be tracked down to BoostC usage. Of course I had all sorts of issues with MPLAB X, but thats X problems, and show up with any toolchain. Best regards Jorge
×