Hilfsgesuch Arduino Leonardo und CUL_V3

[naicheben]

Hallo,
ich bin Ingmar und lese seit ein paar Tagen hier im Forum. Ich habe Lust und Zeit CUL_v3 auf mein Arduino Leonardo zu bekommen, stoße aber an meine Grenzen was das Verständnis angeht.
Hier mal was ich bisher gemacht habe:
AVR-DFU Firmeware über avrdude mit Stange ISP-Programmer geflasht.
Culfw runtergeladen und in Devices/CUL CUL.c , prescaler auf 2, dann mit make clean, make und sudo make usbprogram_v3 den Leonardo geflasht. Dann meldet der sich aber immer noch als DFU Device. Resette ich ihn, oder starte mit sudo dfu-programmer start, bekomme ich nur unable to enumerate USB device.
Müsste der nicht unter Linux als /dev/ttyACMx oder zumindest /dev/ttyUSBx hochploppen?
Vielleicht habe ich mir auch bei meinen Experimenten die Fusebits vergurkt.
Hat einer von Euch das auf einem Arduino Leonardo laufen und kann mir da etwas unter die Arme greifen?

Danke fürs Lesen

[juergs]

Schau mal hier: http://dokuwiki.ehajo.de/artikel:atmega_u-howto:go2bootloader

Dort steht:
Sollte man bereits ein Programm auf den Controller gespielt haben welches keine Möglichkeit bietet, den Boot-Reset-Vector anzuspringen kann man sich über den HWB-Pin helfen. Standardmäßig ist die Fuse HWBE programmiert, dies bedeutet, dass der Bootloader mit Hilfe von PD7/HWB aktiviert werden kann. Das gelingt durch folgende Schritte:

    PD7/HWB mit GND verbinden  (Anm.: und nach dem Reset wieder loslassen)
    einen Reset auslösen (RESET kurz mit GND verbinden)

Hier die "Leonardo ähnlichen"-FAQs:
https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide/troubleshooting-and-faq

Soweit ich mich erinnere liegt PD7/HWB beim Leonardo dauernd auf GND. Ob das sich so mit der CUL-FW verträgt?
Hier http://www.busware.de/tiki-download_file.php?fileId=43, such dort mal nach dem Signal HWB ... und vergleiche mit hier:
http://forum.arduino.cc/index.php?action=dlattach;topic=108956.0;attach=20048 dort ist HWB dauerhaft mit GND über ein 10K Pulldown-R verbunden.

https://code.google.com/archive/p/micropendous/wikis/ProgramAndTestWindows.wiki
http://www.busware.de/tiki-index.php?page=DFU+Bootloader
http://dokuwiki.ehajo.de/bausaetze:display-adapter

Mit diesem Board funktioniert es: http://www.ehajo.de/boards/atmega32u4-breakout-board.html bei mir (mit DFU-Bootloader und CULFW) mit zwei Tastern an RESET und HWB.

Zugegebenermaßen bin ich über einen 8 MHz Quartz gegangen und habe den Prescaler gelassen. 

[naicheben]

Hallo Juergs,
danke für die vielen Links. Ich kann zwar google, aber die hab ich nicht wirklich alle selbst gefunden.

Den HWB-Pin habe ich mir schon abgelötet und das klappt auch ganz gut mit dem dfu-bootloader. Wenn ich aber die CUL Firmware draufspiele und mit dfu-bootloader atmega32u4 start die culfw starten will, bekomme ich im syslog nur "unable to enumurate..."
Ich kann ja verstehen, dass der 16MHz Quarz das Timing durcheinander bringt, aber dafür habe ich ja in CUL.c das select_prescale_1 auf 2 hochgesetzt.
Nun werde ich mich erst noch mal auf Deine Links von ehajo stürzen und schauen, ob ich das Leonardoboard umgebaut bekomme. Soweit ich das Board überblicke, habe ich sowieso Probleme mit den 5V, bzw muss Levelshifter oder Widerstandsteiler basteln für den cc1101. Aber es soll ja auch eine Bastelherausforderung sein

Vielen Dank noch mal und nur weiter so mit guten Tipps, bin für alles dankbar (auch gerne für original Fusebits vom CULV3- hab ich evtl auch vergurkt beim experimentieren)

[juergs]

Hi, klar googlen kann jeder ... 

Du hattest auch nicht alle Infos angegeben ... und hellsehen, .... na ja, man strengt sich an ....   

Es kommen auch nicht so viele Leute auf die Idee, den Leonardo als CUL zu verwenden, oder doch?

Bist Du sicher, dass das Setzen des Prescalers ausreicht?

Wie sieht es mit F_CPU im makefile aus?

Code Auswählen Erweitern

F_CPU = 8000000
FORMAT = ihex
OBJDIR = .


[naicheben]

