Add support for accessing printf, sprintf, puts, etc. strings that do not lie in the MCU data space

git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@3738 42af7a65-404d-4744-a932-0658087f49c3

include/nuttx/arch.h

@@ -449,6 +449,45 @@ EXTERN void up_disable_irq(int irq);
 EXTERN int up_prioritize_irq(int irq, int priority);
 #endif
 
+/****************************************************************************
+ * Name: up_romgetc
+ *
+ * Description:
+ *   In Harvard architectures, data accesses and instruction accesses occur
+ *   on different busses, perhaps concurrently.  All data accesses are
+ *   performed on the data bus unless special  machine instructions are
+ *   used to read data from the instruction address space.  Also, in the
+ *   typical MCU, the available SRAM data memory is much smaller that the
+ *   non-volatile FLASH instruction memory.  So if the application requires
+ *   many constant strings, the only practical solution may be to store
+ *   those constant strings in FLASH memory where they can only be accessed
+ *   using architecture-specific machine instructions.
+ *
+ *   A similar case is where strings are retained in "external" memory such
+ *   as EEPROM or serial FLASH.  This case is similar only in that again
+ *   special operations are required to obtain the string data; it cannot
+ *   be accessed directly from a string pointer.
+ *
+ *   If CONFIG_ARCH_ROMGETC is defined, then the architecture logic must
+ *   export the function up_romgetc().  up_romgetc() will simply read one
+ *   byte of data from the instruction space.
+ *
+ *   If CONFIG_ARCH_ROMGETC, certain C stdio functions are effected: (1)
+ *   All format strings in printf, fprintf, sprintf, etc. are assumed to
+ *   lie in FLASH (string arguments for %s are still assumed to reside in
+ *   SRAM). And (2), the string argument to puts and fputs is assumed to
+ *   reside in FLASH.  Clearly, these assumptions may have to modified for
+ *   the particular needs of your environment.  There is no "one-size-fits-all"
+ *   solution for this problem.
+ *
+ ****************************************************************************/
+
+#ifdef CONFIG_ARCH_ROMGETC
+EXTERN char up_romgetc(FAR const char *ptr);
+#else
+#  define up_romgetc(ptr) (*ptr)
+#endif
+
 /****************************************************************************
  * Name: up_mdelay and up_udelay
  *

include/nuttx/compiler.h

@@ -103,7 +103,7 @@
  * pointers are 16-bits.
  */
 
-#if defined(__m32c__) || defined(__AVR__)
+#if defined(__m32c__)
 /* Select the small, 16-bit addressing model */
 
 # define  CONFIG_SMALL_MEMORY 1
@@ -116,7 +116,24 @@
 
 # undef  CONFIG_PTR_IS_NOT_INT
 
-/* Handle cases where sizeof(int) may or may not be 16-bits  */
+#elif defined(__AVR__)
+/* Select the small, 16-bit addressing model */
+
+# define  CONFIG_SMALL_MEMORY 1
+
+/* Long and int are not the same size */
+
+# define  CONFIG_LONG_IS_NOT_INT 1
+
+/* Pointers and int are the same size */
+
+# undef  CONFIG_PTR_IS_NOT_INT
+
+/* Uses a 32-bit FAR pointer only from accessing data outside of the 16-bit
+ * data space.
+ */
+
+#  define CONFIG_HAVE_FARPOINTER 1
 
 #elif defined(__mc68hc1x__)
 /* Select the small, 16-bit addressing model */

include/stdint.h

@@ -282,6 +282,15 @@ typedef _uint64_t    uint_fast64_t;
 typedef _intptr_t    intptr_t;
 typedef _uintptr_t   uintptr_t;
 
+/* Some architectures support a FAR pointer which is larger then the normal
+ * (near) pointer
+ */
+
+#ifdef CONFIG_HAVE_FARPOINTER
+typedef _int_farptr_t    int_farptr_t;
+typedef _uint_farptr_t   uint_farptr_t;
+#endif
+
 /* Greatest-width integer types */
 
 #ifdef __INT64_DEFINED