Hallo Besucher, der Thread wurde 137k mal aufgerufen und enthält 608 Antworten

letzter Beitrag von Stefan Both am

Projektvorstellung: SDrive-MAX

    Zitat von kbr

    Nein, es gab bislang keinen Grund dazu, die Defaults haben sonst immer gepasst.

    Hoffentlich ist CKDIV8 nicht gesetzt, sonst passt das serielle Timing natürlich nicht!

    Ich denke, folgende Werte sollten passen:

    low: 0xC7 high: 0xD6(ohne Bootloader 0xD7) ext: 0xFF

    ckdiv8 war nicht gesetzt. Leider immer noch kein Bootvorgang.

    Ich hab noch mal einen anderen 328p und 7407 probiert, Stecker und Verdrahtung kontrolliert - alles OK.


    Die 328p Defaults sind 62, d9, ff - also mit ckdiv8 - die passen nicht!

    Die Uno Defaults sind ff, de, 05 - also ohne ckdiv8, mit brown out


    low=c7 very full swing und clock out an Port B0. Also ich denke da passt uno default mit ff besser - der Clock out wird ja nicht benötigt und das Quarz ist ein Low Power.


    In deiner Anleitung von 2017 hab ich das gefunden - wobei lfuse=fe für 16 MHz falsch ist - das muss ff sein.

    Bildschirmfoto 2021-10-31 um 09.11.49.png


    Christian

    Ja stimmt, low=0xff passt besser, da hab ich mich verklickt...


    Aber der Screenshot stammt vom sdrive-ng, da war noch einiges anders, z. B. 4K Bootloader, anderer Quarz, und low=0xFE ist ja nur eine kürzere Startup-Time, spielt also keine Rolle. Den Rest bitte nicht mit dem Sdrive-MAX vergleichen!


    EDIT: Und EEPROM-Preserv war bei mir bis jetzt bei jedem UNO standardmäßig gesetzt, macht ja auch Sinn, da man über den USB-Bootloader das EEPROM nicht direkt beschreiben kann. Wenn das dann jedes Mal gelöscht wird, ist das schon ziemlich blöd. Ich musste bislang noch nie was an den FUSE-Bits anpassen, wo hast du diese angeblichen Defaults her?

    Zitat von kbr

    Ja stimmt, low=0xff passt besser, da hab ich mich verklickt...


    Aber der Screenshot stammt vom sdrive-ng, da war noch einiges anders, z. B. 4K Bootloader, anderer Quarz, und low=0xFE ist ja nur eine kürzere Startup-Time, spielt also keine Rolle. Den Rest bitte nicht mit dem Sdrive-MAX vergleichen!


    EDIT: Und EEPROM-Preserv war bei mir bis jetzt bei jedem UNO standardmäßig gesetzt, macht ja auch Sinn, da man über den USB-Bootloader das EEPROM nicht direkt beschreiben kann. Wenn das dann jedes Mal gelöscht wird, ist das schon ziemlich blöd. Ich musste bislang noch nie was an den FUSE-Bits anpassen, wo hast du diese angeblichen Defaults her?

    Die defaults hatte ich aus dem web gegoogelt, aber sie sind auch in der Arduino boards.txt.

    Extended=05 war aber Quatsch - das gibt es auch gar nicht. Richtig ist FD - also mit brown out und die anderen 5 bits=1

    Das mit dem EEPROM-Preserv ist Quatsch, das trifft ja nur zu, wenn man über SPI flasht, was du aber offensichtlich gemacht hast. Bitte zukünftig immer dazusagen! Per USB wird das Flash ja per Software beschrieben, sprich da bleibt das EEPROM immer ehalten.


    Ich bin zu lange draußen aus dem Geschäft :gruebel


    EDIT: Den ganzen Aufwand mit dem eeprom_writer hab ich mir ja nur aus diesem Grund gemacht, damit jedermann ganz einfach per USB flashen kann. Per SPI kann man ja direkt das EEPROM beschreiben, dazu gibts im Build-Prozess auch eine .hex-Datei.

    Zitat von kbr

    Das mit dem EEPROM-Preserv ist Quatsch, das trifft ja nur zu, wenn man über SPI flasht, was du aber offensichtlich gemacht hast. Bitte zukünftig immer dazusagen! Per USB wird das Flash ja per Software beschrieben, sprich da bleibt das EEPROM immer ehalten.


    Ich bin zu lange draußen aus dem Geschäft :gruebel


    EDIT: Den ganzen Aufwand mit dem eeprom_writer hab ich mir ja nur aus diesem Grund gemacht, damit jedermann ganz einfach per USB flashen kann. Per SPI kann man ja direkt das EEPROM beschreiben, dazu gibts im Build-Prozess auch eine .hex-Datei.

    Danke erst mal für die tolle Arbeit und die Unterstützung!


    Ich hatte geschrieben, das ich mit dem Atmel-ice programmiert habe.

    Das eeprom könnte ich natürlich auch direkt schreiben, aber der eeprom writer macht ja wohl bei der v1.2 auch die Touchscreen Erkennung und schreibt da etwas ins eeprom ?


    Beim Einschalten des Atari 800XLs kommt im Monitor mehrfach SIO-Error: 1


    Kannst du mir sagen, was das bedeutet?

    Atmel-ice ist/war mir leider kein Begriff...


    Korrekt, aus Platzmangel musste die Touchscreenerkennung in den eeprom_writer wandern, daher ab V1.2 nun leider notwendig.


    Im Archiv ist eine Datei "doc/errorcodes.txt":


    SD-Card:

    1 error going into idle state

    2 error getting enhanced power requirements

    3 error on initialization for SD

    4 error on initialization for MMC

    5 error setting block length to 512


    FAT:

    1 error reading master bootblock

    2 error reading partition bootblock

    3 filesystem not supported


    SIO:

    1 CMD changed to high during data reception

    2 timeout

    3 usart frame error

    4 usart data overrun


    Deutet also auf ein Problem mit der COMMAND-Leitung hin. Macht der Atari die üblichen Blubbergeräusche?

    Zitat von castlewolfenstein

    Moin Ihr Lieben,

    die Bedienung der Standard Startsoftware (sdrive.atr) nach dem Einschalten kann auch mit dem Joytick für die Richtungen bedient werden.
    Leider funktioniert der Feuerbutten (Return) nicht. Gibt es da eine neuere Version?

    Eben in den Code geschaut, der Trick ist, man muß den Knopf gedrückt halten, und dann nach rechts bewegen, usw.

    Interessant, es kann auch ein Timing-Problem sein, daß etwas mit der Baudrate nicht stimmt, und das Sdrive-MAX den Befehl nicht erkennt.


    EDIT: Schwierig, ich würd jetzt an der Stelle mal das Oszi dranhängen und schauen, was da am RX-Pin am Arduino ankommt.

    Zitat von kbr

    Interessant, es kann auch ein Timing-Problem sein, daß etwas mit der Baudrate nicht stimmt, und das Sdrive-MAX den Befehl nicht erkennt.


    EDIT: Schwierig, ich würd jetzt an der Stelle mal das Oszi dranhängen und schauen, was da am RX-Pin am Arduino ankommt.

    So, ich hab mal mit dem Ossi gemessen.

    Am SIO Pin 5 kommen zyklisch Signale und die Command Leitung ist in der Zeit low. Am RX-Pin das Atmega's ist nur low hinter dem 7407.

    Und das liegt daran, weil der Designer dieser Platine, den PullUp dort vergessen hat. Wobei man evtl. auch in der FW einen PullUp aktivieren könnte - ich weiß aber nich ob das am RX Pin geht.

    Mit einem 10kOhm von Pin 2 nach Ground läuft das sdrive nun einwandfrei.


    Danke noch mal für die tolle Entwicklung!


    Christian

    Freut mich, daß es läuft!


    Aber normalerweise ergibt sich der Pull-Up anhand des 1K Widerstandes zum Seriell-/USB-Wandler, der im Ruhezustand ein high liefern sollte. https://www.arduino.cc/en/uplo…no_Uno_Rev3-schematic.pdf

    Daher macht es keinen Sinn, den per Software zu aktivieren, einmal reicht :/


    PS: Ich betreibe ja nach wie vor alle meine SDrive-MAX ohne diesen 7407, und hatte damit noch nie Probleme, auch nicht zusammen mit einer 1050.

    immerhin - du hast es rausgefunden! - freut mich, dass es nun geht


    für alle anderen, die noch eine von den Platinen haben:

    wo genau muss der evtl. notwendige Pull-Up hin?

    Zitat von vossi

    Mit einem 10kOhm von Pin 2 nach Ground läuft das sdrive nun einwandfrei.

    wäre das dann nicht ein Pull-Down?

    Ich meinte natürlich nach VCC - war ein Schreibfehler.

    Der muss zwischen Pin 2 und Pin 7.


    Aber vielleicht hat die neuere Platine mit Spannungswandler ja einen Pull Up an Pin 2?


    Die Diode an SIO 3 kann man weglassen, da der 7407 ja open Collector ist und eh nur Ground durchschalten kann.

    In die SIO 10-Plus-Leitung hab ich eine 1N5817 gesetzt, die hat nur etwa 0,4V Spannungsfall. Nun kann man extern mit 5V versorgen (Diode sperrt) oder über den Atari. Dann kommen noch etwas 4,4V am sdrive an und das funktioniert. Den Jumper hab ich dauerhaft gesteckt.


    Christian

    Ich hab ja keine Uno-Platine, sondern eine Spezial-Platine ohne USB/Seriell-Wandler, dafür aber mit 7407 onboard. Deshalb fehlt da der PullUp.


    Christian

    Zitat von kbr

    Immer diese Sonderlocken :D


    Aber daran sieht man, wie schnell so ein winziges Detail vergessen wird, und sehr entscheidend sein kann...

    Ja, allerdings. Man muss schon genau die Schaltung und Funktionsweise verstehen, wenn man etwas umbaut oder weglässt ;)


    Der Buffer am Eingang des Atmegas ist auch gar nicht notwendig, wenn man keinen USB-Chip daran hat.

    Allerdings benötigt man trotzdem einen Pullup - so wie ja auch beim Command-Eingang in sdrive.c/main definiert ist.


    PS: Wird der serielle Ausgang des 328p immer zwischen low und hi-z hin und her geschaltet?

    Dann braucht man den 7407 ja wirklich überhaupt nicht, wenn man keine Arduino-Platine mit USB Chip verwendet.


    Christian

    Interessanter Punkt, das Datenblatt sagt jedoch, daß bei Output immer feste Pegel anliegen, man kann daran ja auch direkt eine LED betreiben, so 10-20mA wird es schon sein, also kein open Collector. Das ist vermutlich auch das Problem, was dann viele haben in Kombination mit weiteren Geräten, die schaffen es dann nicht, den Pegel so weit nach unten zu ziehen. Da bei mir zuerst die 1050 kommt, und dann ein relativ langes Kabel(ca. 1.5m) zum SDrive-MAX, wirkt der Leitungswiderstand wohl als Pull-Up, und das genügt, damit die 1050 den Pegel weit genug drücken kann.

    Es wäre zu überlegen, beim Senden den Port immer zwischen In und Out umzuschalten, müsste man mal ausprobieren, ob das vom Timing her kein Problem macht.


    Beim RX-Input könnte man den internen Pull-Up zusätzlich aktivieren, da ich aber Arduino kompatibel bleiben möchte, ist das wohl eher keine Option. Sehe ich auch nicht unbedingt für nötig, der Atari liefert im Ruhezustand ja auch immer high-Pegel.