Problem mit 4kB Daten über UART- Bluetooth

[damfino]

Hab wieder mal ein Problem:

möchte den Inhalt des 4kB EEPROMS über Bluetooth an den PC schicken, einfach mal ans HTerm.
Problem: bekomme maximal ~2600Bytes durch.
Es sieht so aus als gebe es ein Zeitfenster in dem Daten durchgehen, alles danach wird verschluckt.
Hatte als Test nach 1000 Bytes ein delay von 500ms eingebaut, dann kommen weniger Daten an.
Habe aktuell alle 5 Bytes ein delay drinnen, da gehen nur ein paar hundert Bytes in Summe raus.
Hatte auch probiert einfach mal 8 Bytes pro Nachricht zu schicken und nicht jedes einzeln, analog wie die anderen Datensätze, bringt nichts.


Eigentlich geht die Verbindung, schicke 4x in der Sekunde 4 Datensätze raus, das geht problemlos über den ganzen Tag wenn es sein muss.
Ebenso Flashen über Bootloader.

Also wie bekomme ich die 4kB rüber???

LG!


19200Baud, über BTM222 an den PC.

#define Funk_Daten (UCSR0A & (1<<RXC0))
#define Funk_FrameError (UCSR0A & (1<<FE0))
#define Funk_Overrun (UCSR0A & (1<<DOR0))
#define Funk_Daten_Trans (UCSR0A & (1<<UDRE0))
#define Funk_Buffer UDR0

#define CR "\r\n"

Code für Übertragung:

void Funk_Transmit (unsigned char s)
{
while ( !( Funk_Daten_Trans) );
Funk_Buffer = s;
}

// string über Uart
void Funk_Transmit_s (char *s)
{
do
{
Funk_Transmit (*s);
}
while (*s++);

}



Daten aus EEPROM schicken (das delay ist rein aus Testzwecken drinnen, ohne gehen wie erwähnt ~2600Bytes durch)

void Daten_senden()
{
short temp;
unsigned char daten,x;

//cli();

Funk_Transmit_s("Daten_Anfang,"CR);


for (temp=0;temp<4096;temp++)
{
daten=eeprom_read_byte((const uint8_t *)temp);
sprintf(tx_funk,"%d",daten);
Funk_Transmit_s(tx_funk);
x++;if(x>5) {x=0;Funk_Transmit_s(CR);_delay_ms(150);}
}

Funk_Transmit_s("Daten_Ende"CR);

sei();


}
(ohne Interrupts ist es nicht besser)


Als Vergleich was im normalen Betrieb 4x die Sekunde rausgeht:

void TX_Funk(void)
{
unsigned char temp;
temp=(mowerspeed/231);
if (taskflag==FunkdatentaskA)
{taskflag=0;
sprintf(tx_funk,"A,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,*"CR,gpsodo,gps,pos_x,pos_y,richtung,drehzahl_ist,te mp,speed_li,speed_re,pos_x_ziel,pos_y_ziel);
Funk_Transmit_s(tx_funk);
}

if (taskflag==FunkdatentaskB)
{taskflag=0;


sprintf(tx_funk,"B,%d,%d,%d,%d,%d,%d,%d,*"CR,pitch,roll,richtung_kom,wochentag, jahr, tag, monat);
Funk_Transmit_s(tx_funk);
}


if (taskflag==FunkdatentaskC)
{taskflag=0;
sprintf(tx_funk,"C,%d,%d,%d,%d,%d,%d,%d,%d,*"CR,volt_ges,anzeige_modus,anzeige_fahrmodus,anzeig e_spirale,pos_x_gps_akt,pos_y_gps_akt,hdop,satcoun t);
Funk_Transmit_s(tx_funk);
}



if (taskflag==FunkdatentaskD)
{taskflag=0;// volt_ges_berechnet ersetzt mit volt_ges!!!!!!!!!!!
sprintf(tx_funk,"D,%d,%d,%d,%d,%d,%d,*"CR,0,0,0,0,volt_ges,freierspeicher);
Funk_Transmit_s(tx_funk);
}


}

[BMS]

