Hallo zusammen,
viel gibt's im Forum zu Hausbus-Projekten jeglicher Art, aber auch mit
reichlich Suchfunktion habe ich keine Antwort auf die obige Frage
gefunden: hat hier schon jemand versucht, die ABB US/U für
KNX-Eigenentwicklungen zu nutzen?
Außer einem ATmega32 mit Firmware-Aufkleber und einem Busankoppler ist
nicht viel in den Dingern drin - dafür mag man 33 Euro teuer finden,
aber mit Gehäuse inkl. Mwst. sind sie sogar günstiger als viele
Experimentierboards mit KNX-Ankoppler...
Viele Grüße - Stefan
An sich ganz interessant.Hast du Fotos von dem Innenleben? Ist da noch
ein blue chip oder tpuart drin? Oder ist der bus diskret angekoppelt?
Aber ansonsten wäre ein kleines Atmega board (z.B. Atmega 1284P oder
pinkompatibel) mit tpuart2 (6.50€) oder NCN5120 ($3.80) mal eine
Projektidee für eine Sammelbestellung.
Da ist ein ABB Blue Chip drin. Was ich so charmant finde, ist, dass der
Aufbau getestet ist und ein kleines, in Unterputz-Dosen passendes
Gehäuse hat.
Der NCN ist aber in der Tat auch interessant - hat hier jemand eine
lauffähige Platine damit? Beim TPUART2 braucht man noch einiges an
Kleinfutter, oder?
Ich hatte so ein Ding auch schon offen - die Belegung der sechs auf der
Platine befindlichen Pads entspricht der des Standard-Programmier-Kabels
mit sechs Adern... ;-)
@k.nix: anbei die Bilder, einmal in klein und einmal in groß.
@smf: und? was ist dabei rausgekommen?
Die ganzen Logik-Module etc. sind ja doch "etwas" teurer und weit
weniger flexibel als ein selbst geschriebenes ATmega-Programm!
Stefan schrieb:> @k.nix: anbei die Bilder, einmal in klein und einmal in groß.
Tip top. Ist mit blue chip ;)
Wie sind die Verbindungen zwischen atmega und blue chip?
Das sollten nur so 2-6 Leitungen sein.
> @smf: und? was ist dabei rausgekommen?>> Die ganzen Logik-Module etc. sind ja doch "etwas" teurer und weit> weniger flexibel als ein selbst geschriebenes ATmega-Programm!
Ja, dann müsste man noch nen open source knx stack basteln, Ansätze gibt
es hier ja schon (codesammlung).
Auf den ersten Blick sind da etwa 5 Leitungen, mit der Info von smf ist
mindestens die Reset-Leitung ;-) verbunden. Durchgemessen hab ich die
anderen Pins noch nicht.
Was ist am BlueChip "tip top"? Ich kenn den nicht...
Stefan schrieb:> Auf den ersten Blick sind da etwa 5 Leitungen, mit der Info von smf ist> mindestens die Reset-Leitung ;-) verbunden. Durchgemessen hab ich die> anderen Pins noch nicht.
Es gibt zum blue chip leider keine freie doku.
> Was ist am BlueChip "tip top"? Ich kenn den nicht...
Die Bilder sind tip top, danke dafür.
Der blue chip stellt noch eine ganz brauchbare Stromversorgung zur
Verfügung, da kann man auch über 10mA ziehen ohne dass der Bus
überlastet wird.
Stefan schrieb:> @smf: und? was ist dabei rausgekommen?
Das war nur zu Backup-Zwecken, da ich eibd verwende und im dortigen
Handbuch steht, dass diverse Operationen die Geräte "unbrauchbar" machen
können. Falls dieser Fall eingetreten wäre, hätte ich ein Backup gehabt.
interessant. die 2er und die 4er sehen bis auf ein paar SMD R und C
identisch aus. Hab mir so etwas schon gedacht. Hat einer von euch schon
mal versucht die R&C aufzulöten und aus nem 2er Interface nen 4er zu
machen?
Wo bekommt man die Teile für 33 Euro?
Das habe ich bisher nicht probiert, da ich annehme, dass die Firmware
verschieden ist und die 4er Applikation folglich gar nicht richtig
funktioniert (es wird nur der Teil oberhalb 0x4000 durch die Firmware
beschrieben).
Hallo Stefan (Gast),
wenn du der Stefan (Gast) bist der den MSP430-Akkulader
in mikrocontroller.net gestellt hast....
Ich hätte da mal ne Frage. siehe Beitrag
oder direkt an runout (wie immer das geht)
Grüße runout
@runout: nope, tut mir leid. "Stefan" ist ja, wie man auch hier sieht,
eher ein Sammelbegriff als ein Name. :-/
@cmalo: zum Thema Applikation ist mir noch eingefallen: wenn man sich
die offiziellen ABB-knxprod-Dateien für die ETS4 anschaut (die
Speicherbereiche der Applikationsprogramme sind mit aussagekräftigen
Tags im xml-File als base64-Segmente abgelegt), scheint der einzige
Unterschied zwischen 2er und 4er Applikation ein
cpi R26, 0x0F ;4er, binär: 0000 1111
versus
cpi R26, 0x03 ;2er, binär: 0000 0011
an Adresse 0x480C zu sein. Spricht einerseits stark dafür, dass die
Dinger "sehr ähnlich" sind, und andererseits dafür, dass die Firmware
irgendwo noch die Info hat, wieviele Kanäle "vorhanden" sind. Solange
man das nicht auch ändert...
Stefan schrieb:> "Stefan" ist ja, wie man auch hier sieht,> eher ein Sammelbegriff als ein Name. :-/
@Stefan: ich saß mal in einem 28-Personen-Büro, 5 davon hießen Stefan...
> Spricht einerseits stark dafür, dass die> Dinger "sehr ähnlich" sind, und andererseits dafür, dass die Firmware> irgendwo noch die Info hat, wieviele Kanäle "vorhanden" sind. Solange> man das nicht auch ändert...
Vielleicht ist das auch die Codierung dafür und somit der einzige
Unterschied?
Stefan schrieb:>> Tags im xml-File als base64-Segmente abgelegt), scheint der einzige> Unterschied zwischen 2er und 4er Applikation ein> cpi R26, 0x0F ;4er, binär: 0000 1111> versus> cpi R26, 0x03 ;2er, binär: 0000 0011> an Adresse 0x480C zu sein. Spricht einerseits stark dafür, dass die> Dinger "sehr ähnlich" sind, und andererseits dafür, dass die Firmware> irgendwo noch die Info hat, wieviele Kanäle "vorhanden" sind. Solange> man das nicht auch ändert...
Manchmal wird das über Spannungsteiler am ADC oder Codierwiderstände bei
der Bestückung festgelegt.
Was wird denn in R26 reingeladen?
Keine Ahnung - da wird vorher irgendeine (mir unbekannte) Funktion
aufgerufen. Kann ja auch sein, dass es irgendwo im EEPROM codiert ist.
Meine ursprüngliche Idee ging auch nicht unbedingt dahin, die 12+e Euro
von US/U 2.2 auf 4.2 zu sparen, sondern den ATmega darin mit seinem
Busanschluss zu recyclen. So wie's aussieht, ist das mit den (nicht
vorhandenen) Informationen zum BlueChip aber nicht ganz einfach.
Auf den US/Us hab ich folgende Leitungen nachverfolgt:
Blue-Pin 5 -> ATmega-Versorgung Pin 5 (VCC)
Blue-Pin 8 -> EIB+ über SK18
Blue-Pin 9 -> ATmega-Pin 15 (PD6/ICP1)
Blue-Pin 10 -> ATmega-/Reset Pin 4 (RSET)
Blue-Pin 11 -> ATmega-Pin 11 (PD2/INT0)
Blue-Pin 13 -> ATmega-Pin 14 (PD5/OC1A)
Blue-Pin 14 -> Board-GND inkl. ATmega-GND div. Pins (GND) und EIB-
Blue-Pin 16 -> ATmega-Pin 30 PA7 (ADC7)
Würde zumindest ganz gut zu den Infos hinter Roberts Link passen. Die
anderen hab ich entweder nicht gefunden oder nicht zuordnen können.