μGUI and RAM usage

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a resistive touch screen that I'm using with an XMEGA A1U Xplained pro. I've ported some of the functions out of an Adafruit TFTLCD Arduino library and so far everything there is working fine. Now I've started to implement μGUI in the hope that I'll be able to make a nice fancy GUI, and so far so good, however if I try to use the 12x16 font size or above, my LCD initialization code stops working. In particular it is the readID function from the Adafruit library that stops working, in that it returns the wrong number (0xFFFFFFFF to be exact, rather than the expected 0x990000). My first thought was that uGUI was using too much memory, however according to AS7 the application only uses 6.5% of the available RAM (and 14% of the program memory FWIW) so it would appear I'm way under the limit... However, upon observing my ID variable when debugging (the variable which appears wrong when using the larger font) which is a uint32_t, the memory location is reported to be 0x4053, which according to the datasheet is outside of the internal SRAM limit of 0x3FFF. When I use a smaller font the memory location is 0x2E53.

 

Has anyone else ever experienced anything like this? I'm wondering if I'm simply using too much RAM, even though AS7 says I'm only using a tiny 6.5%...

Does anyone have any ideas? Short of scraping the touchscreen and handling the UI on a PC ha!

 

PS I haven't posted any of my code as of yet as I figured I'd get the ball rolling first to see if there's a simple gotcha I'm missing, however we can go down that road if needs be.

 

 

This topic has a solution.
Last Edited: Fri. Jan 6, 2017 - 09:10 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XMEGA A1U Xplained Pro should have more than enough external RAM if the EBI was initialized correctly.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the time being I'm not using the external RAM, was hoping I could save the costs of the final design... That and I've never actually used external RAM haha. Probably worth me setting up and using it though, it will prove my theory about running out of internal RAM if nothing else. Thanks for the thought.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:
For the time being I'm not using the external RAM, was hoping I could save the costs of the final design
XMEGA384C3 has 32KB of internal RAM.

Its Atmel evaluation board would need an Atmel-ICE; only XMEGA128A1U has an EDBG with it.


http://www.atmel.com/tools/XMEGA-C3XPLAINED.aspx

https://www.mattairtech.com/index.php/development-boards/mt-db-x3-atmel-avr-xmega-64-pin-a3u-a3bu-c3-d3-usb-development-board.html ("DFU (FLIP) bootloader preinstalled")

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:
Does anyone have any ideas?
Use non-volatile memory to store the fonts.

It's somewhat typical for a LCD module to have a SD socket; your LCD module has a microSD socket.

XMEGA A1U Xplained Pro does not have a SD socket.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:
Short of scraping the touchscreen and handling the UI on a PC ha!
or, moving to another LCD with touchscreen on a 16-bit MCU.

The WVGA FTDI modules are a new arrival at Mouser :

http://www.mouser.com/new/ftdi/ftdi-me81x-modules/

IIRC, the FTDI LCD MCU have widgets and there's Arduino source code.

The Riverdi match for FTDI ME81x :

https://riverdi.com/product-category/displays/ft8xx/?filter_size=11&query_type_size=or&filter_addons=36

 

Most of the EarthLCD ezLCD have a PIC24 for the GUI :

https://earthlcd.com/product-category/ezlcd-intelligent-lcds/

 

Edits : EarthLCD, Riverdi

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Jan 5, 2017 - 02:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Howard_Smith wrote:
For the time being I'm not using the external RAM, was hoping I could save the costs of the final design
XMEGA384C3 has 32KB of internal RAM.

Its Atmel evaluation board would need an Atmel-ICE; only XMEGA128A1U has an EDBG with it.


http://www.atmel.com/tools/XMEGA-C3XPLAINED.aspx

https://www.mattairtech.com/index.php/development-boards/mt-db-x3-atmel-avr-xmega-64-pin-a3u-a3bu-c3-d3-usb-development-board.html ("DFU (FLIP) bootloader preinstalled")

 

A nice idea but if possible I'd like to stick with the ATxmega128A1U as I already have the corresponding Xplained Pro, but using the external RAM I have available as you already mentioned should help me get around this.

 

gchapman wrote:

Howard_Smith wrote:
Does anyone have any ideas?
Use non-volatile memory to store the fonts.

It's somewhat typical for a LCD module to have a SD socket; your LCD module has a microSD socket.

XMEGA A1U Xplained Pro does not have a SD socket.

 

Regardless of whether or not I use external RAM that's probably a good idea anyway, however I'll have to modify uGUI's source code to implement this but hopefully that won't be too much of a task.

 

gchapman wrote:

Howard_Smith wrote:
Short of scraping the touchscreen and handling the UI on a PC ha!
or, moving to another LCD with touchscreen on a 16-bit MCU.

...

Most of the EarthLCD ezLCD have a PIC24 for the GUI :

 

