Betty Scart als CUL-Ersatz

[KölnSolar]

Dem Scart-Adapter widme ich mal einen eigenen Thread.  Den Scart müsste man doch fast als Betty-Scart-CUL mit eingeschränkter Funktionalität(nur 8kB flash) umbauen können... Dank des Netzteils dann als RF_Router überall einsetzbar oder die Versorgung auf USB umbauen.

gegebene Hardwarevoraussetzungen:
CC1100 mit 27 MHz an P89LPC931(8bit µC 18MHz, 8kB flash, 256B RAM)  und 2 16b-timer, UART, SPI, I2C
64kB EEPROM(AT24C64A),
JTAG-Interface
herausgeführte Anschlüsse: RX, TX, ICP-PDA, ICP-PCL, GND, ICP-Reset, Vcc(3,3V)
Betrieben über 230V mit Wandler auf (gemessene) 7V DC.
Status-LED

Laienhaft stelle ich mir jetzt vor, dass man sich die Sourcen der (a)-culfw schnappt. Weil CUBe in der a-culfw bereits für einen nicht-ATMega-Prozessor angepasst wurde, diese als Basis nehmen und board.h, sowie die main.c an die prozessorspezifischen Gegebenheiten anpassen.

Klingt ein bißchen einfach, oder ?

Zumindest bedarf es erst einmal den einfachsten Weg für eine Toolchain zu finden. Nach meinem Kenntnisstand muss man auf der SDCC aufsetzen, da diese den Prozessor unterstützt.

Das Flashen geht über mehrere Wege. Um nicht extra basteln zu müssen ohne Kombi-Interface. Im Wiki ist der Weg über die Betty beschrieben. Das hat auch anstandslos mit der in den Betty-Sourcen enthaltenen scart_image.h geklappt  Für die vollständige Nutzung müsste ich aber noch das Winbin installieren, was ja immer umständliche zusätzliche Schritte bedeutet 
Unklar ist mir die Variante mit dem FT232RL. Im Bettyhackforum komme ich nicht an Anhänge dran(weil ich nicht angemeldet bin oder gibt es die gar nicht mehr ?). Lässt sich Betty-Scart evtl. wie die Betty direkt an einen FTDI-Wandler anschließen und dann mit Betty-Heaven flashen ? Wie ist dann zu verdrahten ?

Grüße Markus

[Telekatz]

Anbei das FT232RL Programmierinterface, das ich damals erstellt hatte sowie die dazu passende Software.

[KölnSolar]

Hi Telekatz,

auf Dich ist doch wie immer Verlass   

Hab mir jetzt mal den Schaltplan auf die Schnelle angeguckt. Das ist doch dann nicht (viel ?) anderes als mein fertig gekaufter USB - FT 232R - Wandler. Dran an den  7-poligen Betty.Scart-Anschluss, oder liege ich da falsch ? Ich hab ja RXD,TXD,RTS,CTS, und RI. evtl. noch einen 10K Widerstand zwischen CTS u. DCD. Aber was steuert PWREN und die beiden Transistoren ?  Nur die Spannungsversorgung des Betty-Scart ? 3,3V liefert mein Wandler direkt. DSR könnte ich doch auch "händisch" auf DTR brücken, sofern benötigt.

Das Flashprogramm läuft leider nicht unter Win10 und getesteten Kompatibilitätsmodi    (ohne angeschlossenes Betty-Scart)

Edit: Mit Deiner Erfahrung des CUBe-culfw-Umbaus: Ist das überhaupt ein halbwegs sinnvoller Ansatz einen Betty-Scart-CUL zu "bauen" ? Kann doch eigentlich nicht so kompliziert sein, vorhandene ATMEGA/AT91SAM7-Sourcen auf den LPC umzubauen. Worin siehst Du die größten Probleme ?

[Telekatz]

Hab mir jetzt mal den Schaltplan auf die Schnelle angeguckt. Das ist doch dann nicht (viel ?) anderes als mein fertig gekaufter USB - FT 232R - Wandler. Dran an den  7-poligen Betty.Scart-Anschluss, oder liege ich da falsch ? Ich hab ja RXD,TXD,RTS,CTS, und RI. evtl. noch einen 10K Widerstand zwischen CTS u. DCD. Aber was steuert PWREN und die beiden Transistoren ?  Nur die Spannungsversorgung des Betty-Scart ? 3,3V liefert mein Wandler direkt. DSR könnte ich doch auch "händisch" auf DTR brücken, sofern benötigt.

Die Transistoren schalten die Versorgungsspannung, um den LPC automatisch in den Programming Mode zu bekommen.

Das Flashprogramm läuft leider nicht unter Win10 und getesteten Kompatibilitätsmodi    (ohne angeschlossenes Betty-Scart)

Der Sourcecode ist mit dabei. Einfach mit Visual Studio neu Kompilieren.

