BoostC Forum Extracts 2007 - Revision history

DavidCary: clarified (I hope)

2014-10-31T16:10:28Z

clarified (I hope)

Russ hensel: /* nn3turntable */

2010-04-26T19:29:25Z

nn3turntable

Russ hensel: /* Discussion of software and hardware usart issues */

2009-02-25T22:55:49Z

Discussion of software and hardware usart issues

Russ hensel: /* what */

2009-02-25T22:53:09Z

what

Russ hensel: /* last */

2009-02-19T16:50:02Z

last

Show changes

Russ hensel: /* stop at */

2009-02-07T04:21:57Z

stop at

Russ hensel: /* stop at */

2009-02-07T04:17:22Z

stop at

Russ hensel: /* delay timer */

2009-02-07T03:54:08Z

delay timer

DavidCary: wikify: add headings

2009-02-02T02:15:51Z

wikify: add headings

Russ hensel: /* Almost Ready For Reading */

2009-02-01T22:07:58Z

Almost Ready For Reading

@@ Line 510: / Line 510: @@
 http://forum.sourceboost.com/index.php?showtopic=3129&pid=11777&mode=threaded&start=#entry11777
-I need a definitive answer to my one wire problem please.
+Q:
 Regarding my previous posts on the subject, I'm still having no luck after using various methods.
 Will someone please tell me in what format the 'data' is returned after a temp. conversion. i.e. 9 bytes, bytes 0 & 1? etc....
@@ Line 517: / Line 518: @@
 With the lcd header file it can be opened and you can work out what is happening not so with the one wire header. Does it actually work? Has anyone proved it?
+A:
 These devices (as per datasheet) can return all 9 scratchpad reads, of those only two are needed for minimal  temperature reading. ( Two give you the basic plus, minus, leading integer values and either .0 or .5 )
@@ Line 528: / Line 529: @@
+Q2:
 I realise (from the dallas data sheet) that 9 bytes are returned, however, the answer I need is what exactly does the return char 'data' in the 'oo_get_data' function contain as far as the sourceboost ide is concerned, bytes 0 & 1, which contain the temp. data or the full 9 bytes?
+A2:
 oo_get_data() does exactly what one would expect it to do. It is a generic handler to take data off the
 onewire. This means it will return only the first byte if you just drop it in plain.
-For the dallas sensor you would have tto call it 9 times for all the bytes.
+For the Dallas sensor, you have to call it 9 times for all the bytes.
 == Volatile ==

← Older revision		Revision as of 19:29, 26 April 2010
Line 798:		Line 798:
	Just subtract 48 ( ascii code for '0' ) from each digit to convert to a decimal.		Just subtract 48 ( ascii code for '0' ) from each digit to convert to a decimal.
	The you will need to convert each value into the appropriate segments using some kind of lookup table.		The you will need to convert each value into the appropriate segments using some kind of lookup table.
		+
		+
		+	[[category:Microcontroller]][[category:PIC]][[category:BoostC]]

@@ Line 640: / Line 640: @@
 As you can see my interrupt routine is heavily loaded. What i need to know is if i use the emulated(software) usart will the transmitted data get corrupted due to extended soft ware delay(due to interrupts), which is used to generate the baud rate ?
 Not if you intelligently use priority interrupts or alternativly give NOVOS a spin.
 No priority interrupts, I am using pic16f877. I am talking about software usart and so it does not generate any interrupt ( for that matter i think even the hw uart lib of source boost does not generate interrupt, but does a software polling of the interrupt or status flags( the rx & tx interrupt enable bits are cleared). I don't want to use my own routine. If i use the SB lib i have the advantage of handling strings ,ascii etc with ease( i suppose, i haven't tried).
 Use the hardware UART, problem solved.
@@ Line 685: / Line 663: @@
 The rest of the code to handle the actual data at your leisure would be inside your main.