Thanks for the suggestions, in truth if I start to find that an Xmega isn't quite up to the job of driving a touchscreen GUI then I'll either take it as an excuse to delve into the world of ARM, or I'll use an off-the-shelf item from 4D Systems.

 

Many thanks for all of your feedback and input!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I set up the EBI and everything started working again even with the larger fonts, so once again thank you gchapman! It does beg the question though, what was AS7 referring to when it said that my application was only using 6.5% of the internal RAM, when evidently I had used 100% of it?

Also, now that I'm using 256KB of external SRAM (there is another 256KB available on top of that if I manually fiddle with a GPIO for an extra address bit, however it's not necessary - at least not for the time being) AS7 reports that I'm using 13483 bytes/ 23.5%.  Before I introduced the EBI and the external RAM it was reporting 3755 bytes/  6.5%. At the time I didn't bother checking the actual number of bytes used, I just saw 6.5% and thought I was safe, but looking at it now, 3755 bytes is not 6.5% of the ATxmega128A1U's 8KB of internal SRAM!? Also I'm not sure what the 13483 bytes is 23.5% of either? What am I missing???

 

Edit: typos

Last Edited: Fri. Jan 6, 2017 - 09:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Static variables but other than that I have no other answers.

Stack will grow into static data which will become indeterminate.

IIRC XMEGA EBI document(s), stack is in internal RAM with other regions in external RAM; might want to confirm that.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:
... if I start to find that an Xmega isn't quite up to the job of driving a touchscreen GUI ...
XMEGA should be responsive for your HVGA display.

XMEGA "might" be OK for VGA though would move either from SPI to an 8-bit bus to the display, or, USART in master SPI mode along with DMA.

The XMEGA DMAC is fairly orthogonal (addressing, data sources and sinks including ports)

Howard_Smith wrote:
... then I'll either take it as an excuse to delve into the world of ARM, or I'll use an off-the-shelf item from 4D Systems.
An alternate way is via an Atmel ARM Cortex-M7 SAM V.

Though the following is more expensive than that from 4D Systems, it's somewhat packaged (hardware, software, IDE) :

Precision Design Associates

43xx Series

4.3in Touch Module for use with Atmel ARM-based Xplained kits or custom hosts ...

http://www.pdaatl.com/tx43xx.htm#tm4301b

...

 

Eval Hardware:

...

http://www.atmel.com/tools/ATSAMV71-XULT.aspx (SAM V71 Xplained Ultra Evaluation Kit)

...

Larger displays (VGA and sub) would be a better match with SAMA5; most SAMA5 have an LCD controller.

 

An FTDI LCD MCU and an XMEGA are a good combination :

https://www.avrfreaks.net/forum/graphicsgui-using-xmega#comment-2040551

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It does beg the question though, what was AS7 referring to when it said that my application was only using 6.5% of the internal RAM, when evidently I had used 100% of it?

 Perhaps the AS project "assumes" use of the External RAM, even though you hadn't set it up?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

XMEGA should be responsive for your HVGA display.

 

Absolutely, so far so good! 

 

westfw wrote:

It does beg the question though, what was AS7 referring to when it said that my application was only using 6.5% of the internal RAM, when evidently I had used 100% of it?

 Perhaps the AS project "assumes" use of the External RAM, even though you hadn't set it up?

 

That's a good call, though I wasn't actually using the Xplained Pro as an Xplained Pro as far as the AS7 solution goes, I'd simply set up an executable GCC project and selected the ATxmega128A1U as the target device and the on-board EBDG as the programming and debug interface, so you'd think that AS7 would assume I only have internal RAM available. But maybe AS7 somehow knows that the micro is part of an Xplained Pro, thus having the external RAM available...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's a bug in Studio to do with RAM size reporting for Xmega.  I *think* this is fixed in recent issues. Either way you may want to invoke avr-size in a post build step anyway? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's a tag <address-spaces> in the XML file "ATxmega128A1U.atdf" in the XMEGA A device pack.

 

http://packs.download.atmel.com/#collapse-Atmel-XMEGAA-DFP-pdsc

may not be the most recent.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

There's a bug in Studio to do with RAM size reporting for Xmega.  I *think* this is fixed in recent issues. Either way you may want to invoke avr-size in a post build step anyway? 

 

Ahhh okay, thanks for the heads up. Could you point me in the right direction on how I'd go about invoking a post build step in AS7? It's not something I've ever actually had to do before.

 

gchapman wrote:

There's a tag <address-spaces> in the XML file "ATxmega128A1U.atdf" in the XMEGA A device pack.

 

http://packs.download.atmel.com/#collapse-Atmel-XMEGAA-DFP-pdsc

may not be the most recent.

 

Okay so I found the file and the tag you were referring too, and inside that tag are separate <address-space> tags for the different parts of memory. This is the one relevant for RAM...

 

