Maskenversion 7.5

[uwe223]

Hallo zusammen,
ich habe mal angefangen einen MDT 4-Kanal LED-Controller auf dem ARM zu programmieren.
Das funktioniert auch schon teilweise, aber leider nicht mit der aktuellen Applikation weil diese nicht die MV 0701 sondern die MV 0705 benötigt, welche von der SB-Lib momentan nicht unterstützt wird.
Kann da jemand helfen?

Gruß
Uwe

[Olli]

Hallo Uwe,

zufällig bin ich heute genau über die gleiche Stelle gestolpert.
Ich programmiere zwar zur Zeit kein BIM112 Gerät, brauchte aber die Größen der EEPROM Tabellen.
Dabei ist mir auch aufgefallen, dass einige Geräte bereits höhere Versionen verwenden.

Anbei ist ein Dokument über die Memory Table einer BIM112.

Hier wurde geschrieben, dass bei MV 0701, als auch bei 0705 die Startadresse von 4000h gilt.
https://support.knx.org/hc/en-us/articl ... -0701-0705

So unterschiedlich sind die also wohl nicht.

Was jetzt allerdings genau der Unterschied zwischen den MVs ist, weiß ich nicht.

Wie äußert sich denn bei dir die Inkompatibilität?

Grüße,
Olli

[uwe223]

Hallo Olli,
ich hab in der sblib bcu_type.h einfach mal MASK_VERSION und BIM112_TYPE auf 0x0705 geändert.
Da lief die Programmierung schon mal ein Stück durch, aber nur bis zur Speicherstelle 0x4AFF(und schlägt damit logischerweise fehl).
Beim Original wird bis zur Speicherstelle 0x4DD9 geschrieben.
Wenn ich jetzt die in bcu_type.h hinterlegten Werte für USER_EEPROM_START = 0x3f00 und USER_EEPROM_SIZE = 3072(=0x0C00) addiere komme ich genau auf die beobachteten 0x4AFF.
Also habe ich USER_EEPROM_SIZE mal auf 3802 erhöht.
Damit hängt sich der ARM aber schon beim programmieren der PA auf.
Aber so wirklich Ahnung von der lib, den Speicherbereichen und wie das zusammenhängt hab ich nicht

[Olli]

Hallo,

ich habe mal den Aktor von Florian angesehen (out-cs-bim112)
Dort hat er wohl ein ähnliches Problem gehabt:
app_main.cpp Zeile 120:
// 12 Bytes der Aktorkonfiguration werden ab 0x4B00 geschrieben. Das liegt bloederweise
// genau jenseits des USER-EEPROM. Also mappen wir virtuellen Speicherbereich dorthin.
memMapper.addRange(0x4b00, 0x100);
Damit scheint er den Speicherbereich nach 0x4AFF zu ergänzen.
Ich hatte mich da mal mit beschäftigt, aber so aus dem Stehgreif bekomme ich es auch nicht mehr zusammen.
Eventuell ist da was an der sblib User EEPROM Tabelle für die BIM112 auch nicht ganz korrekt?!

Grüße,
Olli

[uwe223]

Danke für den Tipp.
Das scheint genau die Lösung für mein Problem zu sein.
Ich hab das auch gleich mal ausprobiert, leider ohne Erfolg. So sieht die app_main jetzt aus:

Code: Alles auswählen

#include <Appl.h>
#include <sblib/eib.h>
#include <sblib/eib/user_memory.h>
#include <sblib/eib/sblib_default_objects.h>
#include <string.h> /* for memcpy() */
#include "MemMapperMod.h"
#include <sblib/usr_callback.h>
#include "config.h"
#include <sblib/serial.h>  //debugging only


extern MemMapperMod memMapper;
/*
 * Der MemMapper bekommt einen 1kB Bereich ab 0xEA00, knapp unterhalb des UserMemory-Speicherbereichs ab 0xF000.
 * Damit lassen sich 3 Pages (je 256Byte) (und die allocTable die MemMappers) unterbringen.
 * Benötigt werden zwei Pages:
 * - für den Konfigurationsspeicher jenseits von 0x4B00. Für die SbLib endet der Konfigurationspeicher dort,
 *   unser Vorbild legt dort jedoch noch einige allgemeine Optionen ab.
 * - für die Systemzustände. Diese werden bei Busspannungsausfall und Neustart abgespeichert.
 */
MemMapperMod memMapper(0xea00, 0x400);
//AppUsrCallback usrCallback;

const HardwareVersion * currentVersion;
unsigned int pwmmax;		//  je nach Parametrierung PWM_MAX_600 oder PWM_MAX_1000

/**
 * Application setup
 */
