Jump to content

Dr. John

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Dr. John

  • Rank
  1. Jorge and Reynard, Great stuff! Jorge, you are right. The only way that the compiler will deliver the correct results is if you declare the array as a string. I think that this is a bug, but there is a reasonable workaround and I'd really like to use this compiler since the Hi Tech compiler seems to create more than double the number of instructions (and at least double the amount of execution time) to accomplish the same thing. Reynard, you confirm Jorge's understanding and your comments were necessary for me to catch Jorge's initial comment to DELETE the brackets. I had tried
  2. Hi Reynard, Thanks for your input. What you said makes a lot of sense to me. However, what ACTUALLY happens is different. I get the following: 00000020:00000060 gbl_LCD_segment_config LCD_segment_config This is the problem that needs to be resolved. This result is completely independent of the presence/absence of the asterisk and its location (within the range of options presented here). Meanwhile, as I said before, the table is correctly created in ROM and the code to access it is as well. So, it seems like the compiler understands half of the issue, but
  3. Gentlemen, Again, thanks for your attention to this. I have tried all three variations of the source code and receive identical results in the assembly code generated as well as the map file generated by the linker. The generated assembly code correctly puts the table in ROM, and correctly accesses it. However, in addition, it incorrectly allocates space for the table in RAM, which incorrect allocation follows through into the map file generated by the linker. Hence, were I to put a couple of larger tables (which is indeed my intent) in ROM, the result would be that I would have
  4. Pavel, Thanks for your rapid reply. Well, the form of the declaration matches exactly that shown in the BoostC manual, as shown on page 45. Originally I had declared the array without the pointer (i.e., rom char LCD_segment_config[12] = // LCD segments setting table // if 1, then pixel is enabled { // GFEDCBA 0b00111111, // for displaying '0' 0b00000110, // for displaying '1' 0b01011011, // for displaying
  5. I have been reviewing BoostC in preparation for purchasing a Pro license in support of a project. While in general I like what I see, there is a bug that will prevent me from the purchase if it isn't fixed. The bug is that when declaring an array in ROM, space for same array is allocated in RAM even though it isn't used, thereby removing the availability of this RAM. Here is an example. rom char *LCD_segment_config[12] = // LCD segments setting table // if bit = 1, then pixel is enabled { // GFEDCBA 0b00111111,
  • Create New...