Hardware-wakeup die 4.

Wesie · 10. Mai 2004

Irgendwie hat das neue hex nicht so ganz geklappt:
beim Einschalten kein Blinken
beim setzen (manuell) kein blinken ....

entweder ist der Atmel nicht richtig angelaufen, oder irgendwo im Code verlaufen ....
Das hex war richtig drin, da nach dem schreiben ein Verify gemacht und vorher ich den AVR lösche ( PonyProg ). Ich bin dann wieder auf das hex mit den 3x blinken am Anfang zurück....

BTW: die Sicherung war i.O. Verstehe ich jetzt nicht, daß kein Ruhestrom angezeigt wurde, außer dass das Einschalten über einen kleinen "C" geht ?!??

steini · 10. Mai 2004

OK wesie,
ich muß die Tage nen paar Module programmieren. Werde das mal testen.
Gruß
steini

PS: Haste mal gegen das Gehäuse gemessen? Normalerweise hat so ein Multimeter bei A nur einen winzig kleinen Innenwiderstand.

steini · 11. Mai 2004

Hi,
hat mir natürlich keine Ruhe gelassen. Hab's getestet. Die *.hex hat's entweder beim Komprimieren oder beim Übertragen zerbröselt. Die bei mir auf dem Rechner läuft. Aber die runtergeladene nicht.
Hab ich jetzt nochmal angehängt. Bei mir geht's
Gruß
steini

PS: Hab die auch sicherheitshalber anders benannt

Wesie · 11. Mai 2004

Ich werde heute Abend noch einmal vermutlich einen Transistor besorgen müssen, da ich das Wakeup-Modul nach der Hex nicht mehr zum fliegen bekomme :
die Led blinkt 3* bei Stromzufuhr, aber es nimmt keine Zeiten mehr an . Manuell ( mit oder ohne Autostart von VDR ) sowie aus dem shutdownScript . Ich muss mal messen, ob der Transistor einen Schlag abbekommen, oder der Eingang des AVR's.
Werde mal schauen, ob ich auf die schnelle ein Prüfprog geschrieben bekomme, daß wenn Daten am Pin 15 anliegen die LED entsprechend an/aus geschalten wird.

steini · 11. Mai 2004

Hi wesie,
das *.hex kann am Controller nix schlimmes anrichten. Hab's ja gestern auch bei mir drauf gehabt. Der hat sich in so ne Art Resetschleife verlaufen. Das macht aber nix da die Ausgänge dabei alle hochohmig sind. Trotzdem blöd X(.
Beschädigen kann man die Controller übrigens nicht so leicht. Was die nicht vertragen ist verpolte Betriebsspannung (klar) und ESD. Ich hab mir vor 2 Monaten einen zerschossen als ich mal kurz mein Notebook auf den Fernseher (der natürlich lief ) gestellt habe und den Controller programmieren wollte. Ich hab beim Anschließen des Programmers den kleinen "Funken" gesehen.... und das war's dann. Seither sorge ich vorher immer für nen Potentialausgleich auf GND.
Der Neue '.hex läuft aber sicher da ich den auch runtergeladen und programmiert habe. Programmier den Controller noch mal neu. Kannst aber ruhig den Transistor auch mal testen.
Was mich etwas irritiert ist vielmehr dieses merkwürdige Verhalten deines Mainboards. Wenn du nämlich ein Amperemeter über den Powerjumper anschließt müsste der Rechner sofort einschalten weil der Innenwiderstand fast 0 ist.
Bis dann
steini

Wesie · 11. Mai 2004

AmpereMeter = ~0 Ohm => So habe ich es auch mal gelernt .....
Ich hatte das AmpereMeter an beiden Power-On steckern angeschlossen, wobei der vordere ( zum Display hin ) ja GND ist.

Die Schaltung habe ich so aufgebaut, das sie GND von der Con2 und vom Power-ON Masse bezieht. Vcc habe ich vom Netzteil abgegriffen und zusätzlich auf der Platine zw. Vcc und GND einen Elko eingelötet. Vielleicht sollte ich noch einen kleinen C mit dazu setzen ( zw.Entstörung).

Wesie · 11. Mai 2004

Schaltung war i.O. -> Prüfschaltung mit LED an Pin2 etc ....
Der Fehler saß mal wieder zw. Stuhl und Tastatur :

Ich hatte die Berechnung für $Min nachdem der Befehlsstring zum Shutdown zusammengebaut wurde . Ich bin davon ausgegangen, daß die variablen zur Laufzeit gefüttert werden ...
Jetzt wird der Timer immer schön gesetzt.
Vorher habe ich mir noch die Federn gelesen mit dem Parameter opost ( kommt dir das bekannt vor ? )