void setup()
{
	serial.setTxPin(PIO3_0);	//debugging only
	serial.begin(115200);		//debugging only
	currentVersion = &hardwareVersion[HARDWARE_ID];
	bcu.begin(MANUFACTURER, currentVersion->deviceType, currentVersion->appVersion);
	// _bcu und bcu sind das gleiche Objekt.
	 // _bcu ist vom Typ BCU, während bcu vom Typ BcuBase ist.
	 _bcu.setMemMapper((MemMapper *)&memMapper); // Der BCU wird hier der modifizierte MemMapper bekanntgemacht
	 //_bcu.setUsrCallback((UsrCallback *)&usrCallback);
	 _bcu.enableGroupTelSend(false);
	 //memcpy(userEeprom.serial, SerialNumber, sizeof(SerialNumber));
	 // 12 Bytes der Aktorkonfiguration werden ab 0x4B00 geschrieben. Das liegt bloederweise
	 // genau jenseits des USER-EEPROM. Also mappen wir virtuellen Speicherbereich dorthin.
	 serial.print(memMapper.addRange(0x4b00, 0x300));
	 //memMapper.addRange(0x0, 0x100); // Zum Abspeichern/Laden des Systemzustands
	 //objectEndian(LITTLE_ENDIAN);
	 //userEeprom.commsTabAddr = 0x4400; // Diese Basisadresse wird nicht über die ETS runtergeschrieben, ist aber notwendig!
	 //setUserRamStart(0x3FC);
	//// FIXME for new memory mapper
    memcpy(userEeprom.order, currentVersion->hardwareVersion,
            sizeof(currentVersion->hardwareVersion));
    initApplication();
}

/**
 * The application's main.
 */
void loop()
{
    int objno;
    // Handle updated communication objects
    while ((objno = nextUpdatedObject()) >= 0)
    {
        objectUpdated(objno);
    }

    checkPeriodic();

    // Sleep up to 1 millisecond if there is nothing to do
    if (bus.idle())
        waitForInterrupt();
}

Die serielle Debug Ausgabe von memMapper.addRange ist 0, also war das eigentlich Erfolgreich.
Leider schreibt die ETS wie vorher nur bis 4AFF.

Gruß
Uwe

[Florian]

Also...: Die USER_EEPROM_SIZE direkt zu modifizieren habe ich noch nie versucht, daher kann ich zu dem aufgetretenen Fehler nichts sagen.

Zum MemMapper: Was zeigt die ETS als Fehler? Die Adresse 0x4B00? Du schreibst nur "es funktioniert bis 0x4AFF". Was ich damit meine: Versucht die ETS tatsächlich bei 0x4B00 weiterzuschreiben? Oder macht sie vielleicht etwas anderes?

Bei meinen Versuchen hat sich als praktisch erwiesen, die Kommunikation auf dem Bus im Bus-Monitor zu verfolgen. Allerdings ist der von der ETS nicht ganz einfach zu lesen, weswegen ich mir schliesslich einen erweiterten Monitor geschrieben hatte, der im USB-Interface gelandet ist.

Wenn tatsächlich über 0x4B00 geschrieben wird, versuch doch mal mit dem Debugger die ganze Geschichte zu verfolgen. Dabei lernt man dann schnell die Innereien der sblib genauer kennen, als einem eigentlich lieb ist. So war es zumindest bei mir.

[Florian]

Noch eine Anmerkung zum MemMapper: Stelle sicher, dass sich im Verwaltungs-Speicherbereich des Mappers kein Datenmüll befindet. Also beim Programmieren des uC den ganzen Programmspeicher löschen, aber nicht freie Bereiche mit 0 füllen lassen.

[uwe223]

Die ETS sendet ja die Daten in 12 byte Blöcken zur bcu und die sendet den gespeicherten Block wieder zurück zur ETS. Stimmen beide überein gehts weiter. Beim Block ab 4AFC ist das erste byte noch ok, aber Nr. 5 und 6 kommen nicht mehr zurück.
Die ETS meldet dann "Schreiben in den Speicherbereich fehlgeschlagen".
Ich habe hier den Original MDT LED-Controller und da wird bis zur Adresse 4DD9 geschrieben.
Den Programmspeicher hab ich gerade nochmal komplett gelöscht, hilft aber auch nicht.
Ich schau mal weiter.

[Florian]

Gut, dass Du das Bild eingestellt hast. Denn da dämmert es mir: Das Problem war mir mal aufgefallen. Leider habe ich es dann aber wieder vergessen und nicht behoben:

Es wird versucht, in einem Zugriff über die Grenze von normal implementiertem Speicherbereich zu per MemMapper implementiertem Speicherbereich zu schreiben/lesen. Das geht momentan in der sblib nicht.

In bcu.cpp, void BCU::processDirectTelegram(int apci), APCI_MEMORY_WRITE_PDU kann man erkennen, wie je nach Adresse die Zugriffe auf die verschiedenen Speicher aufgeteilt werden. Das ein Teil des Zugriffs auf den einen Speicher, und ein weiterer auf einen anderen Speicher weitergeleitet wird, ist nicht vorgesehen. Das müsste man umschreiben.

[uwe223]

Na sagen wir mal so: Ich hab mir die Stelle angesehen und kann nachvollziehen was du meinst.
Das zu fixen übersteigt meine Programmierkentnisse aber deutlich .
Ich werde also erstmal mit der älteren Applikation weitermachen, da funktioniert das Programmieren per ETS und einige Dimmfunktionen schon einwandfrei.

Gruß
Uwe