Takt von China-Platine mit AT90USB162 herausfinden/ändern?

[Diabetos (Gast)]

Hallo!

Ich bin kompletter Neuling, und habe bisher Nichts mit der 
Programmierung von Microcontrollern zu schaffen gehabt. Nun habe ich 
einen "ps3ukey" hier liegen, der eigentlich mal angeschafft wurde, um 
ein XUM1541 zu werden, was aber nicht ging, nachdem ich feststellte, 
dass auf diesem Board die meisten Pins des ICs nicht verlötet waren.
Die XUM1541 habe ich dann mit einem anderen Board gebaut, der ps3ukey 
liegt nun hier vor mir, und ich möchte daraus gerne ein Gerätchen bauen, 
welches als Signal-Beeper für ein beliebiges Embedded-Gerät dienen soll.

Das heißt ich möchte einen Piezo-Piepser darauf stecken, und den Stick 
dann als /dev/ttyUSB0 sehen, und später einfach z.B. mit einem String 
wie "beep <F> <L>" (Frequenz, Länge), den ich an /dev/ttyUSB0 sende zum 
fiepen bringen, um damit dann z.B. die erfolgreiche Abarbeitung von 
Skripten auf einem Headless-Embedded Gerät zu bestätigen. Die 
USB-Verbindung möchte ich z.B. mit V-USB lösen.

Ich bin ja schon ganz stolz, weil ich es tatsächlich geschafft habe, ein 
kleines Testprogrämmchen (rote und blaue LEDs blinken abwechselnd) per 
avr-gcc zu compilen und per dfu-programmer darauf zu flashen:

// blaue LED ist PB2!
// rote  LED ist PD3!
#define F_CPU 1000000
#include <avr/io.h>
#include <util/delay.h>
int main (void) {
   DDRB |= (1 << PB2);
   DDRD |= (1 << PD3);
   PORTB ^= ( 1 << PB2 );
   while(1) {
     /* mainloop */
   PORTB ^= ( 1 << PB2 );
   PORTD ^= ( 1 << PD3 );
  _delay_ms(10000);
   }
   return 0;
}