-CODE
-void interrupt(void)
+ void interrupt(void)
-−
+ {
      if(txif)    /* Transmit interrupt flag - triggers when empty */
+     {
@@ Line 703: / Line 681: @@
          txif = 0;
+     }
-−
      if(rcif)    /* rx interrupt */
+     {
@@ Line 710: / Line 688: @@
          rcif=0;
+     }
-−
+ }
@@ Line 740: / Line 702: @@
 To extract a character from the buffer: new_char = rxCapture(tail++); if (tail >= buffer_size) tail = 0;
 Clearing the RCIF flag is handled automatically when the rxreg is read. Clearing it manually (as shown above) can result in character loss in race conditions (don't do it). The PIC is brain dead with respect to its asynchronous port, in the event of an overrun error (not clearing the RXREG before the next character is received) the PIC disables the asynchronous receive logic - to avoid this problem the receive interrupt handler needs to check the error status and in event of error it needs to disable and immediately reenable the receive logic.
 This is true, but also flawed in quite a lot of Microchip's silicon. There is a lot of errata stating that reading does not always clear the flag.  As for the potential race condition, in practice i have yet to see it even when using baudrates in excess of 115.2k.
 Depending on which family of devices your using the USART will disable after the second or third level buffers are full, but the interrupt flag will still be enabled.
 Error checking is essential for any protocol, but is a bit advanced for someone trying to figure out the basics of using the USART.
 I disagree. Lockup of the PIC's USART is a common trap for newbies - they waste a lot of time chasing phantom problems.
 == nn3turntable ==

@@ Line 320: / Line 320: @@
 ------
-=== what ===
+=== Asm Optimizations ===
 * From:  http://forum.sourceboost.com/index.php?showtopic=3348&pid=12571&mode=threaded&start=#entry12571
@@ Line 347: / Line 347: @@
------------
+=== Pointer to Functions  ===
-function pointers are supported since v6.70. See
+Q:  Would like to know if BoostC supports pointers to function; are there any limitations or not?
-http://www.sourceboost.com/CommonDownload/VersionLog.html
+A:  Function pointers are supported since v6.70. See http://www.sourceboost.com/CommonDownload/VersionLog.html
 Limitations:
@@ Line 362: / Line 359: @@
 - It seems that the call tree is not parsed through function pointers. So, function pointers should be used together with a software stack or -very carfully- with the hardware stack. See http://forum.sourceboost.com/index.php?showtopic=3279
---------
+=== what ===
 === last ===

@@ Line 290: / Line 290: @@
 -------
-http://forum.sourceboost.com/index.php?showtopic=2707&pid=10443&mode=threaded&start=#entry10443
+---------
-is there a way to fill data to an address relative to _EEPROM
+== EEProm Data ==
-like
+Is there a way to fill data to an address relative to _EEPROM like:
-CODE
-#pragma DATA _EEPROM,     1, 2, 3
+     #pragma DATA _EEPROM,     1, 2, 3
-#pragma DATA _EEPROM+10,  1, 2, 3
+     #pragma DATA _EEPROM+10,  1, 2, 3
-#pragma DATA _EEPROM+20,  1, 2, 3
+     #pragma DATA _EEPROM+20,  1, 2, 3
 because the preprocessor doesn't seem to accept this one
-No this is a limitation
+No this is a limitation  Have a look at where _EPROM is defined, use this address manually adding the required offset.
 -------
-http://forum.sourceboost.com/index.php?showtopic=3358&pid=12600&mode=threaded&start=#entry12600
+=== Plugins ===
 ------
-http://forum.sourceboost.com/index.php?showtopic=3348&pid=12571&mode=threaded&start=#entry12571
+=== what ===
-'m curious if it is possible to turn off all the optimizations within the ASM code.
+Is possible to turn off all the optimizations within the ASM code.
 Well, i need to make some very time paced routines that jump into different tables and output it on different pins.
 But now BoostC compiles in my ASM code all the different bank switching instructions.
@@ Line 341: / Line 333: @@
 Btw: The "goto $+1" seem very stupid for a c compiler, but it would be neat if that's possible somehow.
 I even tried
-		Use:
+  _asm{
-CODE
+Use:
@@ Line 368: / Line 351: @@
 http://forum.sourceboost.com/index.php?showtopic=3337&pid=12527&mode=threaded&start=#entry12527
- would like to know if BoostC supports pointers to function; are there any limitations or not?
+Would like to know if BoostC supports pointers to function; are there any limitations or not?
 function pointers are supported since v6.70. See

@@ Line 292: / Line 292: @@
 === stop at ===
-	 Counting Optimization (decfsz)
-	Thompson	409	18th November 2007 - 07:22 PM
+http://forum.sourceboost.com/index.php?showtopic=2707&pid=10443&mode=threaded&start=#entry10443
-Last post by: Pavel
+is there a way to fill data to an address relative to _EEPROM

@@ Line 241: / Line 241: @@
 Yes, this one bit me too! I wrote the following routine that you can use for any ms value from 1 to 65535. I timed it at 60,000 and it seems to be pretty much on the money.
-void delayMs(unsigned int ms){
+  void delayMs(unsigned int ms){
-char i;
+       char i;
-char high = ms >> 8;
+       char high = ms >> 8;
-char low = ms & 0x00ff;
+       char low = ms & 0x00ff;
-for(i = 0; i < high; i++){
+       for(i = 0; i < high; i++){
-delay_ms(255);
+            delay_ms(255);
-−
+       }
-delay_ms(low);
+       delay_ms(low);
-−
+  }
 You might think that it needs another delay_ms(1) in the loop but I got the most accurate time without it.
@@ Line 263: / Line 263: @@
-Regards
+ ...
-Dave
+     lcd_datamode();
 -------------
-*From:  http://forum.sourceboost.com/index.php?showtopic=3367&pid=12653&mode=threaded&start=#entry12653
+* From:  http://forum.sourceboost.com/index.php?showtopic=3367&pid=12653&mode=threaded&start=#entry12653
 That's it. Adding -d DEBUG to the compiler options does exactly what I want.

@@ Line 16: / Line 16: @@
 I am not an expert, but I think I have seen compilers that have pragma's that give hints to compiler about these things.
-----------
+== initializing struct ==
 * From:  http://forum.sourceboost.com/index.php?showtopic=3430&pid=12890&mode=threaded&start=#entry12890
@@ Line 68: / Line 69: @@
-----------
+== function prototypes ==
 * From:  http://forum.sourceboost.com/index.php?showtopic=3440&pid=12882&mode=threaded&start=#entry12882
@@ Line 76: / Line 77: @@
 Prototypes are required if you do a forward reference to a function. If you are in the habit of using them, then always use them. I do.
 ** Question 2:
@@ Line 86: / Line 89: @@
 If you go to Settings - Options and enable All warnings the compiler will warn you if you exceed 255 for a delay.
 ** Question 3:
@@ Line 101: / Line 106: @@
 -------------
 * From:  http://forum.sourceboost.com/index.php?showtopic=3427&pid=12856&mode=threaded&start=#entry12856
@@ Line 191: / Line 197: @@
 Russ
 *From:  http://forum.sourceboost.com/index.php?showtopic=3404&pid=12741&mode=threaded&start=#entry12741
@@ Line 217: / Line 223: @@
--------------
+== interrupt handlers ==
 *From:  http://forum.sourceboost.com/index.php?showtopic=3403&pid=12735&mode=threaded&start=#entry12735
@@ Line 230: / Line 236: @@
---------
+== delay timer ==
 *From:  http://forum.sourceboost.com/index.php?showtopic=3269&pid=12715&mode=threaded&start=#entry12715

@@ Line 30: / Line 30: @@
                      "0123456789", quuuux
                    };
 I can create a two dimensional array of strings and initialize them or a array of enums and initialize them but not an array of structs.
@@ Line 67: / Line 66: @@
 Found the thread - http://forum.sourceboost.com/index.php?showtopic=3404
 ----------
@@ Line 107: / Line 107: @@
 read the post for some info an location of variables in memory, bank switching ..... size and speed.
 -------------
@@ Line 121: / Line 122: @@
 delay_us(0) results in 0.01ms + (255 * 0.001ms) = 265us
 -------------
@@ Line 226: / Line 228: @@
 This is still all tricky or it´s not a problem to ignore this warning under this conditions?
 If you are sure you are handling this situation correctly you can ignore this warning, your code looks like it maybe ok, but this kind of code can be tricky to understand.
 --------