Ich habe mal gelesen an der F_CPU sollte man besser nicht drehen, da richtet sich fast alles nach. Ich experimentiere noch mal mit CKDIV8 aus und dem clock_prescale_set(2), eigentlich muss das die Lösung sein, evtl mit F_CPU zusammen.
Wenn ich F_CPU auf 16000000 mache zickt der Compiler. Aber wie ich gerade sehe nur für CUL_V4. Die Hex für den V3 baut er.
Den teste ich nachher mal.

Übrigens: das mit dem Hellsehen klappt bei Dir ja schon hervorragend Den HWB-Pin habe ich zufällig beim Vergleichen der Schaltpläne vom CUL und Leonardo rausgefunden (nachdem ich hier die Frage rein gestellt hatte). Hatte direkt nach sowas gesucht, weil ich beim Lesen über den dfu-bootloader drüber gestolpert bin. Kaum lötet man den ab, kann man zwischen Bootloader und (nicht funktionierender) Firmware hin und her zappen. 

[naicheben]

Code Auswählen Erweitern

usb 2-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[246745.088061] cdc_acm 2-2:1.0: ttyACM0: USB ACM device


Vorher den dfu-bootloader von Atmelseite runterladen und auf den Atmega32u4 brennen (ich glaub Arduino baut da einen eigenen Bootloader rein, den hatte ich eh schon überschrieben)

Hier die Fuses:

Code Auswählen Erweitern

avrdude: safemode: Fuses OK (H:C3, E:99, L:5E) (ich glaub der vertauscht da was....)
Im makefile F_CPU auf 16000000
In CUL.c clock_prescale_set(clock_div_2);

Und noch ein mal ein fettes Dankeschön, dass Du mich bestätigt hast da weiter zu machen.
Wie hast Du den CC1101 angebunden an Dein Board?

[juergs]

Schau mal hier in den Thread:
und ff.
https://forum.fhem.de/index.php/topic,24651.msg419350.html#msg419350

Levelshifter mit 4K7/10K R's (SelbstbauCUL):
http://www.fhemwiki.de/wiki/Hauptseite

PS: das Ganze wäre auch für den Micro möglich, wenn man an HWB herankommt ....
Apropos googlen: https://forum.fhem.de/index.php/topic,45833.0.html

[naicheben]

Habe es soweit aufgebaut. MISO MOSI SCK geht über den ISP Port, aber SS bekomme ich nur an der RX-LED. Hab sie kurzerhand wieder abgelötet.
Der CUL ist in FHEM jetzt Initialized, kann aber noch nicht antworten. LED blinkt im Sekundentakt.(eine Sekunde an, eine Sekunde aus)
Fürs Erste nicht schlecht. Muss jetzt noch mal rausbekommen, warum ich nicht mit ihm sprechen kann.

[juergs]

Die LED ist nicht am D13 (PC7), sondern ist über ein OP, der als Puffer fungiert, über ein 1K-Widerstand an die Led angeschlossen.
Am Pin 1 des IC2A das Signal and der VIA zum Widerstand-Netzwerk (102) durchtrennen (dort lässt sich IO13 dann gut abgreifen) 
D13 an der Leiste liegt parallel, deshalb dort (nicht an der LED!)  -> Levelshifter + Pullup von 10K (je nach Lage an 5V oder 3V3). Das Ganze dann an SS  (CS) des CC1101.
Dann sollte es gehen ... CCCONF und set CUL raw e schaden nicht....

[naicheben]

Ich dachte es geht um den PORTB (ISP-Bus) B0-B3 wobei die MISO MOSI uns SCK am ISP verbaut sind und SS als RXLED an B0 hängt.

Code Auswählen Erweitern

#if defined(CUL_V3)      // not sure why libc is missing those ...
#  define PB0 PORTB0
#  define PB1 PORTB1
#  define PB2 PORTB2
#  define PB3 PORTB3
#  define PB6 PORTB6
#  define PD2 PORTD2
#  define PD3 PORTD3
#endif  // CUL_V3

#define SPI_PORT                PORTB
#define SPI_DDR                 DDRB
#define SPI_SS                  PB0
#define SPI_MISO                PB3
#define SPI_MOSI                PB2
#define SPI_SCLK                PB1

PC7 habe ich gar nicht benutzt. Der ist nur für CUL_V2 definiert:

Code Auswählen Erweitern

#if defined(CUL_V2)
#  define CC1100_CS_DDR         DDRC
#  define CC1100_CS_PORT        PORTC
#  define CC1100_CS_PIN         PC5
#  define CC1100_IN_DDR         DDRC
#  define CC1100_IN_PORT        PINC
#  define CC1100_IN_PIN         PC7


[juergs]

Sorry, hatte mich nur auf LED konzentriert und RX mit L getauscht:

aber SS bekomme ich nur an der RX-LED

Aber wahrscheinlich hatte ich doch an eher an PC7 für SS gedacht, weil einfacher zu erreichen....

Letztendlich gilt natürlich die CUL-Konfiguration ... (und im Prinzip auch das von mir gesagte ...)
aber das kann man ja ändern. 