Hallo,
wenn viele Bytes pausenlos (!) geschickt werden, wird die Synchronisation auf die einzelndn Startbits unzuverlässiger. Zwischen den Bytes sollte mindestens eine halbe Bitdauer Pause sein. Andere Fehlerursache könnte sein, dass das BTM eine gewisse Anzahl Bytes sammelt und erst dann versendet (Pakete) - und währenddessen eintreffende Bytes verwirft ? Oder reicht der Buffer im BTM nicht ?
Grüße,
Bernhard

[damfino]

Deswegen habe ich die 150ms Pause eingebaut, hatte auch mit anderen Werten experimentiert, bis zu 1s. In 1s sollte jeder Buffer leer und jedes Paket gesendet sein.
Aber je länger die Pausen, desto weniger Daten kommen in Summe an.
Komplett ohne jede Pause gehts am Besten, eben nur max ~2600 Bytes.

Hatte auch je 8 Byte zu einer Nachricht zusammengefasst, damit eben nicht nur einzelne Bytes als Datenpakete rausgehen, die gesamte Datenmenge war wieder geringer.

Beim flashen gehen aktuell 100kB übers BTM, daran sollte es nicht liegen.

[oberallgeier]

.. 4kB EEPROMS über Bluetooth an den PC schicken, einfach mal ans HTerm ..Wer organisiert das denn? Ein Mikrocontroller? Welcher? Wie wird empfangen ? Bluetoth

Hast Du schon mal versucht alle diese Zeichen über ne simple UART-Verbindung an das Terminal zu senden ? (HTerm war nie mein Fall, zu viele symbolisch dargestellte Steuerzeichen, ich nehme das Terminal von br@y) Nur so, an meinem Hinterkopf kribbeln die Haare wenn ich an so einen Speicherbereich in EEPROMs denke. Warum? Ich würde mal die Lesezeit laut Datenblatt mit der geübten Übertragungsrate vergleichen. Nicht, dass der Input zu langsam tröpfelt und der Datenstrom schon an der Quelle abreisst ? ? ? Passen die Standards der beiden Blauzahn-Stationen zu einander - anders: hatte die benutzte Verbindung schon mal längere Zeit gehalten? (Ok, einmal klappen sollte eigentlich heißen: auch immer klappen). Welche Störeinflüsse ? D.h. vielleicht blöken da ein paar Handys dazwischen, ne Kaffeemaschine, eine Zahnbürste oder so?

[BMS]

Das BTM-Modul müsste mit den AT Befehlen auch einen Echo-Modus unterstützen, damit könnte man prüfen, ob jedes vom uC gesendete Byte auch richtig vom BTM gelesen wurde...

Andere denkbare Ursache: Die Daten stehen nicht richtig im EEPROM ab den 2,6kB...? Oder ist zufällig eine Sequenz im EEPROM abgelegt, die das BTM in den AT Modus schaltet (+++ o.ä.) ?

Gut, das ist alles Spekulation, aber irgendwie muss man sich der Lösung langsam nähern...

Grüße, Bernhard

[damfino]

Für direkte UART Verbindung muss ich erst mal ein paar Kabel basteln.

Verdacht auf langsames EEPROM hatte ich auch, deswegen so getestet:

for (tempx=0;tempx<4096/8;tempx++)
{
for (i=0;i<8;i++)
{
temp++;
daten[i]=eeprom_read_byte((const uint8_t *)temp);
// sprintf(tx_funk,"%d",daten);
// Funk_Transmit_s(tx_funk);
}
sprintf(tx_funk,"%d,%d,%d,%d,%d,%d,%d,%d"CR,daten[0],daten[1],daten[2],daten[3],daten[4],daten[5],daten[6],daten[7]);
Funk_Transmit_s(tx_funk);_delay_ms(200);
//x++;if(x>5) {x=0;Funk_Transmit_s(CR);_delay_ms(150);}

}

Bringt absolut nichts.

Im EEPROM sind nur Zahlen abgelegt.

Wenn die Datenübertragung beendet wird, springt das Programm aus dieser Routine zurück und geht es natlos mit den 4 Datensätzen weiter.
Die Verbindung steht also, und funktioniert.
Es kommen bei den Datensätzen ca 400Bytes/s an, also Daten inklusive Steuerzeichen.
Der letzte Code oben übermittelt viel weniger Daten pro Sekunde.

Die Verbindung halt stundenlang...

So, kann erst am Abend weitermachen, Kindergeburtstag