ricevitore usb per telecomando (ex:infrahid)

[alez]

Che coppia di PID:VID avete testato?

Stavo pensando di comprare una coppia (10 euri) da OBDEV da regalare alla community VDR ITALIA...

[ragno]

Quelli soliti nel source atmega.
L'idea non e' male, sono tuo follower

[von fritz]

Hello

l' altro "giorno" ho aggiornato la mia Arch (VDRBOX) e son passato da un kernel 3.7.9 ad un 3.8.3 e all riavvio
il ricevitore non funzionava piu' il device /dev/hidraw non viene creato con il kernel 3.8.x dunque ATTENZIONE! se aggiornate.
io ho risolto facendo un downgrade riportando la mia arch al 3.7.9.
il problema e che con il kernel 3.8 la USB-ID del ricevitore IR viene usata dal nuovo device Masterkit M901 USB-Radio.
2 soluzioni a parte il downgrade :
1. si patcha il kernel 3.8 togliendo il supporto Masterkit M901 USB-Radio.
2. si riprogramma il ricevitore IR con un altra USB-ID "libera".

bye

Ci sono novita'?
Nel weekend ho scoperto che il kernel di yavdr05 non vede piu' il dispositivo. Dopo innumerevoli bestemmie sono tornato alla 0.4
Francamente sono scocciato da questa piega e stufo di perdere tempo appresso ad un potpuorri dov avere qualcosa funzionante e' praticamente un terno al lotto.

nel 3.8.7 (attuale stable) non e stata ancora inserita "l'ultima patch" che rimette a posto il tutto.
nel 3.9.X, non ancora rilasciato,

Codice: Seleziona tutto

--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -158,6 +158,8 @@
#define USB_VENDOR_ID_ATMEL 0x03eb
#define USB_DEVICE_ID_ATMEL_MULTITOUCH 0x211c
#define USB_DEVICE_ID_ATMEL_MXT_DIGITIZER 0x2118
+#define USB_VENDOR_ID_ATMEL_V_USB 0x16c0
+#define USB_DEVICE_ID_ATMEL_V_USB 0x05df 

basta non usare un kernel 3.8.X, il ricevitore funziona bene fino al 3.7.X e funzionera' di nuovo con il 3.9.X senza fare modifiche.

[alez]

In che senso patch? Hanno scazzato i developer del kernel ed hanno rimediato nelle successive?

[ragno]

L'hanno fatta proprio fuori tazza...
Mi domando come sia sfuggita una cosa del genere...ormai la corsa e' sui dispositivi mobili che fanno "cassa"...
Per fortuna Vonfritz ci aveva allertato, altrimenti avrei buttato tutto dalla finestra.

[von fritz]

L'hanno fatta proprio fuori tazza...
..........

molto fuori se vi dico che la patch iniziale, quella fuori tazza :
......patch also was pushed to stable trees like 3.5, 3.8, 3.2
e poi la patch finale, quella che rimette a posto il tutto :
....Absolutely. Will add your Ack and push it to Linus for 3.9 still
dunque il 3.2, 3.5, 3.8 rimangono ....
per chi interessa il thread :
http://www.spinics.net/lists/linux-media/msg61830.html

bye

[ragno]

grazie

[alez]

Altra USBASP betemcu flashata ma con infrahid non ne vuol sapere di andare... non riesco proprio a capire cosa ha che non va... tutti gli altri progetti basati si V-USB flashati sulla USBASP vanno.



EDIT: FUNZIONAAAAAA!!!!

La mia testaccia dura anche questa volta l'ha vinta


Prima di tutto sono riuscito a trovare lo schema di un "other" UBSASP:

https://www.dropbox.com/s/45li6ar0xgjd8 ... Mhz_10.pdf

che mi ha permesso di notare che il pin PD2 (INT0) sulle USBASP è collegato a PB1 tramite una pista, la cosa è visibile anche nello schema LCSOFT, ma come spesso succede "ero cecato" :

https://www.dropbox.com/s/7yq16r5o8iraa ... P2_SCH.pdf



Morale della favola, in main.c ho provato a commentare la riga che attiva le resistenze interne di PULL-UP interne al atMega8 su PORTD:

