Angepinnt LCD-SD2IEC Firmware 1.0.0 für LarsP-Layout kompiliert

  • Der Lcd-Part ist tatsächlich der selbe, wie der für LarsP. Wenn ich mich noch richtig erinnere, dann ist bei dem Evo2-Code eine andere Beschaltung der Led's (Duo-Led) und eine Real-Time-Clock drin enthalten. Aber auch ich werde dafür nichts mehr machen, da ich nie eine Antwort von dem Verkäufer erhalten habe, um ihn auf ein paar Fehler im Source-Code hinzuweisen (z.B. das gerade zu ladende File aus einem D64-Image wurde bei der Evo2-Firmware nicht mehr auf dem LCD angezeigt)

    DoReCo #52 am Sa. 18.03.2017
  • Hab jetzt auch ein evo2 und die mini von denen da weil die summasummarum eben am einbaufreundlichsten sind und alles mitbringen was sein muss.

    Wenn der code fürs RTC in der lars-p fw schon enthalten ist dann frage ich mich immer warum das bei den ganzen bausätzen nicht genutzt wird? Ist das so teuer oder aufwendig eine rtc zu integrieren? Das evo2 ist das einzige mit rtc was ich kenne und glaub noch eins aus usa das es mal gab.
    Defekte Backstein-Netzteile bitte nicht wegwerfen, ich nehme sie gerne.
  • grade nachgesehen: die evo2 firmware hat auch noch einen kleinen patch fuer die RTC. der fehlt auch noch bei dem patch, den ich weiter oben gepostet habe.

    soweit ich sehe sind folgende aenderungen in der EVO2 firmware:

    CONFIG: prinzipiell larsp aber HARDWARE_VARIANT = 10
    RTC: eine kleine aenderung zum DS1307 support, der eigentlich eh schon drinnen ist
    LCD: der groesste brocken, betrifft mehrere files

    wenn man momentan ein diff zwischen git version und evo2 firmware macht, kommen endlos aenderungen, wegen copyright header (aenderung auf 2017) das ist ein bisserl unuebersichtlich.

    Ingo: Wenn ich dir einen sauberen patch fuer config und RTC zukommen lasse, ueberlegst du dir, ob du den uebernehmen willst?
  • katarakt schrieb:

    Wenn der code fürs RTC in der lars-p fw schon enthalten ist dann frage ich mich immer warum das bei den ganzen bausätzen nicht genutzt wird? Ist das so teuer oder aufwendig eine rtc zu integrieren?

    Das ist weder teuer noch aufwendig, aber es mindert natürlich die Gewinnspanne der eBay-Frickler. Selbst nachrüsten ist aber auch nicht besonders aufwendig, einfach eines der billigen DS3231-RTC-Module von eBay an die sd2iec-Stromversorgung sowie die (Software-)I2C-Pins des AVRs hängen. Die sind zwar im Augenblick nicht für alle Hardware-Varianten definiert und deswegen der RTC-Support nicht überall per Default an, aber ich nehme gerne Vorschläge für geeignete Pins bei den noch nicht damit ausgestatteten Konfigurationen an.

    Das evo2 ist das einzige mit rtc was ich kenne und glaub noch eins aus usa das es mal gab.

    Die Final Expansion 3 hat auch eine RTC am integrierten sd2iec.

    everslick schrieb:

    CONFIG: prinzipiell larsp aber HARDWARE_VARIANT = 10

    Ohje. Was funktioniert alles nicht, wenn man die normale larsp-Hardwarekonfiguration verwendet?

    wenn man momentan ein diff zwischen git version und evo2 firmware macht, kommen endlos aenderungen, wegen copyright header (aenderung auf 2017) das ist ein bisserl unuebersichtlich.

    Idealerweise difft man gegen genau die Revision, von der die modifizierte abstammt - wenn das nicht bekannt ist, scripte ich meist ein wenig auf der Kommandozeile, um die Originalversion mit dem kleinsten diff zu finden.

    Ingo: Wenn ich dir einen sauberen patch fuer config und RTC zukommen lasse, ueberlegst du dir, ob du den uebernehmen willst?

    Ich habe bisher nicht reingeschaut, aber prinzipiell fände ich es wichtig, dass der Code die eh schon vorhandenen Display-Hooks verwendet und nicht überall eigene Aufrufe einstreut.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    Ich habe bisher nicht reingeschaut, aber prinzipiell fände ich es wichtig, dass der Code die eh schon vorhandenen Display-Hooks verwendet und nicht überall eigene Aufrufe einstreut.
    ja, darum wollte ich das auch in 2 stufen machen. einmal prinzipieller support mit RTC und dann 'eventuell' LCD support, wenn man das ordentlich hinbekommt.


    Unseen schrieb:

    Ohje. Was funktioniert alles nicht, wenn man die normale larsp-Hardwarekonfiguration verwendet?
    ich bin gerade die HARDWARE_VARIANT 10 und die HARDWARE_VARIANT 3 durchgegangen und konnte keinen unterschied feststellen. d.h. es muesste mit der standard variante 3 gehen. ich werd das gleich mal testen ....
  • so mal wieder ein bisserl zeit investiert:

    ich versuche eine aktuelle firmware ohne LCD aber mit RTC zu kompilieren. dabei ist mir aufgefallen, dass man anscheinend IMMER 2 rtc typen in der config aktivieren muss, damit das NEED_RTCMUX define gesetzt wird. wenn das nicht passiert fehlen beim linken die rtc_*() funktionen. ich denke das ist nicht so gedacht oder? Unseen?
  • everslick schrieb:

    ich versuche eine aktuelle firmware ohne LCD aber mit RTC zu kompilieren. dabei ist mir aufgefallen, dass man anscheinend IMMER 2 rtc typen in der config aktivieren muss, damit das NEED_RTCMUX define gesetzt wird. wenn das nicht passiert fehlen beim linken die rtc_*() funktionen.
    Nö? Es fehlte lediglich in der ds1307-3231.c ein Alias von rtc_init auf dsrtc_init (gerade gefixt), aber alle anderen RTCs compilieren auch einzeln. Wenn das bei dir nicht klappt scheinst du seltsame Probleme mit deiner Toolchain zu haben, die rtc_*-Funktionen werden in jeder RTC-Implementierung per Weak Alias auf die jeweiligen Funktionen umgebogen. Wenn der RTC-Mux eincompiliert ist, sind dessen Funktionen "stärker" und überschreiben die Aliase; wenn nur eine Implementierung eingebunden ist werden ihre Aliase verwendet.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • ah, ok, dann hab ich den fkaschen schluss gezogen, denn jetzt kompilierts auch, wenn ich nur eine RTC in der config hab, danke fuer den fix.

    trotzdem liefert "T-RI" 30,SYNTAX ERROR :(

    ich hab alle SOFTI2C_* defines gecheckt, zwischen larsp harware variant und original evo2 firmware, da ist alles exact gleich.

    zur sicherheit hab ich den original evo2 source nochmal compiliert und da geht die uhr.

    koennte es sein. dass der DS1307 codepfad seit dem umbau einen bug hat?
  • everslick schrieb:

    trotzdem liefert "T-RI" 30,SYNTAX ERROR :(
    Hast du denn die Zeit vorher gesetzt?

    koennte es sein. dass der DS1307 codepfad seit dem umbau einen bug hat?
    Zumindest mit dem DS1307-Modul von eBay was ich zum Testen verwende funktionierte es.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    Hast du denn die Zeit vorher gesetzt?
    jupp. die evo firmware liefert auch die richtige zeit zurueck. ausserdem muesste ich ja ein 31,SYSNTAX ERROR bekommen, wenn es an der nicht gesetzten uhr liegt, oder?

    >> If the RTC isn't present, both commands return
    >> 30,SYNTAX ERROR,00,00; if the RTC is present but not set correctly T-R will
    >> return 31,SYNTAX ERROR,00,00.

    ich werde also wohl oder uebel versuchen muessen, da irgendwie eine serielle dranzukriegen. das ding hat eine 6-polige ISP schnittstelle von denen ich mit freiem auge sehe das sie mit pad 2, 3 und 4 vom atmel verbunden ist. aha, ist aber SPI und reset laut datenblatt. ich brauch den pin10 (TX0) oder?
  • everslick schrieb:

    jupp. die evo firmware liefert auch die richtige zeit zurueck. ausserdem muesste ich ja ein 31,SYSNTAX ERROR bekommen, wenn es an der nicht gesetzten uhr liegt, oder?
    Als ob ich die Nummern auswendig kennen würde...

    ich werde also wohl oder uebel versuchen muessen, da irgendwie eine serielle dranzukriegen. das ding hat eine 6-polige ISP schnittstelle von denen ich mit freiem auge sehe das sie mit pad 2, 3 und 4 vom atmel verbunden ist. aha, ist aber SPI und reset laut datenblatt. ich brauch den pin10 (TX0) oder?
    TX0 klingt gut

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    TX0 klingt gut
    soweit so gut. ich hab debug uart eingeschalten, baudrate auf 115200 und buf_shift auf 8 eingestellt:

    CONFIG_RTC_DSRTC=y
    CONFIG_UART_DEBUG=y
    CONFIG_UART_BAUDRATE=115200
    CONFIG_UART_BUF_SHIFT=8

    aber da bekomm ich keinen sinnvollen output (ich lass die ausgaben von picocom mit drinnen, damit man die einstellungen sieht)...

    Quellcode

    1. root@secrets:/mnt# picocom -b 115200 /dev/ttyUSB0
    2. picocom v1.7
    3. port is : /dev/ttyUSB0
    4. flowcontrol : none
    5. baudrate is : 115200
    6. parity is : none
    7. databits are : 8
    8. escape is : C-a
    9. local echo is : no
    10. noinit is : no
    11. noreset is : no
    12. nolock is : no
    13. send_cmd is : sz -vv
    14. receive_cmd is : rz -vv
    15. imap is :
    16. omap is :
    17. emap is : crcrlf,delbs,
    18. Terminal ready
    19. ���z,��GAͯ��r#ፆ.V+k7Aa���8��K�ɡ��**����������....
    Alles anzeigen
    ich hab auch andere baudraten probiert: 19200 und 38400. ich sehe, dass ca alle 250ms etwas ausgegeben wird dann mal wieder alle 500ms, manchmal kommen richtige bursts. jemand eine idee?
  • everslick schrieb:

    soweit so gut. ich hab debug uart eingeschalten, baudrate auf 115200 und buf_shift auf 8 eingestellt:
    (...)
    aber da bekomm ich keinen sinnvollen output (ich lass die ausgaben von picocom mit drinnen, damit man die einstellungen sieht)...
    Kein Wunder - mit einem 8MHz-Quarz hat man eine ziemlich hohe Frequenzabweichung bei 115200 Baud und die von mir verwendete Formel zur Berechnung des Divisors rundet in dem Fall auch noch ungünstig. Nimm lieber 19200.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • fsck!

    hab mich grandios verschaut. das evo2 ist DOCH eine andere HW VARIANTE naemlich mit i2c auf port A und nicht auf C und SDA und INTRQ sind vertauscht. sonst ist alles gleich!

    :cry:

    hier ein minimales diff zu arch-config.h

    Unterschiede-Datei: evo2.diff

    1. diff --git a/src/avr/arch-config.h b/src/avr/arch-config.h
    2. index 955d20d..7c74acb 100644
    3. --- a/src/avr/arch-config.h
    4. +++ b/src/avr/arch-config.h
    5. @@ -366,8 +366,8 @@ static inline void buttons_init(void) {
    6. }
    7. -#elif CONFIG_HARDWARE_VARIANT == 3
    8. -/* ---------- Hardware configuration: LarsP ---------- */
    9. +#elif (CONFIG_HARDWARE_VARIANT == 3 || CONFIG_HARDWARE_VARIANT == 10)
    10. +/* ---------- Hardware configuration: LarsP or Evo2 ---------- */
    11. # define HAVE_SD
    12. # define SD_CHANGE_HANDLER ISR(INT0_vect)
    13. # define SD_SUPPLY_VOLTAGE (1L<<21)
    14. @@ -451,14 +451,27 @@ static inline void buttons_init(void) {
    15. PORTA |= BUTTON_NEXT | BUTTON_PREV;
    16. }
    17. +#if CONFIG_HARDWARE_VARIANT == 3
    18. +
    19. # define SOFTI2C_PORT PORTC
    20. # define SOFTI2C_PIN PINC
    21. # define SOFTI2C_DDR DDRC
    22. # define SOFTI2C_BIT_SCL PC6
    23. # define SOFTI2C_BIT_SDA PC5
    24. # define SOFTI2C_BIT_INTRQ PC7
    25. -# define SOFTI2C_DELAY 6
    26. +#else
    27. +
    28. +# define SOFTI2C_PORT PORTA
    29. +# define SOFTI2C_PIN PINA
    30. +# define SOFTI2C_DDR DDRA
    31. +# define SOFTI2C_BIT_SCL PA6
    32. +# define SOFTI2C_BIT_SDA PA7
    33. +# define SOFTI2C_BIT_INTRQ PA5
    34. +
    35. +#endif
    36. +
    37. +# define SOFTI2C_DELAY 6
    38. #elif CONFIG_HARDWARE_VARIANT == 4
    39. /* ---------- Hardware configuration: uIEC ---------- */
    Alles anzeigen

    und hier eine config

    Quellcode

    1. # This may not look like it, but it's a -*- makefile -*-
    2. #
    3. # sd2iec - SD/MMC to Commodore serial bus interface/controller
    4. # Copyright (C) 2007-2010 Ingo Korb <ingo@akana.de>
    5. #
    6. # Inspiration and low-level SD/MMC access based on code from MMC2IEC
    7. # by Lars Pontoppidan et al., see sdcard.c|h and config.h.
    8. #
    9. # FAT filesystem access based on code from ChaN, see tff.c|h.
    10. #
    11. # This program is free software; you can redistribute it and/or modify
    12. # it under the terms of the GNU General Public License as published by
    13. # the Free Software Foundation; version 2 of the License only.
    14. #
    15. # This program is distributed in the hope that it will be useful,
    16. # but WITHOUT ANY WARRANTY; without even the implied warranty of
    17. # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    18. # GNU General Public License for more details.
    19. #
    20. # You should have received a copy of the GNU General Public License
    21. # along with this program; if not, write to the Free Software
    22. # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
    23. #
    24. # config-larsp: sd2iec configuration for SD2IEC evo2 from 16xEight
    25. #
    26. #
    27. # This file is included in the main sd2iec Makefile and also parsed
    28. # into autoconf.h.
    29. CONFIG_ARCH=avr
    30. CONFIG_MCU=atmega1284p
    31. CONFIG_LINKER_RELAX=y
    32. CONFIG_MCU_FREQ=8000000
    33. CONFIG_BOOTLOADER=y
    34. CONFIG_BOOT_DEVID=0x5053524c
    35. CONFIG_COMMAND_CHANNEL_DUMP=y
    36. # In case someone added a crystal to his board
    37. CONFIG_LOADER_TURBODISK=y
    38. CONFIG_LOADER_FC3=y
    39. CONFIG_LOADER_DREAMLOAD=y
    40. CONFIG_LOADER_ULOAD3=y
    41. CONFIG_LOADER_GIJOE=y
    42. CONFIG_LOADER_EPYXCART=y
    43. CONFIG_LOADER_GEOS=y
    44. CONFIG_LOADER_WHEELS=y
    45. CONFIG_LOADER_NIPPON=y
    46. CONFIG_LOADER_AR6=y
    47. CONFIG_LOADER_ELOAD1=y
    48. CONFIG_LOADER_MMZAK=y
    49. CONFIG_HARDWARE_VARIANT=10
    50. CONFIG_HARDWARE_NAME=mmc2iec
    51. CONFIG_SD_AUTO_RETRIES=10
    52. CONFIG_SD_DATACRC=y
    53. CONFIG_ERROR_BUFFER_SIZE=46
    54. CONFIG_COMMAND_BUFFER_SIZE=120
    55. CONFIG_BUFFER_COUNT=6
    56. CONFIG_EEPROM_SIZE=512
    57. CONFIG_EEPROM_OFFSET=512
    58. CONFIG_MAX_PARTITIONS=2
    59. CONFIG_RTC_DSRTC=y
    60. CONFIG_REMOTE_DISPLAY=n
    61. CONFIG_DISPLAY_BUFFER_SIZE=40
    62. CONFIG_LCD_DISPLAY=n
    63. CONFIG_UART_DEBUG=n
    64. CONFIG_UART_BAUDRATE=19200
    65. CONFIG_UART_BUF_SHIFT=8
    66. CONFIG_HAVE_IEC=y
    67. CONFIG_M2I=y
    68. CONFIG_P00CACHE=y
    69. CONFIG_P00CACHE_SIZE=12000
    70. CONFIG_HAVE_EEPROMFS=y
    Alles anzeigen
    damit bekommt man Evo2 support mit RTC aber ohne display in die aktuelle git version.

    Unseen: hat das eine chance drauf, dass du es uebernimmst?
  • everslick schrieb:

    Unseen: hat das eine chance drauf, dass du es uebernimmst?
    Als neue Hardwarevariante mit eigener Bootloader-ID ja, aber nicht als Änderung der bisherigen larsp-Konfiguration - das würde den RTC-Support auf schon existierenden Platinen kaputtmachen.

    Die Soft-I2C-Routinen so umbiegen, dass sie dynamisch auf einen anderen Port umkonfigurierbar sind würde deren Code vermutlich zu sehr aufblasen: Bit Set/Clear auf feste Ports geht mit jeweils einem Befehl, wenn der Port dynamisch ist wird daraus eine Sequenz aus Lesen/Modifizieren/Schreiben (was auch doof ist, wenn man im Interrupt ebenfalls Port-Schreibzugriffe machen will)

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • ok, das ginge dann praktisch nur fuer leute, die sich den bootloader neu flashen koennen (braucht man ISP programmer nehm ich an). und wir nennen das dann einfach Evo2open oder so. wenn 16xEight halbwegs seine sinne beisammen hat, wird er ja seine platinen zukuenftig mit der neuen bootloader ID ausliefern.