So ginge es z.B. auch:

Code Auswählen Erweitern

  // CUL_V3
#define SPI_PORT PORTB
#define SPI_DDR DDRB
#define SPI_SS PB4   // ChipSelect CC1101 / LEO =>  #IO8 = D8  ( oder PB5 mit D9)
#define SPI_MISO PB3   // LEO: ICSP.1
#define SPI_MOSI PB2   // LEO: ICSP.4
#define SPI_SCLK PB1   // LEO: ICSP.3


und die Leonardo LED "L" umdefinieren:

Code Auswählen Erweitern


#if defined(CUL_V3)
#  define CC1100_CS_DDR SPI_DDR
#  define CC1100_CS_PORT        SPI_PORT
#  define CC1100_CS_PIN SPI_SS
#  define CC1100_OUT_DDR        DDRD
#  define CC1100_OUT_PORT       PORTD
#  define CC1100_OUT_PIN        PD3    // LEO TX-PIN INT3
#  define CC1100_OUT_IN         PIND
#  define CC1100_IN_DDR DDRD
#  define CC1100_IN_PORT        PIND
#  define CC1100_IN_PIN         PD2     // Leo RX-PIN INT2
#  define CC1100_IN_IN          PIND
#  define CC1100_INT INT2
#  define CC1100_INTVECT        INT2_vect
#  define CC1100_ISC ISC20
#  define CC1100_EICR           EICRA
#  define LED_DDR               DDRC
#  define LED_PORT             PORTC
#  define LED_PIN               7              // LEO: LED "L" an PC7 (D13)
#endif

[naicheben]

Jupp, so habe ich das verkabelt.
ccconf sagt:

Code Auswählen Erweitern

myCul ccconf => freq:6182.103MHz bWidth:270KHz rAmpl:33dB sens:8dB

das finde ich schon etwas komisch.

Code Auswählen Erweitern


CMDS
BbCFiAZNkGMKUYRTVWXefmLltux
Clients

:FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF
/dev/ttyACM0@38400 0000
DeviceName /dev/ttyACM0@38400
FD 11
FHTID 1234
NAME myCul
NR 47
PARTIAL

STATE Initialized
TYPE CUL
VERSION V 1.66 CUL868
initString X21
Readings
ccconf freq:6182.103MHz bWidth:270KHz rAmpl:33dB sens:8dB

2016-04-04 19:07:11
cmds B b C F i A Z N k G M K U Y R T V W X e f m L l t u x

2016-04-04 19:06:18
raw
No answer


Auch über Telnet bekomme ich nichts angezeigt. Wie kann ich denn sicherstellen, dass der ATMEGA mit dem CC1101 "spricht"?

EDIT: schon gut, er spricht ja. Kann zumindest die Register aus dem CC1101 auslesen. 
Danke für die Unterstützung!!!
Jetzt suche ich mir mal schöne Steckdosen aus.

[juergs]

Ob die Readings auch die richtigen Inhalte wiedergeben?
Blinkt die Led "L"  im Sekundentakt?

Probier mal mit

Code Auswählen Erweitern

mycul set raw e den CUL zurückzusetzen.
Das initialisiert den EEprom-Inhalt auf Std-Werte, wenn danach keine
passenden Werte mit ccconf angezeigt werden, "spricht" der Leonardo nicht korrekt mit dem CC1101!

siehe auch hier: https://forum.fhem.de/index.php/topic,24651.msg419350.html#msg419350

Wenn Du einen 2. Arduino hast, zum Prüfen (ob alles ankommt, insbesondere SS mit PullUp!) :
Arduino als Logic Analyzer -> funktioniert recht gut bis 4 MHz !
http://physudo.blogspot.de/2013/08/arduino-als-logic-analyzer.html

[naicheben]

Ich komme nicht weiter. Mit einem 433,92MHz Receiver sehe ich, dass der CUL sendet. Aber die Brennenstuhl will ums Verrecken nicht schalten. GDO0 und GDO2 habe ich auch mal getauscht=nix. set myCul raw e bringt mich in den Bootloader. Ich flashe also die Firmware neu, weil er nun nur noch in den Bootloader läuft. ccconf sieht immer noch komisch aus:
   

Code Auswählen Erweitern

ccconf: freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:4dB
cmds: B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
credit10ms: 469
fhtbuf: No answer
raw: No answer
state: Initialized
uptime: 0 00:00:25
version: V 1.66 CUL433

Die LED blinkt im Sekundentakt (Logictester)

Code Auswählen Erweitern

