Benutzer:Sven
Sven versucht zurzeit Ethersex mit SD-Card und HTTP Server zum Laufen zu kriegen. :-) (auf dem Pollin NET-IO mit ATMEGA644)
--Sven 09:29, 18. Jun. 2009 (UTC)
Inhaltsverzeichnis
Endlich habe ich Ergebnisse:
- http Webserver ging von Anfang an
- serielles Debugging funktioniert jetzt
- HC595 an den Pins PD2, PD3 und PD4 funktioniert hardwaretechnisch und 'via ecmd set port 3 n' via http, telnet, und sogar über die serielle Debug-Konsole! Großartig! :-)
Was fehlt mir noch:
- HC595 Pin - Definition
Update: habe inzwischen die Technik begriffen (bilde ich mir ein ;-) ) und in /pinning/hardware/netio.m4 folgende Eintragungnen gemacht:
ifdef(`conf_HC595', `dnl
/* port pin the HC595_CLOCK is attached to */
pin(HC595_CLOCK, PD2, OUTPUT)
')dnl
ifdef(`conf_HC595', `dnl
/* port pin the HC595_DATA is attached to */
pin(HC595_DATA, PD3, OUTPUT)
')dnl
ifdef(`conf_HC595', `dnl
/* port pin the HC595_STORE is attached to */
pin(HC595_STORE, PD4, OUTPUT)
')dnl
Was dazu führt, dass der Compiler nicht mehr über die HC595 Pins und Ports meckert. Jetzt schmeckt ihm was mit uip nicht. (Später mehr dazu.)
Was ich festgestellt habe:
- Der Schaltplan in hardware/io_expander/hc595.sch ist falsch. Die Pins 10 des HC595 müssen an VCC und die Pins 13 an GND. (ich ändere die gschem-Datei noch)
- Der Schaltplan sollte jetzt stimmen, danke für den Hinweis --stettberger 17:13, 18. Jun. 2009 (UTC)
update: Vielen Dank für die schnelle Reaktion. :-)
Ich habe trotzdem mal den Plan überarbeitet und finde ihn so übersichtlicher und nicht unlogisch.
Fals gewünscht ich würde meine Version auch commiten. (muss nur Git-fit werden)
SD-Card Reader
- Hardware steht, sollte funktionieren
- Compilerfehler, den doppelt definierten CS-Pin betreffend, sind seit dem Wochenende (oder so) Geschichte
- Ich habe den SD CD-Pin auf PB1 gelegt, da an PB2 ja INT vom ENC28J60 hängt und PB1 auf J11 rauskommt
ifdef(`conf_SD_READER', `dnl /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB1, OUTPUT) ')dnl
serielles Debugging
Damit das richtig funktioniert sind folgende Dinge wichtig:
- die Fuse Bits des m644 auf hfuse 0xdc und lfuse 0xe7 setzen -> sonst Kauderwelsch an RS232
Grund dafür ist, dass der Atmega 644 in Werkseinstellung mit internem RC-Oszillator läuft. Damit funktioniert zwar Einiges (in Zeitlupe), aber die serielle Schnittstelle ist zu lahm. (Dank an --jochen)
Stella empfiehlt einen Blick auf den AVR Fuse Calculator zu werfen. Man sollte aber trotzdem wissen was man damit macht ;-)
Falls noch nicht geschehen: Fuses mit Atmel Programmieradapter via USB "brennen" (geht natürlich auch ein anderer Adapter)
avrdude -c avrispmkII -P usb -p m644 -U lfuse:w:0xe7:m -U hfuse:w:0xdc:m
ansehen mit
avrdude -c avrispmkII -P usb -p m644 -v
- die Baudrate ist 115200 (38400 und 9600 unter Umständen möglich)
- welche im Einzelfall aktiviert wird, steht in Serial Line Debugging --Stella 16:18, 18. Jun. 2009 (UTC)
- mit Terminalprogrammen geht es nicht richtig (?)
- bei minicom und Konsorten muss man in den Einstellungen Handshaking ausschalten; grundsätzlich geht es schon (ich verwend' immer minicom) --Stella 16:18, 18. Jun. 2009 (UTC)
- am besten mit dem Programm screen unter Linux verbinden
screen /dev/ttyS0 115200 8N1 oder screen /dev/ttyUSB0 115200 8N1
Jetzt kann man sich mit dem Ethersex "unterhalten". Auf "ip" erscheint die IP-Adresse. Cool! :-) Um screen zu beenden drücke Strg-a k, dann mit y (j) bestätigen.