Edit: Mit Deiner Erfahrung des CUBe-culfw-Umbaus: Ist das überhaupt ein halbwegs sinnvoller Ansatz einen Betty-Scart-CUL zu "bauen" ? Kann doch eigentlich nicht so kompliziert sein, vorhandene ATMEGA/AT91SAM7-Sourcen auf den LPC umzubauen. Worin siehst Du die größten Probleme ?

Das größte Problem sind die 8kB Flash und 256 Byte RAM.

[KölnSolar]

Hi Telekatz,
wie im anderen Thread besprochen muss ich ja die cc1100.c mit den defaults der cc1100 von boop befüllen. An Unterschieden habe ich diese Registerinhalte ausgemacht:

Code Auswählen Erweitern

    0x05   // PKTCTRL0      Packet Automation Control
    0x00   // CHANNR        Channel Number
    0xE6   // FREQ0         Frequency Control Word Low Byte
    0x6C   // MDMCFG3       Modem Configuration
    0x04   // MCSM2         Main Radio Control State Machine Configuration
    0x0C   // MCSM1         Main Radio Control State Machine Configuration
    0xE9   // FSCAL3        Frequency Synthesizer Calibration
    0x2A   // FSCAL2        Frequency Synthesizer Calibration
    0x1F   // FSCAL0        Frequency Synthesizer Calibration Muss ich alle so setzen ? Bei CHANNR auf 0 ?

Nächster Schritt sind dann Toolchain f. betty_scart incl. dieser ulrichradig-software.

Grüße Markus

Edit: download sdcc f. x64 http://sourceforge.net/projects/sdcc/files/snapshot_builds/x86_64-w64-mingw32-setup/sdcc-20201012-11914-x64-setup.exe/download u. Installation; anpassen der makefiles in betty_scart an den gewählten Installationspfad.
Windoof machte dann mehrfach Ärger u. lies den Dateizugriff nicht zu(Viren- u. Bedrohungsschutz). Lässt man den Zugriff zu, ergibt sich dieser Output

Code Auswählen Erweitern

C:\Users\Public\Fhem\boop\betty_scart>make all
C:/Tools/SDCC/bin/sdcc -mmcs51 --iram-size 0x100 --model-small --code-size 8096 -IC:/Tools/SDCC/include --std-sdcc99 -Dcode=__code -Didata=__idata -Dbit=__bit -c main.c
main.c:146: warning 126: unreachable code
C:/Tools/SDCC/bin/sdcc -mmcs51 --iram-size 0x100 --model-small --code-size 8096 -IC:/Tools/SDCC/include --std-sdcc99 -Dcode=__code -Didata=__idata -Dbit=__bit -c serial.c
C:/Tools/SDCC/bin/sdcc -mmcs51 --iram-size 0x100 --model-small --code-size 8096 -IC:/Tools/SDCC/include --std-sdcc99 -Dcode=__code -Didata=__idata -Dbit=__bit -c cc1100.c
C:/Tools/SDCC/bin/sdcc -mmcs51 --iram-size 0x100 --model-small --code-size 8096 -IC:/Tools/SDCC/include --std-sdcc99 -Dcode=__code -Didata=__idata -Dbit=__bit -c cmd.c
C:/Tools/SDCC/bin/sdcc -mmcs51 --iram-size 0x100 --model-small --code-size 8096 -IC:/Tools/SDCC/include --std-sdcc99 -Dcode=__code -Didata=__idata -Dbit=__bit -c rf.c
rf.c:86: warning 126: unreachable code
C:/Tools/SDCC/bin/sdcc -mmcs51 --iram-size 0x100 --model-small --code-size 8096 -IC:/Tools/SDCC/include --std-sdcc99 -Dcode=__code -Didata=__idata -Dbit=__bit -c timer.c

Linking main.rel serial.rel cc1100.rel cmd.rel rf.rel timer.rel
C:/Tools/SDCC/bin/sdcc -mmcs51 --iram-size 0x100 --model-small --code-size 8096 -IC:/Tools/SDCC/include --std-sdcc99 -Dcode=__code -Didata=__idata -Dbit=__bit main.rel serial.rel cc1100.rel cmd.rel rf.rel timer.rel -o betty_scart.ihx
C:/Tools/SDCC/bin/packihx betty_scart.ihx > betty_scart.hex
packihx: read 134 lines, wrote 239: OK.
cat betty_scart.hex | C:/Tools/SDCC/bin/makebin -s 8096 > betty_scart.bin

C:\Users\Public\Fhem\boop\betty_scart>die warnings tun hoffentlich nicht weh 

next step: ulrichradig-software....

[KölnSolar]