define initialUsbCheck notify global:INITIALIZED usb create
define myCul CUL /dev/ttyACM0@38400 1234
attr myCul rfmode SlowRF
attr myCul room Stube
attr myCul showtime 1
attr myCul verbose 5
define Schalter_ME_A IT 00000F0FFF FF F0
attr Schalter_ME_A IODev myCul
attr Schalter_ME_A ITrepetition 12
attr Schalter_ME_A model itswitch
attr Schalter_ME_A room Stube
define sz_Fensterleuchte_Ein IT 000000000F FF F0
attr sz_Fensterleuchte_Ein IODev myCul
attr sz_Fensterleuchte_Ein model itswitch
attr sz_Fensterleuchte_Ein room Stube
define BRENN_1 IT 00000F0FFF FF F0
attr BRENN_1 IODev myCul
attr BRENN_1 model itswitch
attr BRENN_1 room Stube

Was hat das mit den MARK_PIN_433 auf sich? Muss ich den auf LOW ziehen?8

EDIT: ich habe das jetzt auf dem lcd-adapter von ehajo laufen. Allerdings noch mit 16MHz. Ich bin mit meinem Latein am Ende. Pilight kann die Dosen schalten. Allerdings nicht mit dem CUL sondern Pilight_usb_nano

[juergs]

Ok, dann müssen wir die Infos mal aufdröseln:
Du hast jetzt 2 Culs.
1. Leonardo
2. ehajo mit 16Mhz

Der 1. sendet noch und zeigt nicht richtige ccconf-Werte.
Der 2. sendet, schaltet aber nicht?
Ist Dein CC1101 ein 433 MHz-Version?

Beide mit 16 MHz.

Das erste: bei 433 : Das Attribut "slowrf" gilt für FS20 und nicht für IT ("langsame" Amplitudenmodulation und kein OOK).
Itrepetitions auf 12 zu setzen nützt auch nicht viel. Das Senden ist nur ewig lang weg.

Dein Problemlos wird ähnlich gelagert sein wie bei mir: die Module liegen u.U. frequenztechnisch neben dem
Frequenzfenster der Dosen.

Hierbei hilft: Schrittweise die itfrequeny um 5 kHz nach oben zu wandern, bis die Dosen reagieren. Bei mir musste ich die Itfrequeny z.B. auf 433.960 MHz einstellen, bis meine Pollin-IT-Dosen sicher reagieren. Vorausgesetzt alles andere ist Ok (Firmware + Anschaltung).
Die 08/15-433-Sendemodule sind wesentlich breitbandiger (sie müssen auch alle möglichen Empfänger erwischen ...)
als der CC1101! Deshalb muss dieser auch wesentlich genauer eingestellt werden.

Am WoE könnte ich das mal mit meinem Leonardo ausprobieren.
Wenn beim Leo mit dem EEPROM zurücksetzen wieder der BL aktiv ist, stimmt aber generell etwas mit dem Compile nicht.

Dein 433Empfänger liefert wirklich ein IT Muster und kein Spam? Bei einer falschen CC1101 Einstellung (z.B. GD0 +2 falsch)
sendet der CC1101 ggf. auch ... aber nur ein "blirp" ...

Es geht auch mittels GPIO ohne CUL mit C-Programm und 433-Sender:

Code Auswählen Erweitern


#######################################################################
# siehe: matthias-biedert.de/2014/08/25
define Radio1 dummy
attr Radio1 room Arbeitszimmer
attr Radio1 setList on off
define off_Radio_1 notify Radio1:off {system("sudo /opt/fhem/send 11111 1 0&");;}
define on_Radio_1 notify Radio1:on {system('sudo /opt/fhem/send 11111 1 1&');;}
#-------------------------------------------------------------------------------


Hier als Beispiel meine IT Einstellungen (beachte die versch. Frequenzen für unterschiedliche Steckdosentypen!):

Code Auswählen Erweitern


##################################################################################
#define <name> IT <housecode> <on-code> <off-code> [<dimup-code>] [<dimdown-code>]
#Define IT_000000FFFFF: wrong IT-Code format: specify a 10 digits 0/1/f statefile:
#------------------------------------
#..................1234567890.on.off
define POLLIN_A IT 000000FFFF 0F F0
attr POLLIN_A IODev NANOCUL
attr POLLIN_A ITfrequency 433.960
attr POLLIN_A model itswitch
attr POLLIN_A room POLLIN,IT
#------------------------------------
#..................1234567890.on.off
define Zimmer_A IT 000000FFFF 0F F0
attr Zimmer_A IODev NANOCUL
attr Zimmer_A ITfrequency 433.9284
attr Zimmer_A ITrepetition 3
attr Zimmer_A model itswitch
attr Zimmer_A room IT
#------------------------------------

Code Auswählen Erweitern

IT-Infos:
http://avr.börke.de/Funksteckdosen.htm

[naicheben]

Was der dann wirklich sendet kann ich gar nicht sagen. Vielleicht ist es tatsächlich Spam. Ich habe jetzt mal ein altes Scope ausgegraben. Kann nur 1MHz, aber solange ich nicht die HF messen muss reicht es ja.
Den CC1101 habe ich mal nur mit Strom versorgt (3,3V über LT1086-CT-3.3) und da bekomme ich 3,7µS breite Pulse.

