20.4.09: Speichermangel in Bascom?
Ein neues Bascom-Projekt für den Tiny13 wurde begonnen. Beim Kompilieren des Programms brachte der Compiler die Fehlermeldung 22: "out of SRAM-space". Und das obwohl noch kaum Variablen verwendet wurden. Nach etwas Sucherei wurde der Fehler gefunden: Die Einstellungen für Hwstrack, Swstack und Framesize waren für ein vorher bearbeitetes Projekt mit dem Mega32 höher eingestellt worden als es dem Tiny13 gut tut.
Das Bild zeigt die Default-Einstellungen. Man kann aber besser im Quelltext die Größen dieser Speicherbereiche angeben. Für den Tin13 reichen meist auch kleinere Werte. Hwstack = 8 reicht für vier Unterprogrammaufrufe. Swstack wird bei der Variablenübergabe an Subs benötigt, die man besser vermeidet. Und Framesize ist für lokale Variablen da, die bei kleinen Projekten nicht sinnvoll sind, denn mit globalen Variablen läuft es glatter.
$regfile = "attiny13.dat"
$crystal = 1200000
$hwstack = 8
$swstack = 2
$framesize = 2
Eine häufige Frage zu der ELEXS.DLL, RSCOM.DLL und RSAPI.DLL: Warum haben die DLLs keine Funktion, um den Status der Leitung RXD abzufragen?
Das
ist leider technisch nicht möglich, es gibt dazu keine
Windows-Funktion. Man kann nur abfragen, ob an RXD ein Byte empfangen
wurde. TXD kann man zwar zu einem beliebigen Zeitpunkt in den
Break-Zustand setzen und genauso schnell mit dieser Leitung klappern wie
mit DTR oder RTS, aber bei RXD gibt es einen großen Unterschied zu den
Leseleitungen CTS, RI usw. Wenn nämlich der UART an RXD einen
Pegelwechsel erkennt muss er erst mal abwarten was da noch kommt und ob
das mal ein gültiges Byte werden soll.
Auf der Suche nach einem Übertragungsfehler über den I2C-Bus habe ich ein anloges Zweikanal-Oszilloskop eingesetzt. Damit es noch übersichtlich genug bleibt wurde zum Test eine Sequenz aus zwei Bytes schnell wiederholt. Das Signal lief über den USB und einen FT232R und wurde mit VB erzeugt.
Beide
Kanäle wurden in der y-Achse so verschoben, dass man die zeitliche
Zuordnung gut erkennen kann. Die Zeitbasis war auf 1 ms/Skt eingestellt.
Das Taktsignal an SCL hat 9 Impulse. SDA überträgt die Daten, in diesem
Fall die beiden Bytes 00100010 und 00010001. Bei ersten Byte sieht man
deutlich den Ack-Impuls des Slave. Alles klar auf dem Bus. Man erkennt
deutlich, dass der schnelle USB 2.0 läuft.
Durch die Messung wurde festgestellt, dass der FT232R sich mit USB 2.0 anmeldet wenn er kann, an anderen PCs mit USB 1.1. Windows verzichtet großzügig auf eine Rückmeldung was da läuft. Das gesuchte Problem war, dass die wesentlich langsamere Ansteuerung über USB 1.1 mit 3 ms pro Pegelwechsel vom angeschlossenen I2C-IC nicht akzeptiert wurde. Was da hilft? Der Bit Bang Modus.
Hier im Labortagebuch habe ich schon mal davon berichtet: Ein STK500 hat einen Schaden im Bereich der Takterzeugung erlitten. Ein Widerstand hat es repariert: 6,8 kΩ statt des defekten Treibers. Das System hat wieder funktioniert, jedoch wie sich später herausstellte nicht in jeder Situation. Die Firma (Modul-Bus) hat sich ein neues STK500 gekauft, das alte ist zu mir gewandert. In der Zwischenzeit habe ich mein eigenes ebenfalls gekillt (vielleicht durch statische Ladung...). Bei meinem Board liegt ein andere Fehler vor: Der Quarzoszillator selbst ist defekt. Man hat zwar noch den internen Takt von 3,6 MHz, aber mit der freien Wahl des Quarzes ist es vorbei.
Also habe ich mir das reparierte Board noch mal vorgenommen: Bei kleiner Frequenz klappte eigentlich alles, aber z.B. mit 11 MHz war es unzuverlässig. Grübel, grübel, 5,6 kΩ ist eigentlich ganz schön viel, wenn am XTAL-Eingang zusammen mit allen Leitungen möglicherweise eine Kapazität von 20 pF gegen Masse liegt. 20 pF ergeben bei 11 MHz einen kapazitiven Widerstand von 700 Ω, da bleibt nicht mehr viel übrig vom Oszillatorsignal. Oder anders gesagt, 5,6 kΩ und 20 pF bilden ein Tiefpassfilter mit der Grenzfrequenz 1,4 MHz. Damit ist die Reparatur einfach: Der 5,6-kΩ-Widerstand wurde mit einem keramischen Kondensator von 56 pF überbrückt, der gerade herumlag. Jetzt klappt es wieder mit jedem beliebigen Quarz!
14.4.09: Hilfsozillator für das STK500
Das zweite STK500 (das mit dem defekten Quarzoszillator) ist inzwischen bei meinem Sohn gelandet, der intensiv mit Bascom arbeitet. Erst ging es noch mit der Festfrequenz von 3,6 MHz, aber dann brauchte er unbedingt einen schnelleren Takt, 11,0592 MHz. Kein Problem, wir bauen einfach einen Quarzoszillator wie im Lernpaket Tesla-Experimente. Er bekommt eine Fassung aus einem Stock IC-Sockel, dann kann man sogar den Quarz austauschen.
Am Kollektor-Ausgang gibt es ein Kabel, das nun bei Bedarf einfach auf den entsprechenden Jumper des STK500 gesteckt wird. Und schon hat jeder von uns wieder ein funktionierendes System - bis demnächst vielleicht eines komplett geschrottet wird. Wo gehobelt wird, da fallen Späne.