<address-space name="data" id="data" start="0x0000" size="0x1000000" endianness="little">
  <memory-segment start="0x0000" size="0x001000" type="io" rw="RW" exec="0" name="IO"/>
  <memory-segment start="0x1000" size="0x000800" type="eeprom" rw="RW" exec="0" name="MAPPED_EEPROM"/>
  <memory-segment start="0x2000" size="0x002000" type="ram" rw="RW" exec="0" name="INTERNAL_SRAM"/>
  <memory-segment start="0x4000" size="0x00BFFF" type="ram" rw="RW" exec="0" name="EXTERNAL_SRAM" external="true"/>
</address-space>

 

The external SRAM's size entry seems incorrect to me. Given that with the starting offset of 0x4000, a size of 0x00BFFF would equate to 0x7FFF/ 32KB of external SRAM, and given that you can set the the block size for the 4 chip selects, via the ASIZE bits in their corresponding CTRLA registers, up to 16MB, surely the size entry should be much bigger? Even in my case where I'm only using 256KB the size entry doesn't add up. Can I simply change the value to suit or...?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:
The external SRAM's size entry seems incorrect to me.

...

surely the size entry should be much bigger?

No for AVR GCC has 16-bit pointers.

Other AVR C compilers have 16b pointers with the exception of IAR EWAVR.

Howard_Smith wrote:
Can I simply change the value to suit or...?
... use ASF Huge Memory.

Alternatively, can maintain the four RAMP registers outside the scope of AVR GCC, or, use the DMAC (24b addressing, 16MB max per transaction, 64KB max per block)


http://ftp.iar.se/WWWfiles/AVR/webic/doc/EWAVR_CompilerReference.pdf (page 59, "Memory models")

via

https://www.iar.com/support/user-guides/user-guides-iar-embedded-workbench-for-atmel-avr/

and

https://www.iar.com/iar-embedded-workbench/#!?architecture=AVR

http://asf.atmel.com/docs/latest/xmegaau/html/group__hugemem__group.html

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

No for AVR GCC has 16-bit pointers.

Other AVR C compilers have 16b pointers with the exception of IAR EWAVR.

 

Ah, okay that would explain a few things! So although I've set up the EBI to use 256KB of external SRAM, I can't actually access all of that - something which I did actually notice when debugging, as the memory window displayed everything above 0xBFFF as '??'.

So does that mean that  size="0x00BFFF"  is correct? How come it's not 0xFFFF? Is there something else that limits this?

 

Once again, thank you for your responses gchapman!

 

EDIT: Ah, of course the size is correct; 0x4000 + 0xBFFF = 0xFFFF. You'll have to excuse me for missing the painfully obvious there ha!

Last Edited: Mon. Jan 9, 2017 - 08:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:
... I can't actually access all of that - ...
Within libgcc, can't access data greater than 0xFFFF.  Go outside of AVR GCC.

Howard_Smith wrote:
So does that mean that  size="0x00BFFF"  is correct?
Yes

Howard_Smith wrote:
How come it's not 0xFFFF?
0x4000 + 0x00BFFF = 0xFFFF

Howard_Smith wrote:
Is there something else that limits this?
Yes; the AVR GCC ABI :

https://gcc.gnu.org/wiki/avr-gcc#Type_Layout

There are 24b types so could do the pointer arithmetic before going outside of libgcc and libc.

https://gcc.gnu.org/wiki/avr-gcc#Types

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Saw your edit

Glad we are both heads up

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Why is gcc any different to any other c compiler? you extend beyond 64k banks using RAMxx registers which are 64k bank seleection registers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IAR EWAVR can have 24-bit pointers :

http://ftp.iar.se/WWWfiles/AVR/webic/doc/EWAVR_CompilerReference.pdf

(page 279)

Pointer types

...

DATA POINTERS

Data pointers have three sizes: 8, 16, or 24 bits.

...

whereas AVR GCC has 16b pointers :

https://gcc.gnu.org/wiki/avr-gcc#Type_Layout

...

void*, sizeof is 2

...

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I fear you have forgotten __memx?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

__memx

https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#AVR%20Named%20Address%20Spaces

...

__memx

This is a 24-bit address space that linearizes flash and RAM:

RAMPZ

If the high bit of the address is set, data is read from RAM using the lower two bytes as RAM address.

If the high bit of the address is clear, data is read from flash with RAMPZ set according to the high byte of the address. See __builtin_avr_flash_segment.

Objects in this address space are located in .progmemx.data

...

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Jan 10, 2017 - 02:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
... you extend beyond 64k banks using RAMxx registers which are 64k bank seleection registers.

https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#AVR-Options

...

3.18.5.2 Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers

...

"Dare to be naïve." - Buckminster Fuller