Zwischen dem Leonardo und dem eHaJo besteht quasi kein Unterschied. Beide senden, aber die Dosen schalten nicht.
Ich glaube ja auch eher, dass es Konfigurationsfehler sind. Ich weiß nur nicht ob in FHEM oder in der CUL-Software.
Beim eHaJo würde ich ungern auf den Bootloader verzichten. Der Leonardo hat ja einen festen ISP, da fällt es mir leichter den zum neu flashen zu verwenden; dummerweise steckt da der CC1101 drauf 

Ich versuche mal den Tipp mit der itfreqency, sobald ich mir sicher bin, dass ich den richtigen Fersteuerungscode habe

EDIT: ich habe nur einen CC1101, muss also immer umbauen. Dafür habe ich einen Noname Empfänger, an dem ich eine LED/Logoktester am Ausgang habe.
EDIT 2: es sind wohl eher 3,7µS, bei Belastung ist die Spannung aber recht gering

[juergs]

Ah, ok.

Ich betreibe einen 433 + 868 mit ehajo Modul. Aber wie gesagt: mit umgerüsteten 8 MHz Quartz.
Der sitzt mechanisch sehr fest und das Auslöten desselbigen ist sehr schwierig,
weil die Leiterbahnen unter dem Quartz zu lang sind.
Dafür habe ich mir den Ärger mit dem Prescaler gespart... und die Standard-CULV3-FW verwendet.
Du könntest auch mal die a-CULFW-Version versuchen? Dort ist das mit dem 433-Pin in der SW gelöst.

Wenn Du Glück hast, geht es schon mit der Frequenzvariation.
Vielleicht hilft meine Aufzeichnung etwas ...

[naicheben]

Ich habe jetzt mal die a-culfw gezogen und CUL-Arduino_433 auf dem eHajo installiert, die ist für 16MHz gedacht. Nun habe ich noch mal die Verkabelung ganz von vorn angefangen und siehe da! C99 liefert Werte! 433MHz kann ich einstellen und bekomme sie mit get ccconf auch wieder angezeigt. Und das Beste: die Dosen schalten.

Vielen Dank für die vielen Tipps. Den Logic-Analyzer habe ich mal geflasht und konnte schon mal schön die Signale vergleichen. Auf meinem Uralt Hameg 312 konnte man da keinen Unterschied erkennen, weil das nicht richtig einrastet.... Dabei ist mir dann aufgefallen, das meine Arduino IDE total veraltet ist. Als ich den Analyzer mit 1.6 compiliert und geflasht habe ging der dann endlich 

Dann gehts jetzt weiter mit der Konfiguration von FHEM. Mal schauen, wie und ob ich die Fernbedienung und mein Anemometer eingebunden bekomme.
Ach, ist das schön wenn auch mal was funktioniert 
Vielen vielen Dank noch mal juergs!

[juergs]

 
Hi, freut mich.
Habe gerade den Leonardo umgebaut und auch versucht zu flashen.

Dabei gibt es natürlich massig Probleme Hürden:
1.) alle Geräte-Protokolle sind in der board.h eingeschalten, so dass das Ergebnis > 7000h ist !
2.) Da der DFU Bootloader ab 7000h anfängt .... gibt es da Ärger !
3.) Abspecken der Protokolle und Obj-File hat nur noch 25K, Flashen geht!
4.) FHEM mit Leo ohne CC1101-Modul betrieben liefert ccconf:

Code Auswählen Erweitern

ccconf => freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:4dB
Was zu beweisen war. -> CC1101 wird nicht angesprochen.
Morgen baue ich mal ein Modul dran, dann sieht man mehr.

Hier ist

Code Auswählen Erweitern

