Gefunden für ascii strings empfangen - Zum Elektronik Forum |
| 1 - PWM mit Attiny2313 will nicht so ganz -- PWM mit Attiny2313 will nicht so ganz | |||
| |||
| 2 - HiFi Verstärkerändnisproblem beim AVR GCC -- HiFi Verstärkerändnisproblem beim AVR GCC | |||
| Habe immer noch recht wenig erfahrung mit dem GCC Compiler und folgendes Problem:
Der Datenspeicher ist immer voll. Ich habe eine Interaktion zwischen Benutzer und µC per serieller Schnittstelle. Der Benutzer schickt Befehle in ASCII und der µC muss antworten. Bin dann draufgekommen, dass wenn ich die Strings direkt meiner UART-Sendefunktion übergebe, der Datenspeicher übermäßig beansprucht wird. Wenn die die Textblöcke als const char * vordefiniert werden wird das im Programmspeicher abgelegt. Blöderweise ist der Datenspeicher wieder belastet wenn ich diese Strings übergebe 
Kann mich jemand über die inneren Abläufe im GCC aufklären? Hier die relevanten Codestücke. (Sorry wenns noch chaotisch aussieht, ist alles noch beim Entstehen) Code : | |||
3 - Parser unter Bascom? -- Parser unter Bascom? | |||
Zitat : An den Kommata könnte man sich orientieren... Ja, das wäre die passende Lösung  .
Eine andere Möglichkeit wäre auch, beim String hinten anzufangen, vorausgesetzt, die Position der Daten verändert sich nicht. Da ich nicht weiß, wie man das mit BASIC umsetzen kann, oder ob man dort überhaupt so schön durch Strings iterieren kann wie in vernünftigen Sprachen, würde ich vorne beginnen und alle Zeichen durchrattern und mit dem ASCII-Wert für das Komma vergleichen. Bei positivem Vergleich dann einen Zähler inkrementieren. Hat dieser den passenden Wert (also 6), dann speicherst du den Anfang der Information (Offset vom Stringanfang) und suchst das nächste Komma, welches quasi das Ende der interessanten Information darstellt und speicherst ebenfalls diese Position. Alternativ kannst du dir auch ein paar Bytes in einem String reservieren und die passenden Informationen dort hineinkopier... | |||
| 4 - UART Probleme -- UART Probleme | |||
OK, auch wenn ich einen hinter der Binde habe grade (gute Kumpels verabschiedet für die nächsten Jahre  ), versuche ich mal, die Fragen zu beantworten .
Zitat : So nun zu deinem Code. Ich möchte nicht irgendwie diesen Code kopieren und einfach vergessen wenn es funktionert, ich will den Code verstehen, darum die nächsten (dämlichen) Fragen: Gute Einstellung; da hilft man gern 
---- Zitat : Was ist der unterschied zwischen signed char und unsigned char? | |||
| 5 - Probleme bei LCD-Ansteuerung -- Probleme bei LCD-Ansteuerung | |||
| Moin,
Wie sollen wir denn den Fehler finden, wenn wir den Originalkode nicht haben? Du musst keine Verzögerung, wie von Jorn vorgeschlagen, reinbauen, wenn du das Busyflag testest. Das tust du, ob du es richtig machst, kann ich dir nicht beantworten, da ich keinen PIC-Assembler verstehe, oder nur rudimentär. Sollte das Testen des Busyflags allerdings nicht klappen, dann ist Jornbytes Einwand allerdings berechtigt. Tabelle? Werden denn die richtigen Zeichen im ROM korrekt addressiert? Wann ist der String zuende? Nullterminiert? Oder bekannte Länge? Wenn er nicht nullterminiert ist, dann wird fleißig jeder weitere Datensalat aus dem Flash oder RAM gelesen und als Datenbyte ins Displayram kopiert. Nullterminiert bedeutet aber auch, dass du selbst überprüfen musst, ob das gelesene Zeichen ungleich NULL (0) ist! Sind die Zeichen unter den ASCII-Zeichen 0x0-0x7, dann wird der Inhalt des Character Generator RAMs aufs Display abgebildet. Das Ganze geht so schnell, dass du vermutlich kaum die ersten paar korrekten Zeichen des Strings sehen kannst, bevor sie mit Datensalat überschrieben werden. Ist dann noch ein Fehler in der LCD-Routine, was ich wie gesagt nicht herausfinden kann, dann ist es klar, dass das nich... | |||
| 6 - Datenübertragung zwischen C-Control M-Unit und Atmega 8 -- Datenübertragung zwischen C-Control M-Unit und Atmega 8 | |||
| Also ich hab zwar auch nie bascom programmiert, aber ich hab ne c-control hier rumliegen, die Staub ansetzt ^^
Ich hab jetz beim Einlesen in die Materie also einen ähnlich unbefangenen Blick auf die Dinge wie tvgucker. Als allererstes möchte ich dich auf die seite http://avrhelp.mcselec.com/bascom-avr.html verweisen, falls du die noch nicht kennst. Beim sende Programm scheint mir so weit alles in Ordnung zu sein, Beim Programm das die Daten auf dem LCD anzeigt ist mir Spontan folgendes ins Auge gesprungen. Du Definierst die Eingabevariable A als "String", Benutzt jedoch zum Lesen vom Port das commando "Inputbin", Das liest so viele Bytes wie es braucht vom Port, In dem Fall meines Erachtens nach die Länge des Strings, die bei deiner Definition Aber 0 ist. Ich würde da auf jeden Fall als erstes mal den Datentyp der Variable auf Byte ändern, weil du dann sicher sein kannst, dass er nur versucht 1 Byte vom Port zu lesen. Gibt es eigentlich einen bestimmten Grund warum du "inputbin" benutzt und nicht "Input" ? Meines Erachtens nach ist ... |
Im transitornet gefunden: Ascii Strings Empfangen
|
Zum Ersatzteileshop Bezeichnungen von Produkten, Abbildungen und Logos , die in diesem Forum oder im Shop verwendet werden, sind Eigentum des entsprechenden Herstellers oder Besitzers. Diese dienen lediglich zur Identifikation! gerechnet auf die letzten 30 Tage haben wir 12 Beiträge im Durchschnitt pro Tag heute wurden bisher 0 Beiträge verfasst 7 Besucher in den letzten 60 Sekunden alle 8.57 Sekunden ein neuer Besucher ---- logout ----su ---- logout ---- |
xcvb
ycvb
0.0249319076538