Jetzt kommen wir aber zum eigentlichen Problem:
Das Timing der LEDs stimmte nicht. Auf dem Board befindet sich ein Quarz 
mit der Aufschrift "K8.000", also 8MHz vermute ich?. Aber damit die Zeit 
zwischen den Flashes der LEDs mit dem bei _delay_ms(n) angegebenen 
Intervall übereinstimmt, musste ich
F_CPU auf 1000000 stellen.
Heiß das, dass der uC wirklich nur mit 1MHz läuft?
Oder kann das einfach eine Konfigurationssache sein?
Kann ich die echte Taktfrequenz über diese Clocksource-Dinge irgendwie 
beeinflussen, ohne großen Umbauten an der Hardware?
Da ich wie oben angegeben ja gerne später über USB-Kommandos empfangen 
möchte, bräuchte ich für die Verwendung von V-USB ja wie 
hier(https://www.heise.de/select/make/2017/1/1488551128750727) bei heise 
beschrieben eine der Freuqnzen von 2, 12,8, 15, 16, 16,5, 18 und 20 MHz.

[Rufus Τ. F. (rufus)]

Diabetos schrieb:
> Heiß das, dass der uC wirklich nur mit 1MHz läuft?

Das könnte bedeuten, daß die sogenannten "Fuses" nicht so gesetzt sind, 
daß der Quarz überhaupt angesteuert wird. Es könnte aber auch die 
CKDIV8-Fuse gesetzt sein, die den Takt durch 8 teilt.

> Die USB-Verbindung möchte ich z.B. mit V-USB lösen.

Das ist beim at90usb162 grober Unfug, das Ding kann USB in Hardware. Du 
solltest Dir statt V-USB besser LUFA ansehen.

[Dia B. (diabetos)]

Rufus Τ. F. schrieb:
> Diabetos schrieb:
>> Heiß das, dass der uC wirklich nur mit 1MHz läuft?
>
> Das könnte bedeuten, daß die sogenannten "Fuses" nicht so gesetzt sind,
> daß der Quarz überhaupt angesteuert wird. Es könnte aber auch die
> CKDIV8-Fuse gesetzt sein, die den Takt durch 8 teilt.
>
>> Die USB-Verbindung möchte ich z.B. mit V-USB lösen.
>
> Das ist beim at90usb162 grober Unfug, das Ding kann USB in Hardware. Du
> solltest Dir statt V-USB besser LUFA ansehen.

Danke schon mal. Ich hatte mich nach erstem Sondieren eher mit V-USB 
angefreundet, weil LUFA so überkomplex wirkte, und die Website etwas 
eigenartig ist... schon den Download konnte ich dort nicht finden (habe 
es inzwischen aber von Github).
Ich fürchte die Fuses kann ich mit dieser Verlötung des Chips gar nicht 
setzen(z.B MISO fehlt, der wäre ja auf 17), oder? Ich habe mir an Hand 
der Atmel-Dokumentation eine Grafik angefertig, wo zu sehen ist, welche 
Pins überhaupt zur Verfügung stehen. Ich habe die Grafik mal angehängt.

Also müsste ich wohl sowieso auf LUFA setzen..?

[Rufus Τ. F. (rufus)]

LUFA ist sogar in der Arduino-Umgebung integriert, wenn man z.B. einen 
Arduino Leonardo damit programmiert (der verwendet einen Atmega32u4, der 
ebenso einen echten USB-Device-Controller enthält).

Und LUFA ist V-USB gegenüber eindeutig im Vorteil, wenn man eine andere 
USB-Geräteklasse als HID umsetzen möchte; zwar gibt es eine 
CDC-Implementierung mit V-USB, die aber funktioniert nur mit sehr 
toleranten Betriebssystemen, da sie eine Verletzung der 
USB-Spezifikation darstellt.

Daß Du allerdings bei Deinem Controller die Fuses nicht setzen kannst, 
dürfte mehr als eklig sein.

Die Kontakte des QFN-Gehäuses sind auch mit feinen Nadeln nicht 
erreichbar?

Zeig doch bitte mal ein (scharfes, anständig ausgeleuchtetes) Bild von 
Deinem "ps3ukey".

[Dia B. (diabetos)]

Hallo!

Ich habe den Stick mal in der Totalen und im Detail fotografiert. 
(Besser konnte ich die Makroaufnahme nach ca 30 Versuchen nicht 
hinbekommen).
Die Lötflächen um das IC herum sind leider bei den meisten Pins nicht 
mit dem IC verlötet. Von der MISO-Seite aus, also Pin 17-24, ist gar nur 
ein Pin verlötet, nämlich der Reset (24, ganz rechts).

Die dünnste meiner Lötspitzen, mit der ich einigermaßen umgehen kann, 
ist etwa so breit, wie der gesamte IC dick ist.
Die 2x3 Pinleiste links ist unbeschaltet; die habe ich selbst mit Epoxyd 
angeklebt, weil ich mir daraus ursprünglich mit etwas Lackdraht einen 
ISP-Header machen wollte...
PS: Habe noch ein Detailbild angehängt, es wurde vorher wohl beim 
Transfer vom Smartphone durch die App komprimiert, jetzt ist es wohl 
minimal besser. Ich kann aber leider dennoch nicht sagen, ob unter den 
unverlöteten Füßen des ICs überhaupt Lötaugen auf dem Board sind.

[Jim M. (turboj)]

Diabetos schrieb:
> Oder kann das einfach eine Konfigurationssache sein?

Kapitel 6.8.1 Clock Prescale Register – CLKPR im Manual gelesen?

Dafür gibt es IIRC sogar ein Macro, was die 4 Takte beim Schreibzugriff 
einhält.

[Dia B. (diabetos)]

Jim M. schrieb:
> Diabetos schrieb:
>> Oder kann das einfach eine Konfigurationssache sein?
>
> Kapitel 6.8.1 Clock Prescale Register – CLKPR im Manual gelesen?
>
> Dafür gibt es IIRC sogar ein Macro, was die 4 Takte beim Schreibzugriff
> einhält.

Danke! Das hat funktioniert.
Habe das gefunden um die Clockbits zu resetten:

CLKPR = _BV(CLKPCE);
CLKPR = 0;

Und vor mein Progrämmchen gesetzt. Das Timing stimmt jetzt mit #define 
F_CPU 8000000

Hätte nicht gedacht, dass man die Werte die von den Fuses presettet 
werden auch von einem Userprogramm aus overriden kann. Das geht aber 
sicher nicht mit Allem, was die Fuses so setzen, sonst bräuchte ich ja 
kein ISP mehr?


Die nun anstehenden Fragen sind ja, ob LUFA überhaupt funktionieren 
kann, ohne Zugriff auf die Fuses, oder ob Rufus evtl. noch einen Trick 
auf Lager hat, wie ich das "MISO-Problem" mechanisch lösen könnte. Ich 
habe ja im Github Download schon gesehen, dass LUFA seine eigenen 
Bootloader mitbringt, aber weiß nicht wofür die eigentlich nötig sind. 
Normalerweise bietet so eine Library ja ein paar Includes, über die ich 
dann die gebotene Funktionalität bekommen, aber bei einem uC ist das 
wohl anders. Bisher dachte ich der Bootloader sei nur dafür da, ein 
Ansprechpartner zum Programmieren ohne ISP-Hardware zu sein...

[Rufus Τ. F. (rufus)]

LUFA ist zunächst nur eine Library, die Du zu Deinem Programm 
dazulinkst. Der Bootloader ist dafür da, über die USB-Schnittstelle 
Programme in das den Controller hineinzubekommen, den brauchst Du 
offensichtlich nicht, denn Du bekommst ja Programme übertragen.

Ich habe keine Ahnung, ob man, um LUFA nutzen zu können, irgendwelche 
speziellen Fuses o.ä. setzen muss.

Googelt man nach "LUFA at90usb162", findet man aber etliche Hinweise.

Also: Viel Erfolg!

[Dia B. (diabetos)]

OK, danke dir. Also ist es doch so, wie ich es bisher (von 
Desktopentwicklung) kannte. Die Bootloader scheinen nur ein "Bonus" zu 
sein, falls man auf seinem uC nocht keinen geeigneten drauf hat.
Dann versuche ich jetzt mal LUFA zu überschauen. Die für meinen Zweck 
interessanteste mitgelieferte Demos (DualVirtualSerial) ist laut txt 
leider nicht für den at90usb162 geeignet und liefert 
Kompilierungsfehler, wenn ich diesen uC als Target setze.

[Dia B. (diabetos)]

Ich wollte hier noch kurz anfügen, dass das Miniprojekt (und mein 
Erstling) soweit gelungen ist.
Ich habe in den mitgelieferten LUFA-Projekten nur den Source-Code von 
"USBToSerial" ein wenig geändert, einen 12mm-Piezo-Beeper an den selben 
Ausgang wie die blaue LED gelötetn, und es funktioniert. Unter Linux 
sind keine Treiber nötig, man muss nur eine Ausgabe auf das Devcie 
senden (z.B: echo > /dev/ttyACM0) und schon ertönt ein kleines Signal. 
Ich wollte noch eigentlich noch die übergebenen Daten parsen, um daraus 
Tonfolge, Laustärke und Dauern zu interpretieren, aber um mit 
"&USBtoUSART_Buffer" etwas anzufangen reichen meinhe C-Kenntnisse nicht 
aus. (Ich vermute es läuft darauf hinaus, die Länge das Buffers zu 
ermitteln, und den gesamten String im Buffer in ein Array zu lesen, aber 
das ist auch egal, es funktioniert ja auch so). Als Signalgeber für 
Embedded-Geräte, ohne Treiberabhängigkeit.

Falls sich jemand dafür interessiert, der noch weniger, oder ähnlich 
viel wie ich darüber weiß, habe ich den geänderten Code angehängt.