int
main(void)
{
  wdt_enable(WDTO_2S);
#if defined(CUL_ARDUINO)
  clock_prescale_set(clock_div_2); // for 16MHz
#endif

und F_CPU ist im makefile auf 16000000 gesetzt.

Die Leo-Fuses habe ich auf :
LF = 0xFF HF=0xD8 EF=C3 (HWB enable, war 0xCB) und LB=0xFF
gesetzt.

Diese Variante passt für die 16MHz und LEO!
https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUL-Arduino

Code Auswählen Erweitern

V 1.20.03 a-culfw Build: private build (unknown) CUL-ARDUINO868 (F-Band: 868MHz)

Hier noch ein HowTo zum Flaschen Flashen des 32U4:
http://dougspcbdesigns.pbworks.com/w/page/59725474/ATMega32U4...
und hier:
http://www.stanleylio.com/home/usblufa

[naicheben]

Die gleiche Firmware habe ich auch genommen. CUL-Arduino. Musste nichts ändern. HWBE habe ich gelassen, finde ich ganz gut auf dem eHaJo, Jumper setzen - Reset auf GND und dfu-bootloader meldet sich. Beim Leo habe ich den Pin ja schon abgelötet, werde den aber wohl auch auf Taster setzen, wie beim CUL, auch wenn ich den für FHEM nicht einsetzen werde (dafür war der irgendwie auch zu teuer). Beim eHaJo möchte ich ungern auf den Bootloader verzichten. Ist etwas nervig, wenn man den CC1101 abbauen muss um an die ISP-Schnittstelle ran zu kommen.

Was mich wurmt: ich kann von meiner Brennenstuhl FB keine Codes emfangen. Einmal habe ich kurz  was gehabt, konnte es aber nicht reproduzieren. Autocreate hat dann ein FS20 angelegt. Sowas habe ich gar nicht. Muss vom Nachbarn kommen (Garagentor vielleicht?). Also Empfang geht rudimentär.

Ich flashe mit dfu-programmer und avrdude, mit avrdude brenne ich auch die Fuses um (Leo L:0xff; H: 0xd8; Ext: 0xcb; bei abgelötetem HWBE), ohne gleich das ganze hex zu übertragen. Blöd ist nur, dass man wissen muss was man tut. Wenn man aus Versehen mal auf ext. Oszillator gestellt hat  Aber da habe ich inzwischen Übung drin  Axo: alles unter Linux auf Consle. Windows versuche ich zu meiden, hab ich nur für Steuern und Half Life 2

[juergs]

 
Erkenntnis ist der Weg zu Perfektion ...

Ohne Werbung machen zu wollen, aber den ehajo gibts mittlerweile für 9€ + Porto.
Also fast ein China-Schnäppchen.

Hier habe ich auch noch was gefunden, nicht ganz irrelevant:

Code Auswählen Erweitern

#if !defined(clock_prescale_set) && __AVR_LIBC_VERSION__  < 10701UL
#  warning "avr/power.h needs patching for prescaler functions to work."
#  warning "for the m32u4 add __AVR_ATmega32U4__ for cpu types on prescale block"
#  warning "for the m32u2 add __AVR_ATmega32U2__ for cpu types on prescale block"
#endif

Der CC1101-Pin CSN liegt bei a-culfw auf PB0 (kein Stiftleitsten-Pin). Besser wäre hier als "SS"-Port: PB4 -> D8 oder PC7 mit D13.
Das wäre zu klären, ob die SS-Funktion ausschließlich auf PB0 zwingend für SPI erforderlich ist
oder (da ja nur "normale" CS-Funktionalität) auch umgesetzt werden könnte. (Ausprobieren...)

Das Empfangen der IT-Fernbedienung geht bei mir (schau Dir mal den SDR#-Tip im Wiki an, ansonsten: im Frequenzbereich suchen!).

Wenn man autocreate setzt, empfängt man auch die Nachbarn!
Ganz "schlimm" ist es, wenn man im Hochaus wohnt und jeder hat sein Eigentum mit
z.B. FHTTK abgesichert! Ob das so die Zukunft sein wird? Intertechno ist da gar nicht gut ...

FileLog_CUL_FHTTK_382f6d
FileLog_CUL_FHTTK_766870   _FHTTK_766870-2016.log
FileLog_CUL_FHTTK_78ccd3   _FHTTK_78ccd3-2016.log
FileLog_CUL_FHTTK_8ffe0a   _FHTTK_8ffe0a-2016.log
FileLog_CUL_FHTTK_b6de6d   _FHTTK_b6de6d-2016.log
FileLog_CUL_FHTTK_da4ad7   _FHTTK_da4ad7-2016.log
FileLog_CUL_FHTTK_f21ec4   _FHTTK_f21ec4-2016.log
FileLog_CUL_FHTTK_f7f982   _FHTTK_f7f982-2016.log
FileLog_CUL_FHTTK_fa9612   _FHTTK_fa9612-2016.log
FileLog_CUL_TX_11      _TX_11-2016.log
FileLog_CUL_TX_111      _TX_111-2016.log
FileLog_CUL_TX_127      _TX_127-2016.log
FileLog_CUL_TX_23      _TX_23-2016.log
FileLog_CUL_TX_24      _TX_24-2016.log
FileLog_CUL_TX_32      _TX_32-2016.log
FileLog_CUL_TX_42      _TX_42-2016.log
FileLog_CUL_TX_58      _TX_58-2016.log
FileLog_CUL_TX_67      _TX_67-2016.log
FileLog_CUL_TX_68      _TX_68-2016.log
FileLog_CUL_TX_70      _TX_70-2016.log
FileLog_CUL_TX_88      _TX_88-2016.log
FileLog_CUL_TX_97      _TX_97-2016.log
FileLog_CUL_TX_99      _TX_99-2016.log
FileLog_CUL_WS_1      _WS_1-2016.log
FileLog_CUL_WS_2      _WS_2-2016.log
FileLog_CUL_WS_3      _WS_3-2016.log
FileLog_CUL_WS_4      _WS_4-2016.log
FileLog_CUL_WS_5      _WS_5-2016.log
FileLog_CUL_WS_7      _WS_7-2016.log
FileLog_CUL_WS_8      _WS_8-2016.log
FileLog_FHT_1156      _1156-2016.log
FileLog_FHT_1aeb      _1aeb-2016.log
FileLog_FHT_1ea1      _1ea1-2016.log
FileLog_FHT_4019      _4019-2016.log
FileLog_FHT_9470      _9470-2016.log
FileLog_FHT_9550      _9550-2016.log
FileLog_FS20_002201      20_002201-2016.log
FileLog_FS20_2116a4      20_2116a4-2016.log
FileLog_FS20_2aa444      20_2aa444-2016.log
FileLog_FS20_34dfc5      20_34dfc5-2016.log
FileLog_FS20_38ba00      20_38ba00-2016.log
FileLog_FS20_38ba01      20_38ba01-2016.log
FileLog_FS20_38ba02      20_38ba02-2016.log
FileLog_FS20_38ba03      20_38ba03-2016.log
FileLog_FS20_39b797      20_39b797-2016.log
FileLog_FS20_4b929f      20_4b929f-2016.log
FileLog_FS20_5288d4      20_5288d4-2016.log
FileLog_FS20_613a1b      20_613a1b-2016.log
FileLog_FS20_680ad4      20_680ad4-2016.log
FileLog_FS20_710660      20_710660-2016.log
FileLog_FS20_7fe570      20_7fe570-2016.log
FileLog_FS20_85611e      20_85611e-2016.log
FileLog_FS20_86aa9e      20_86aa9e-2016.log
FileLog_FS20_8b8fac      20_8b8fac-2016.log
FileLog_FS20_93e426      20_93e426-2016.log
FileLog_FS20_989925      20_989925-2016.log
FileLog_FS20_b84ce3      20_b84ce3-2016.log
FileLog_FS20_b88245      20_b88245-2016.log
FileLog_FS20_cb8280      20_cb8280-2016.log
FileLog_FS20_ce548a      20_ce548a-2016.log
FileLog_FS20_d88970      20_d88970-2016.log
FileLog_FS20_f8f4de      20_f8f4de-2016.log
FileLog_FS20_fdd69d      20_fdd69d-2016.log
FileLog_HMS100TF_0000   HMS100TF_0000-2016.log
FileLog_IT_00000FFFF0   _00000FFFF0-2016.log
FileLog_IT_000FFFF0FF   _000FFFF0FF-2016.log
FileLog_IT_000FFFFF0F   _000FFFFF0F-2016.log
FileLog_IT_00FF00000F   _00FF00000F-2016.log
FileLog_IT_0F0F00FFFF   _0F0F00FFFF-2016.log
FileLog_IT_0F0F0F0FFF   _0F0F0F0FFF-2016.log
FileLog_IT_0F0F0FFFFF   _0F0F0FFFFF-2016.log
FileLog_IT_0F0FFF000F   _0F0FFF000F-2016.log
FileLog_IT_0F0FFF0F0F   _0F0FFF0F0F-2016.log
FileLog_IT_0F0FFFF00F   _0F0FFFF00F-2016.log
FileLog_IT_0F0FFFFF0F   _0F0FFFFF0F-2016.log
FileLog_IT_0FF000000F   _0FF000000F-2016.log
FileLog_IT_0FFFF0FFFF   _0FFFF0FFFF-2016.log
FileLog_IT_0FFFFF0FFF   _0FFFFF0FFF-2016.log
FileLog_IT_0FFFFFF0FF   _0FFFFFF0FF-2016.log
FileLog_IT_0FFFFFFF0F   _0FFFFFFF0F-2016.log
FileLog_IT_0FFFFFFFFF   _0FFFFFFFFF-2016.log
FileLog_IT_1FFF1FF000   _1FFF1FF000-2016.log
FileLog_IT_F0FFF0FFFF   _F0FFF0FFFF-2016.log
FileLog_IT_F0FFFF0FFF   _F0FFFF0FFF-2016.log
FileLog_IT_F0FFFFFF0F   _F0FFFFFF0F-2016.log
FileLog_IT_F0FFFFFFFF   _F0FFFFFFFF-2016.log
FileLog_IT_F1FF1FF000   _F1FF1FF000-2016.log

[juergs]

Fazit:
Aufwand den Leonardo in ein CUL zu verwandeln lohnt aus meheren Gründen nicht:
1.) die a-culfw Compilierung mit den Standard-Einstellungen in der board.h:

Code Auswählen Erweitern

#define SPI_SS PB0
#define SPI_MISO PB3
#define SPI_MOSI PB2
#define SPI_SCLK PB1
Also:

Code Auswählen Erweitern


LED  = PD7 - D6
CSN = PB0 - (RX-LED)
GD0 = PD3 - TX - D1
GD2 = PD2 - RX - D0
SO   = PB3 - SPI.1
SCK = PB1 - SPI.3
SI    = PB2 - SPI.4

extra zu verlegen:
HWB - CPU Pin 33
PB0  - CPU Pin 8


ausser der Led, wegen der Sichtbarkeit auf dem Protoboard auf D6 verlegt:

Code Auswählen Erweitern

#  define LED_PIN               7        //PD7=D6   RX-Led = 5
Der Compile liefert bei den Standard-mäßig eingestellten Protokollen ein Output von > 07000h , geht also in den Bootloader-Bereich rein ->
CUL startet zwar lässt sich aber nicht mehr über FIPS und USB flashen sondern nur noch über einen ISP-Programmer.
Was an den Protokollen herauszunehmen ist .... scheitert erst mal an fehlenden Kommentaren ...

2.) SPI - SS Funktion liegt auf PB0, welche nicht an der Buchsenleiste verfügbar ist. Gefrickel... der Pullup mit der RX-LED ist "nur" 1K (statts 10K).
um das herauszuführen -> Gefrickel. Im Bild habe ich versucht diese Konstellation abzutrennen, aber wegen Gefrickel dabei belassen ...
Pin anheben? Geht nicht so gut wie bei HWB. -> so belassen ...

