Jump to content

guzewski

EstablishedMember
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About guzewski

  • Rank
    Newbrie
  1. We have been using Andrew Smallridge's I2C driver with great success for a long time, but now something is up and I can't explain it. Maybe someone here can. The new design is using I2C(1) as a slave and I2C(2) as a master (on a secondary I2C bus). The chip is the 18F46K22. Problem summary: Master I2C init fails with PIR3.SSP2IF == 0 and PIR3.BCL2IF == 1. Andrew's I2C init code calls 12c_stop as the last instruction. The stop function asserts SSPCON2.PEN to initiate the stop condition, and then gets stuck in an infinite loop waiting for PIR3.SSP2IF to assert. It never does, but I n
  2. The following line of code used to compile fine: unsigned char *pFrame = (unsigned char *)&(txFrame.destAddrHi); I always put brackets around expressions that I'll take the address of. It's just a habit and I don't want to worry about operator precedence. After upgrading to 7.11, that line of code produces the following errors: error: failed to generate expression error: error in expression The error can be avoided by taking out one pair of brackets. I have to do this in hundreds of places :-( unsigned char *pFrame = (unsigned char *)&txFrame.destAddrHi; H
  3. That makes perfect sense. The library must use the same index size as the code. I'm using SB7.03, but I do not use the IDE. Instead, I use Source Insight for editing and GNU make for building, so I have to manage my own makefiles. I'll find the large library and start using that. Thanks! -mark
  4. I'm using SB7 and I have a project that compiles and links fine. However, I need to increase an array to be larger than 256 bytes, so I thought the [b]-idx 2[/b] option would be suitable. I had to add the option to both the compiler and linker for it to work. When I do that, I suddenly get a lot of linker errors. Here is a snippet: When I remove the option, it compiles fine again. Anyone have any ideas about this? -Mark Guzewski
  5. So I went ahead and purchased an upgrade license for 7.01, after using 6.95 for a while. I'm not sure what I was expecting, but certainly not the following. I installed 7.01 in a separate directory (called SourceBoost7) as I did not want to blow away my 6.95 installation. I use gnu make and it was a pretty straightforward to point to the new install directory. For some reason the executables changed names (e.g. boostc.pic18.exe became boostc_pic18.exe). No biggie. Now when I make I get two bad things happening: (1) My little bit of inline assembler gives an error of "label not fou
  6. I'm trying to define a value in my program, using the compiler command line option -d. It seems that this option does not behave like the gcc -D option, where you can supply a value with the definition (e.g. -Dfoo=bar will have the effect of #define foo bar in the source code) With the SourceBoost C compiler, anything I put after the -d option has a value of 1. I have tried stuff like -d foo=bar but foo always has a value of 1. Is there some way to make this option do what I need, or perhaps there is another way? regards, -mark guzewski
  7. You are correct - if you have a 2 Kbyte bootloader then you simply add the option -rb 0x800 to the linker command line and that offsets everything by 2 Kb. We do this all the time for our 18F4550-based products. I can't remember where we got the bootloader... it was a while ago and I just followed links from the MicroChip site. I remember I had to change how to power-up into the bootloader vs into the app. On all our boards we have a boot button that is read by the bootloader on reset. If the button is pressed it continues running the bootloader, otherwise it jumps to the code entry point
  8. The 18F4550 data sheet includes the instructions DECFSZ and DCFSNZ, however these produce an error when used within an asm block. Is there something I'm missing? -mark
  9. Pavel, I see how that could work quite well, and it is something to consider in the future. For now I'm working on porting other sub-systems and I'll revisit this later. thanks, -mark
  10. Hi Pavel, I must admit I'm a bit skeptical of the effectiveness of C++ on an architecture like the PIC. My C++ on Linux and Windows code pretty much demands STL, accesst to large 3rd party classes, and things like that, so I'm not used to worrying about memory usage etc in that domain. On a PIC, going from assembler to C is such a huge productivity gain in itself that I would need a pretty compelling reason to use C++ on that platform. I may consider it in the future. tahnks & regards, -mark
  11. Pavel, I have been considering other strategies and I think I have settled on something that involves one function per screen, which is responsible for rendering the LCD contents (from ROM storage) and handling the various key strokes in a switch statement. The only other thing that is needed is a pointer to the current menu handler function. It's pretty easy to implement. In fact it should also be reasonably maintainable (always a concern) since all the functionality for a particular screen is encapsulated in one function. My current PicBasic implementation uses a lot of function pointers, s
  12. Pavel, first of all thanks for the update. I understand what you say about function addresses not being known at compile time, and your suggestion to hard-code function addresses with the DATA pragma merits some consideration. I would probably write a tool that does the job for me, which would compile everything, extract the interesting function addresses, automatically edit the source code to replace the addresses in the DATA pragma, and then re-compile everything. At this point it sounds a bit painful but I'll try. But while I have your attention, I was wondering if you could tell m
  13. Pavel, that is the direction that I was heading. But the problem with this is that all of the tables must be in RAM and so must be initialized at system start-up. As it turns out, that requires more ROM and RAM than I'm willing to part with. Essentially, I would like the tables to simply exist and be addressable in ROM, rather than having to go through the exercise of creating them programatically in RAM. I have nearly 20 different screens, and each screen must handle between 3 and 16 buttons. The way I see it, in C, the menu structure would look something like this: struct buttonHa
  14. I'm having trouble figuring this out, and my forum searches are not turning up any solutions.The documentation doesn not provide a lot of detail here either. I often need to store function addresses in ROM. In my PicBasic application, I have some menu code that presents some information on an LCD and handles button presses depending on which screen of information is currently displayed. This code relies heavily on storing functions in ROM (e.g. menu entry function, menu exit function, button handlers, etc). Astonishingly, this was actually pretty easy to implement in PicBasic, using a bit
×
×
  • Create New...