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
Schau mal hier: http://dokuwiki.ehajo.de/artikel:atmega_u-howto:go2bootloader
(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 (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 (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 (https://code.google.com/archive/p/micropendous/wikis/ProgramAndTestWindows.wiki)
http://www.busware.de/tiki-index.php?page=DFU+Bootloader (http://www.busware.de/tiki-index.php?page=DFU+Bootloader)
http://dokuwiki.ehajo.de/bausaetze:display-adapter (http://dokuwiki.ehajo.de/bausaetze:display-adapter)
Mit diesem Board funktioniert es: http://www.ehajo.de/boards/atmega32u4-breakout-board.html (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. :'(
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)
Hi, klar googlen kann jeder ... 8)
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?
F_CPU = 8000000
FORMAT = ihex
OBJDIR = .
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. 8)
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
;D ;D ;D ;D
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:
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?
Schau mal hier in den Thread:
und ff.
https://forum.fhem.de/index.php/topic,24651.msg419350.html#msg419350 (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 (https://forum.fhem.de/index.php/topic,45833.0.html)
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.
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....
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.
#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:
#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
Sorry, hatte mich nur auf LED konzentriert und RX mit L getauscht:
Zitataber 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. 8)
So ginge es z.B. auch: // 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:
#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
Jupp, so habe ich das verkabelt.
ccconf sagt:
myCul ccconf => freq:6182.103MHz bWidth:270KHz rAmpl:33dB sens:8dB
das finde ich schon etwas komisch.
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. ;D
Danke für die Unterstützung!!!
Jetzt suche ich mir mal schöne Steckdosen aus.
Ob die Readings auch die richtigen Inhalte wiedergeben?
Blinkt die Led "L" im Sekundentakt?
Probier mal mit 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 (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 (http://physudo.blogspot.de/2013/08/arduino-als-logic-analyzer.html)
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:
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)
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
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:
#######################################################################
# 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!):
##################################################################################
#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
#------------------------------------
IT-Infos:
http://avr.börke.de/Funksteckdosen.htm (http://avr.xn--brke-5qa.de/Funksteckdosen.htm)
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
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 ...
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 ;D
Vielen vielen Dank noch mal 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:
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
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 (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUL-Arduin)
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... (http://dougspcbdesigns.pbworks.com/w/page/59725474/ATMega32U4...)
und hier:
http://www.stanleylio.com/home/usblufa (http://www.stanleylio.com/home/usblufa)
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 ;D Axo: alles unter Linux auf Consle. Windows versuche ich zu meiden, hab ich nur für Steuern und Half Life 2
:)
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:
#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 ...
ZitatFileLog_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
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:
#define SPI_SS PB0
#define SPI_MISO PB3
#define SPI_MOSI PB2
#define SPI_SCLK PB1
Also:
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:
# 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!)
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 ;D
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.
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 (http://www.fhemwiki.de/wiki/Funksignalanalyse_mit_DVB-T_Stick)
nanoCUL:
http://www.fhemwiki.de/wiki/Selbstbau_CUL (http://www.fhemwiki.de/wiki/Selbstbau_CUL)
CUL:
http://www.fhemwiki.de/wiki/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:
Hallo juergs,
kannstd Du mal einen Link für Dein Gehäuse posten?
Danke + Gruß
Peter
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 (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 (https://www.luedeke-elektronic.de/de/Gehaeuse/Standardgehaeuse/?XTCsid=b3bc22e6f05aff54409826ea7392f9fd)
Hier gibts ähnliche:
http://www.hammondmfg.com/scpg.htm
Grüße
Jürgen
Zitat von: juergs am 17 April 2016, 14:18:26
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