3.) HWB geht nur mit PIN an der CPU hochheben und mit Gefrickel an Button führen.

4.) Die a-culfw nimmt in der "CUL-Arduino"-Version das Gefrickel mit dem Prescaler ab und patcht auch die power.h.

5.) Musste bei meinem CC1101-Modul um ca. 40KHz nach oben konfigurieren um den negativen Offset bei 868.300
zur Fernbedienung wieder auszugleichen. (Was häufig vorkommt! Mittenfrequenz = Geometrisches Mittel!)
Mein verwendetes Modul hat wohl nicht so viel Leistung wie die Fernbedienung! Evtl. kann man die Antenne doch noch besser abstimmen.

6.) Die SPI-Ports sind belegt, zum Flashen muss man wechseln ...

7.) Der DFU-Bootloader löscht den Bereich von 0h..6fffh beim Flashen mit, deshalb wenn defekt, immer BL zuerst, dann CUL flashen.


Wer nur ein Leonardo zu Verfügung hat .... es geht nicht sofort auf Anhieb! (Siehe dieser Thread!)

[naicheben]

Danke für die Zusammenfassung. Der Leonardo macht es einem wirklich nicht leicht. Ich bin froh, dass Du mir den Tip mit dem eHaJo gegeben hast. Wobei jetzt ein AVR mit mehr Platz auch nicht verkehrt wäre. Man ist ja auch irgendwie nie zufrieden 