Hi telekatz,
nach wie immer langer Quälerei, bekomme ich betty_scart kompiliert u. per Betty geflashed(das größte Problem war, dass man das image nicht komplett, sondern nur mit 7 Sektoren in die scart_image_data.h eintragen darf).
Was kann man mit betty_scart machen(zum Test), wenn man den Adapter nicht seriell am PC angeschlossen hat? Die LED blinken lassen? Die ist doch an P1.0(Pin18) oder ?
Port2 wird ja gar nicht genutzt. Dort ist ja auch das SPI-interface. Meinst Du, dass ich da meinen TFT anbinden könnte ?
Grüße Markus

[KölnSolar]

Hi Telekatz,
ich hab mir jetzt mal eine Blinkroutine eingebaut, so dass ich etwas debuggen kann, welche Programmteile durchlaufen werden.
Dabei hab ich nun festgestellt, dass der RF-Teil irgendwie nicht funktioniert. Wenn ich einen ping von der Betty(oder vom Betty-CUL) sende, bleibt die LED stumm, obwohl sie direkt am Anfang der interrupt-Routine aufgerufen wird. Ich hatte ja die CC1100.c an die Konfiguration von boop angepasst. Daran kann es also nicht liegen. Ich hab auch keinen Programmteil entdeckt, wo evtl. die Konfiguration noch einmal verändert wird. Bleibt mein einziger Gedanke: kann es sein, dass betty_scart nicht "wach" wird ? Muss ich da evtl. noch was anpassen ?
Ich les dann mal weiter zu dem Interrupt u. wor.
Grüße Markus

[Telekatz]

An WOR liegt es nicht. Da der Scart Adapter nicht Batterieberieben ist, muss man da den CC1100 nicht schlafen legen, um Energie zu sparen.

[KölnSolar]

OK, ich dachte das wäre wie bei boop(Strom sparen kann man doch immer  )

Ich bin dann noch einmal in den Vergleich der config für boop u. betty_scart(jeweils SVN-Version) eingestiegen und stellte fest, dass MCSM1 u. MCSM2 unterschiedlich waren. Ds habe ich nun wieder auf den ursprünglichen Wert gesetzt und schon blinkt der Adapter bei einer ping-Anforderung durch die Betty. Ein ACK kommt aber noch nicht bei der Betty an. Hängt vielleicht mit Verzögerungen durch meinen blink-code zusammen. Schaue ich mir morgen an.....

noch nicht gelöst aber ein Schrittchen weiter: betty_scart(addr=1) antwortet nicht auf den ping der Betty(addr=3) oder FHEM-Betty_01 . Die LED blinkt 2-mal.
Ein ping von FHEM-Betty_03 wird von betty_scart anstandslos beantwortet mit 4-fach blinken. Die Anz. des Blinkens ist gleich der Länge des frames u. wird nach Abschluss der Empfangs-/Sendeaktivität ausgeführt.
Lustiger Effekt: ping-request der betty und nachfolgender ping-request von  FHEM-Betty_03 führt zu einem ping-received auf der Betty(und dann auch in FHEM-Betty_01 ).
Folglich ist im Grundsatz der Empfang u. das Senden des pings nun OK. Fraglich warum der ping von der betty von betty_scart nur mit der Länge 2 empfangen wird. Ebenso der ping von FHEM-Betty_01.
(broadcast(addr=0) zeigt dasselbe Verhalten)

Nun das Blinken auf die konkrete empfangene Länge des frames eingestellt. Unterschied: bei betty u. FHEM-Betty_01 2*2, also 4-mal mit kurzer Pause. Ich interpretier das mal als nicht mind. Länge 3 erkannt. Hingegen blinkt es 5-mal, wenn ich mit FHEM-Betty_03 sende. 5-mal bei einem frame der Länge 4 ?
Das war dann der neue Ansetzpunkt. im source wird eine Struktur "missbraucht". Dadurch ist der Blick "verwässert". Das umgestellt auf eine eigenständige Variable zur besseren Lesbarkeit und den blink-code komplett entfernt, funktionieren auch die vorher fehlerhaften pings. ==> es war also irgendein timing-Problem.

Nun haben wir also mit meinen Arbeiten ein etwas erweitertes(ping) FHEM-Betty u. eine den in 2017 geänderten Funkeinstellungen angepasstes betty_scart, dessen Funktion sich per ping prüfen lässt.

@Telekatz:
Soll ich meine Anpassungen mal hier ablegen und Du stellst sie bei Dir ins GitHub ?

Grüße Markus

[KölnSolar]

da Du Dein github zu boop "aktualisiert" hast, hier die Veränderungen zu betty_scart u. 10_Betty

10_Betty - additional command ping; new reading ping: set to xy_send, if a ping_request was send by xy(addr of sending device); set to xy_ack if ping was received and answered

betty_scart
cc1100.h - typo corrected
cc1100.c - adjustment to new rf-settings of boop and FHEM-Betty; typo corrected
rf.c         - new variable length to differentiate between  length of read bytes vs. length-byte in received frame

Grüße Markus