Da der interne SRAM des RZ Raven USB Sticks (AT90USB1287) mit 8KByte relativ klein ist, entstehen immer wieder Probleme, welche meist durch einen Überlauf des Stacks in den Heap oder umgekehrt entstehen können, siehe folgende Abbildung.

Besonders beim Einsatz als RPL Border Router (Der Jackdaw Raven USB Stick als RPL Border Router), gelangt der SRAM mit 96% Auslastung nach der Kompilierung an seine Grenze. Der Betrieb von weiteren Protothreads wie z.B. das Contiki SNMP ist somit auf dem RZ Raven USB Stick nicht möglich, siehe hierzu RZ Raven USB Stick als RPL Border Router mit SNMPv3 Support und RPL MIB.

Glücklicherweise haben die Entwickler des Raven USB Sticks für solche Fälle bereits Vorbereitungen getroffen und innerhalb des Platinenlayouts Leiterbahnen zum Anschluss eines zusätzlichen externen SRAMS inegriert. Im folgenden Schaltplan ist dieser unter der Bezeichnung U6 zu finden.

Da um Pins zu sparen der Datenbus und die High Order Adress Bits über die gleichen Pins gesteuert werden, ist zusätzlich ein Latch erforderlich, welches mit der Bezeichnung U5 im Schaltplan zu finden ist. Die folgende Abbildung verdeutlicht den prinzipiellen Aufbau.

Außerdem ist pro Chip jeweils ein Abblockkondensator vorgesehen (C19 und C20). Auf dem Raven USB Stick sind die Bauteile auf der Platinenunterseite zu finden.

Empfohlen werden laut RZ Raven Hardewareguide Kapitel 3.4.2 die ICs 74AHC573PW als Addresslatch und der BS62UV256TCP-10 als SRAM (32KByte). Das Addresslatch ist ohne Probleme zu beziehen, z.B. von Texas Instruments bei Farnell. Beim empfohlenen SRAM wird das Ganze schon etwas schwieriger, da das Bauteil scheinbar nicht mehr hergestellt wird. Es gibt jedoch einige Alternativen, das wichtigste ist die Gehäuseform TSOP-28 sowie die 32KByte in Anordnung 32×8 und 3,3V Nennspannung, z.B. INTEGRATED SILICON SOLUTION (ISSI) - IS62LV256AL-45TLI.

Um den neuen externen SRAM nun zugänglich zu machen, muss dieser aktiviert werden. Dazu muss das Register XMCMRA, genauer PIN7 von XMCMRA auf High gesetzt werden.

Die restlichen PINs 0-6 (SLR0-SLR2, SRW10, SRW11, SRW00 und SRW01) sind zur Einstellung von „Wait-States“ vorgesehen, was es ermöglicht den Addressraum in verschiedene Sektoren aufzuteilen, was bei den hier verwendeten 32KByte jedoch nicht notwendig ist.

Ebenfalls nicht benötigt werden die Einstellung von Register XMCRB, welches es ermöglicht einzelne Address Bits zu maskieren um den vollen Addressraum auszunutzen.

Umgesetzt in C Code kann folgende Funktion verwendet werden:

void xram_enable(void)
{
 
	XMCRA = ((1 << SRE));  	//enable XMEM interface with 0 wait states, 
                                //switch Bit 7 of XMCRA on to enable XMEM usage
 
	XMCRB = 0;		//use all Port C Pins for XRAM Addresses, Port C7 no needed, 
			        //but we don't need it till it is not connected to anything
}

Um die Funktion sinnvoll in Contiki zu platzieren, bietet es sich an dies im Ordner platform/avr-ravenusb/ zu tun. Der Aufruf kann dann sinvoller Weise in der Datei contiki-raven-main.c innerhalb der lowlevel Initialisierung geschehen. Dazu bietet sich folgendes Vorgehen an (alles im Ordner platform/avr-ravenusb/):

1. Erstellen der C und Header Datei, z.B. avr-xram.c und avr-xram.h und Platzierung innerhalb des platform/avr-ravenusb/ Ordners.
2. Integration von avr-xram.c in das Makefile Makefile.ravenusb
3. Aufruf innerhalb der Lowlevel Initialisierung static void initialize(void) in der Datei contiki-raven-main.c (Änderungen markiert mit /*sz*/
4. Optional: An und Abschalten des externen RAMS durch Makro in contiki-conf.h (#define AVR_XRAM)

Es stellt sich nun die Frage, wie die zusätzlichen 32KByte sinnvoll genutzt werden können. Eine Möglichkeit ist z.B. den internen Speicher für den Stack zu Nutzen und den Heap sowie die .data und .bss Sections in den externen RAM zu verschieben, siehe folgende Abbildung.

Um dies umzusetzen, muss das Vorhaben dem Linker mitgeteilt werden. Dazu genügt es beim kompilieren GCC mit folgendem Anweisungen aufzurufen.

-Wl,--section-start,.data=0x802100,--defsym=__heap_end=0x80a0ff

Dadurch beginnt die .data Section ab der Adresse 0x2100. Die .bss und der Heap werden automatisch danach platziert. Lediglich das Heap Ende muss noch mitgeteilt werden. Der Stack bleibt wie gehabt beginnend beim Ende des internen Speichers, wächst abwärts und muss nicht geändert werden.

Die Adresse 0x2100 ergibt sich durch die internen 8KByte ( 8*1024= 8192 Byte = 0x2000) sowie die Register von 0x0000 bis 0x00FF (255 Byte) = 0x20FF = letzte Adresse des internen SRAMs.

Das Ende des Heap, also das Ende des externen SRAMS ergibt sich dann durch Addition der 32KByte (32*1024=32768=0x8000) mit 0x20FF + 0x8000 = 8192 + 255 + 32768 = 41215 = 0xA0FF = letzte Adresse des externen SRAMS = Ende Heap.

Innerhalb von Contiki lässt sich die Linker Anweisung einfach in das Makefile mit dem Zusatz CFLAGS +=… integrieren, Bsp Makefile im Ordner /examples/ravenusbstick/Makefile.ravenusbstick.

Überprüfen lässt sich die Änderung der Grenzen nach der Kompilierung mit dem Tool avr-readelf. Also z.B. mit dem Befehl avr-readelf -e ravenusbstick.elf. Die anschließende Suche nach z.B, __heap_end, liefert dann die Möglichkeit zur Überprüfung.

Vielleicht taucht beim Lesen die Frage auf, wie der komplette SRAM genutzt wird. Da der externe SRAM nach dem internen SRAM gemappt wird, führt eine Adressierung der ersten 8448 Byte immer zum internen RAM und nicht zum externen RAM. Das bedeutet, dass normalerweise der externe RAM erst ab dem 8449. Byte addressiert werden kann, wodurch ein Speicherbereich mit der Größe des internen SRAMS nicht genutzt werden kann. Um dieses Problem zu umgehen, haben die Entwickler des Raven USB Sticks das Adressbit A15, welches normalerweise das höchste Addressbit darstellt nicht mit dem externen SRAM verbunden (siehe Schaltplan weiter oben). Das führt dazu, dass ab dem Nutzen der Adresse 0x8000 der unterste Teil des SRAMS adressiert wird, da durch das fehlen des höchsten Adressbits die Adresse 0x8000 als 0x0000 erscheint. Die folgende Abbildung verdeutlicht diesen Vorgang.