Codice: Seleziona tutto

     //PORTD = 0xFF;   													/* activate all pull-ups */

Probabilmente, la corrente che esce attraverso le resitenze interne da 20k dell'Atmel va nella porta USB su D+ e fa casino...



Ora che come periferica USB viene vista, posso procedere a fare il circuito per collegare il ricevitore IR a quel che una volta era una USBASP




P.S.1 : memore dell'esperienza con la USB ASP precedente sputtanata causa falsi contatti (vedi qui viewtopic.php?p=19235#p19235 ) ho fatto ponticello migliore per J2, usando 2 pin di un header maschio infilati a mano (il passo è troppo ravvicinato, non è lo standard 2.54 mm) e li ho saldato al PCB, poi ho piegato i pin per adattarli al passo standard 2.54 mm in modo da riuscirci ad infilare un ponticello:








P.S.2 : con questa modifica, funge anche sulla versione LCSOFT delle USBASP

[ragno]

Perfetto, non ho fatto alcuna modifica, ma ho provato su una betemcu miniprog. Immagino che la lcsoft sia la solita dongle...che differenze ci sono?

[alez]

Le LCSOFT sono le prime due che ho avuto, più complete dotate di jumper per selezione 5 / 3,3 V e piazzole su cui si può saldare un ponticello standard 2,54 mm per RESET e velocità di programmazione lenta

viewtopic.php?p=17886#p17886

Trovandole ancora sono meglio le LCSOFT come smanettamento offerto, ma ormai vedo che quasi tutti vendono le betemcu, probabilmente costa meno produrle.



Francamente sono ancora basito dal fatto che a te e agli altri del forum easy-vdr.de funzionino senza quel commento...

[ragno]

Francamente sono ancora basito dal fatto che a te e agli altri del forum easy-vdr.de funzionino senza quel commento...

Almeno qualche volta una cosa che funziona al primo colpo mi capita...

Mi pare che czb6721960 abbia ancora le LCSOFT allo stesso prezzo delle betemcu.

[alez]

Per applicazioni tipo joystick o altro che richiedono molti pin sono migliori, hanno qualche jumper in più.

Se usate come USBASP inoltre sono più standard in quanto hanno anche il jumper (da montare, c'è solo la piazola) per funzionare a bassa velocità.




P.s.: se usate come USBASP vanno (quasi) tutte (sia lcsoft che betemcu) riflashate se si vuole avere il supporto all'ultima versione di avrdude, in quanto se non montano l'ultimo firmware avrdude restituisce un warning relativo al settaggio del clock durante la programmazione

[alez]

Hai detto benissimo "vista la sfiga nel trasformare il piombo in oro": ho montato l'hardware necessario per realizzare il ricevitore con la USBASP.

Ho perso più di due ore di tempo e imprecazioni varie prima di riuscire a capire dopo diversi controlli incrociati che non funzionava perché il cavo flat di collegamento tra USBASP era difettoso:



Il bastardo ora è andato a finire in discarica

Ora un po di olio di gomito, preparo la documentazione e la metto sul Wiki, attende da troppo tempo

[alez]

Altro problema

Ho provato a scaricare da git l'ultima versione di irmplird ma non parte, provato sia su

Ubuntu 10.04 (portatile) con kernel 2.6.32-24-generic

che su

Ubuntu 12.04 minimal (VDR BOX ION) con kernel 3.2.0-36-generic-pae

ma non parte e torna subito al prompt quando lancio

./irmplircd -f /dev/hidraw0



Anche qui, controllo incrociato, ho provato una vecchia versione che avevo archiviato insieme a USB-IR-RR ed ha funzionato su entrambe le macchine

Qualcuno può testare la nuova versione GIT?



P.s.: non è che il problema con la SifBox sia riconducibile a irmplircd?

[ragno]

Grazie: stranamente non gira sotto DS (quindi il codice oggetto non e' compatibile col suo ARM).
Hai compilato il codice del git o quello dell'archivio originale?

A me sembra che quello del git vada meglio...



p.s. c'e' da variare il link del download di irmplircd sul wiki.