Ich hatte erst das neue hex gebrannt, aber ( durch die Kid's abgelenkt worden ) habe ich den Eindruck, daß der Rechner nicht hochgefahren ist... immo immer noch das orig, Wakeup_auto_on drauf und nachdem der AVR nicht in Count_Mode gesetzt wurde - s.o. erst einmal Fehlersuche begonnen.

steini · 11. Mai 2004

Hi Wesie,
na ja, so iss das eben
Man muß sich einfach dann etwas Zeit nehmen, ...soweit das möglich ist ;).
Ich hab mein Modul übrigens genauso angeschlossen wie du. Das sollte auch reichen für die Verbindung zum GND des Mainboards.
Du solltest aber aufgrund deiner Konfiguration das veränderte *.hex schon nehmen....ist sicherer. Versuch's einfach, läuft ja bei mir auch problemlos 8). Ist auch nich viel geändert. Den Sourcecode häng ich die Tage mal an.....wenn der bei dir auch läuft
Ja und mit dem "opost".... kannst dir jetzt ja vielleicht vorstellen dass ich "etwas" länger gebraucht habe um das rauszukriegen. Ist übrigens in der neuen Version geändert (kann man hier runterladen). Sind auch noch andere "Probleme" beseitigt.
Hauptsache es geht jetzt
Gruß
steini

Wesie · 12. Mai 2004

Gestern habe ich noch das Exp. Board von STB ( Dirk ) bekommen. Da auf dem Board ja auch ein Einschalter ist ( via FB ) werde die 2 Schaltungen mittels eines 7400 ( AND ) zuzammenhängen. Auf dem Schaltplan, welcher verwendet wurde, ist nachdem Transitor ein 100 Ohm Widerstand genommen worden ....

steini · 12. Mai 2004

Hi,
ok, ich denke man kann beide Schaltungen parallel betreiben. Ich würd das mit nem Transistor und nem Widerstand versuchen, ewa so wie in dem angehängten Bild. Das würde ja noch auf die Wakeup-Platine passen. Aber wie gesagt: Bitte nur mit der modifizierten Software!!!
Gruß
steini

Wesie · 13. Mai 2004

Manchmal sieht man den Wald vor lauter Bäumen nicht :
Wir haben ja noch etliche Ein und Ausgänge frei :
Einfach einen weiteren Eingang definieren - nach der Routine für den Datenanfang anspringen, wenn der auf Low ist, die Routine für den den Ausgang Richtung Power-on anspringen ;), wenn nicht wieder in die Routine für den Datenempfang.

Das heißt keine weiteren Hardware Änderungen - nur Software

steini · 13. Mai 2004

Guten Morgen,

Zitat

Wir haben ja noch etliche Ein und Ausgänge frei

Ja klar. Jede Menge.

Zitat

Einfach einen weiteren Eingang definieren - nach der Routine für den Datenanfang anspringen, wenn der auf Low ist, die Routine für den den Ausgang Richtung Power-on anspringen

Gute Idee!! Allerdings läuft die UART-Routine sozusagen im Vordergrund also ohne Interrupt weil das softwaremäßig weniger aufwendig und bisher auch nicht nötig war
Daher mußt du dann einen der beiden ext. Interrupts (PD2 oder PD3) für sowas nehmen und halt in der entsprechenden Interruptroutine den Ausgang schalten. Das ist nicht sehr kompliziert aber ich dachte das mit dem Transistor wäre noch einfacher
Gruß
steini

Wesie · 13. Mai 2004

Ich denke, daß wir hier keine Interrupt brauchen werden und dies im Vordergrund mit laufen lassen können, da wir ja mit 4 Mhz arbeiten.
Es muss ja nur abgefragt werden, ob an einem pin Low anliegt, wenn nicht mach weiter -> das sind dann max. 4 Takte mehr. Da das Low Signal ja auch ~ min. 0.5 sec anliegt, haben wir hier auch die Zeit dies zw. Vergleich des Strings und wieder am Anfang vom Empfang mit einzupflegen, oder ?

steini · 13. Mai 2004

OK Wesie,
hast schon Recht. Schnell genug ist das Teil allemal.
Ich hab mich auch unklar ausgedrückt. Was ich sagen wollte ist, dass der Controller permanent im Vordergrund auf ein Signal an der UART wartet. Da kommt ja bei laufendem Display so alle paar mS ein Signal. Aber man kann das auch dazwischen "fummeln". Aus Gründen der Übersicht mach ich das nur nicht ganz so gerne. Aber gut.
Das Programm "gammelt" die meiste Zeit hier

Code

_GetCh:	sbis	USR,0x07
	rjmp	_GetCh
	in		zl,UDR
	ret

rum ;). Und erst recht wenn der Rechner nicht läuft (kommt ja nix auf die UART)
Das könntest du jetzt in z.B

Code

_GetCh:	sbis		PINX,x
	rcall	_PWon
	sbis	                USR,0x07
	rjmp	_GetCh
	in		zl,UDR
	ret

abändern, wobei PINX,x dein abzufragender Port ist. Dieser muß natürlich bei der Initialisierung als Eingang (also cbi DDRX,x) und der Pullup aktiviert (also sbi PORTX,x) werden. Dann noch das Unterprogramm

Code

_PWon:
	sbi		DDRB,4
	ldi		zl,Low(500)
	ldi		zh,high(500)
	rcall	_wms
	cbi		DDRB,4
	ret