Meintest Du statt power.h board.h ?

Deinen Tip mit SDR# habe ich im Wiki nicht gefunden. Mag an mir liegen, darum werde ich mich nächste Woche mal kümmern.
Erst mal werde ich mir auf Lochraster den eHaJo und einen Wannenstecker zusammenbraten und die Widerstände fest anlöten. Mit dem Breadboard ist das immer etwas empfindlich.

[juergs]

Nur in board.h. Falls man die original CUL FW zugrunde nimmt, dann möglicherweise auch die power.h.

SDR#:
http://www.fhemwiki.de/wiki/Funksignalanalyse_mit_DVB-T_Stick

nanoCUL:
http://www.fhemwiki.de/wiki/Selbstbau_CUL
CUL:
http://www.fhemwiki.de/wiki/CUL

Noch ein Tip zum Gehäuse:
Habe etwas milchig durchsichtiges PVC-Gehäuse genommen, da passt der Controller mit CC1101-Modul mit SMA
hervorragend rein. Beim Durchbruch für den USB-Stecker (als Passung!) kann man sich aber verkünsteln ...
Mit Crimp + Wannenstecker kann man die Länge gut ausgleichen.
Hier das 433MHz-Modul:

[PeMue]

Hallo juergs,

kannstd Du mal einen Link für Dein Gehäuse posten?

Danke + Gruß

Peter

[juergs]

Huch, halloo PeMue,

Gedankenübertragung, war gerade auch am Suchen...!
Habe sie vom lokalen Elektronikhändler.

Aber hier gibt es sie auch:
http://www.voelkner.de/products/39872/Gehaeuse-Kunststoff-124x72x30mm-Klar-Transparent.html

Sonst benutze ich eher diese Varianten, weil man die Frontseiten separat bearbeiten kann (z.B. KEMO GS111) :
https://www.luedeke-elektronic.de/de/Gehaeuse/Standardgehaeuse/?XTCsid=b3bc22e6f05aff54409826ea7392f9fd

Hier gibts ähnliche:
http://www.hammondmfg.com/scpg.htm

Grüße
Jürgen

[PeMue]

Hier gibts ähnliche:
http://www.hammondmfg.com/scpg.htm

Ok, jetzt kann ich Deine Mail zum Thema zuordnen. Ich habe - wie schon geschrieben - die Gehäuse von Hammond beim nanoCUL, beim LaCrosse Gateway und beim Optolink Adapter schon im Einsatz ...

Gruß Peter