Wäre dann auch sicher sinnvoll noch einen Pin als Sensor für den laufenden Rechner zu nehmen (z.B. 5V vom NT also nicht 5VSB) und diesen im Unterprogramm abzufragen um zu verhindern dass der Powerjumper im laufenden Betrieb bei Betätigung des IR-Einschalters kurzgeschlossen wird.
Iss jetzt nur so ne Idee
steini

steini · 13. Mai 2004

Sooo Wesie,
damit du auch was machen kannst hab ich mal die modifizierte Software angehängt. Wenn du dir den Assembler-Code anschaust wirst du sehen, dass es etwas anders laufen sollte um klare Verhältnisse zu gewährleisten. Anstatt der optimistischen

Code

_GetCh:	sbis		PINX,x
	rcall	_PWon
	sbis	                USR,0x07
	rjmp	_GetCh
	in		zl,UDR
	ret

sollte dies

Code

_GetCh:	
;-> Sensorpinabfrage
	sbic		PINX,x
	rjmp	_GetCh1
	cli
	rcall	_PWon
	sei
	rjmp	init
_GetCh1:
	sbis		USR,0x07
	rjmp	_GetCh
	in		zl,UDR
	ret

Alles anzeigen

rein, damit die Variablen wieder in einen definierten Zustand gesetzt werden und kein Timerinterrupt "dazwischenfunkt". ;)So sollte das funktionieren, tut es bei mir auch. Hier ist als "Sensorpin" für den IR-Einschalter PD2 (also Pin6) verwendet. Das kannst du natürlich so machen wie du's brauchst. Vielleicht hast du ja auch ne bessere Variante gefunden. Wäre dann schön wenn du sie mir mal gibst.
Ach ja,....Alle die das Modul verwenden und nicht die Konfiguration von Wesie haben sollten alles so lassen wie es ist Diese ganzen Änderungen in der Software beziehen sich auf diesen speziellen Fall!
Gruß
steini

Wesie · 13. Mai 2004

Hi Steini,
das geht ja schneller als die Polizei erlaubt. Ich werde es gleich mal runterladen und schauen, ob ich soweit durchsteige. Ich habe heute mal meine alten AVR Sachen wieder ausgegraben und ich denke, daß wenn wir in den Init.Routine die Ports klar definieren incl. internen Shutup (auf 5V) kann auch derjenige das Asm hernehmen,der den Port freiläßt. Also ich meine init nach dem Muster:

Zitat

ldi r16,0x00
out DDRD, r16 ;Port D durch Ausgabe von 0x00 ins
;Richtungsregister DDRD als Eingang konfigurieren

ldi r16, 0x0F
out PORTD, r16 ;PORTD 7,6,5,4 auf LOW- Shutdown
;PORTD auf HIGH -Shut-up

Alles anzeigen

Wesie · 14. Mai 2004

Edit On :

Bei DDRn = Input bedeutet bei PORT eine 0 nicht Shutdown, sondern TRi-State; eine 1 ist wie oben erwähnt ein Pull-UP

Edit off

steini · 14. Mai 2004

Hi,
klar, die Ports müssen definiert werden. Bei einem Reset werden alle Ports auf Tri-State gesetzt. Die bleiben auch so wenn sie nicht umdefiniert werden. Es werden hier nur die Ports angefasst, die auch gebraucht werden. Der Rest ist Tri-State, also hochohmig.
Daher kann selbstverständlich der Code von jedem verwendet werden. Passieren kann nix. Nur ist es nicht notwendig das zu tun, es sei denn man will/muss sowas machen wie du.
Hast du denn mal die Software getestet? Also ich hab die mal bei mir aufgespielt. Wenn ich jetzt Pin6 gegen GND kurzschließe (Was im eingebauten Zustand bei dem SMD-Chip ganz schön fummelig ist ;)) dann startet der Rechner auch erwartungsgemäß und der Controller wird in den "Empfangsmodus" zurückversetzt. Wenn du jetzt noch prüfen möchtest ob der Rechner läuft, dann sind das noch so 3-4 Zeilen Code mehr und natürlich der 10K Pullup zum NT
Gruß
steini

Wesie · 14. Mai 2004

Ich werde erst noch einmal den Pin umbiegen , da ich auf der Seite von Pin11 bis 20 noch voll den Platz auf der Platine habe und auf der anderen Seite nichts mehr frei ist, ausser für Drahtbrücken. Gestern habe ich mir noch einmal das AVR-Studio gezogen ( jaja, lange nichts mehr mit gemacht ... ) und werde es dann neu kompilieren und dann einsetzen. Rückmeldung folgt, sobald es läuft.

steini · 14. Mai 2004

Jau, mach mal.
Falls du die Version 4.x gezogen hast würde mich mal deine Erfahrung damit interessieren. Kannst ja mal den Simulator laufen lassen, falls du soviel Geduld hast Port "umbiegen" ist ja kein Problem.
bis dann
steini

Hardware-wakeup die 4.

Jetzt mitmachen!

Teilen