Re: Heiß, heißer, FujiNet
von tschak909 » Sa 14. Mär 2020, 19:08Status for 2020-03-14:
* @jeffpiep is hard at work implementing the Atari 1020 plotter emulation. This emulation is unique in that the output is not PDF, but an SVG.
* There are a few more testers of ESP32 boards popping up, and bug reports are coming in.
* The TNFS filesystem implementation is accidentally sending back successes when all retries have been exhausted. It comes from an inconsistent mis-match of return values that happened when we ported the code to use the standard Arduino FS API. Whoops.
* In addition, the TNFS retry timings need to be further tuned, as currently there are more retry attempts than there is time for in the SIO timeout allotted by the OS for most disk operations (5 retries, 5000ms, 25 seconds, compared to 15 seconds for the OS.), We need to decrease the time between timeouts, and do more retries. To this end, I have moved timeout values to #define constants in lib/sio/sio.h
* The N: handler is being debugged, lots of work needing to be done there. OPEN works now, after a complete rewrite of the device spec tokenizer. Other operations currently fail due to stack smashing. I need to re-think how buffers are passed between protocol functions. Any insight anyone can offer for this, please check out the code and dip into sio/network* I did write a theory of operation in the wiki, if anyone is interested.
This is the muck of the project, we’ve done the huge flurry of “ain’t it cool?!” demos, and now we’re rolling up our sleeves, and working through the mix of technical debt and functionality testing. Not to mention writing unit tests
-Thom
---
Status für 2020-03-14:
* @jeffpiep arbeitet hart an der Implementierung der Atari 1020 Plotter-Emulation. Diese Emulation ist insofern einzigartig, als die Ausgabe nicht als PDF, sondern als SVG erfolgt.
* Es gibt noch einige weitere Tester von ESP32-Boards, und es kommen Fehlerberichte herein.
* Die TNFS-Dateisystemimplementierung sendet versehentlich Erfolge zurück, wenn alle Wiederholungsversuche erschöpft sind. Das kommt von einer inkonsistenten Fehlanpassung der Rückgabewerte, die passierte, als wir den Code zur Verwendung der Standard-Arduino-FS-API portierten. Hoppla.
* Zusätzlich müssen die TNFS-Wiederholungszeiten weiter abgestimmt werden, da es derzeit mehr Wiederholungsversuche gibt, als in der SIO-Zeitüberschreitung, die vom Betriebssystem für die meisten Plattenoperationen vorgesehen ist (5 Wiederholungsversuche, 5000ms, 25 Sekunden, im Vergleich zu 15 Sekunden für das Betriebssystem). Zu diesem Zweck habe ich die Zeitüberschreitungswerte in #define constants in lib/sio/sio.h verschoben.
* Der N:-Handler wird gerade debuggt, es muss noch viel Arbeit geleistet werden. OPEN funktioniert jetzt, nach einem kompletten Neuschreiben des Tokenizers der Gerätespezifikation. Andere Operationen scheitern derzeit aufgrund von Stack-Zerstörungen. Ich muss neu überdenken, wie die Puffer zwischen den Protokollfunktionen übergeben werden. Jeder, der einen Einblick in diese Problematik geben kann, möge sich bitte den Code anschauen und in sio/network* eintauchen. Ich habe eine Theorie der Funktionsweise im Wiki geschrieben, falls es jemanden interessiert.
Das ist der Dreck des Projekts, wir haben die große Aufregung der "Ist das nicht cool?!"-Demos hinter uns gebracht, und jetzt krempeln wir die Ärmel hoch und arbeiten uns durch die Mischung aus technischer Verschuldung und Funktionstests. Ganz zu schweigen vom Schreiben von Unit-Tests
* @jeffpiep is hard at work implementing the Atari 1020 plotter emulation. This emulation is unique in that the output is not PDF, but an SVG.
* There are a few more testers of ESP32 boards popping up, and bug reports are coming in.
* The TNFS filesystem implementation is accidentally sending back successes when all retries have been exhausted. It comes from an inconsistent mis-match of return values that happened when we ported the code to use the standard Arduino FS API. Whoops.
* In addition, the TNFS retry timings need to be further tuned, as currently there are more retry attempts than there is time for in the SIO timeout allotted by the OS for most disk operations (5 retries, 5000ms, 25 seconds, compared to 15 seconds for the OS.), We need to decrease the time between timeouts, and do more retries. To this end, I have moved timeout values to #define constants in lib/sio/sio.h
* The N: handler is being debugged, lots of work needing to be done there. OPEN works now, after a complete rewrite of the device spec tokenizer. Other operations currently fail due to stack smashing. I need to re-think how buffers are passed between protocol functions. Any insight anyone can offer for this, please check out the code and dip into sio/network* I did write a theory of operation in the wiki, if anyone is interested.
This is the muck of the project, we’ve done the huge flurry of “ain’t it cool?!” demos, and now we’re rolling up our sleeves, and working through the mix of technical debt and functionality testing. Not to mention writing unit tests
-Thom
---
Status für 2020-03-14:
* @jeffpiep arbeitet hart an der Implementierung der Atari 1020 Plotter-Emulation. Diese Emulation ist insofern einzigartig, als die Ausgabe nicht als PDF, sondern als SVG erfolgt.
* Es gibt noch einige weitere Tester von ESP32-Boards, und es kommen Fehlerberichte herein.
* Die TNFS-Dateisystemimplementierung sendet versehentlich Erfolge zurück, wenn alle Wiederholungsversuche erschöpft sind. Das kommt von einer inkonsistenten Fehlanpassung der Rückgabewerte, die passierte, als wir den Code zur Verwendung der Standard-Arduino-FS-API portierten. Hoppla.
* Zusätzlich müssen die TNFS-Wiederholungszeiten weiter abgestimmt werden, da es derzeit mehr Wiederholungsversuche gibt, als in der SIO-Zeitüberschreitung, die vom Betriebssystem für die meisten Plattenoperationen vorgesehen ist (5 Wiederholungsversuche, 5000ms, 25 Sekunden, im Vergleich zu 15 Sekunden für das Betriebssystem). Zu diesem Zweck habe ich die Zeitüberschreitungswerte in #define constants in lib/sio/sio.h verschoben.
* Der N:-Handler wird gerade debuggt, es muss noch viel Arbeit geleistet werden. OPEN funktioniert jetzt, nach einem kompletten Neuschreiben des Tokenizers der Gerätespezifikation. Andere Operationen scheitern derzeit aufgrund von Stack-Zerstörungen. Ich muss neu überdenken, wie die Puffer zwischen den Protokollfunktionen übergeben werden. Jeder, der einen Einblick in diese Problematik geben kann, möge sich bitte den Code anschauen und in sio/network* eintauchen. Ich habe eine Theorie der Funktionsweise im Wiki geschrieben, falls es jemanden interessiert.
Das ist der Dreck des Projekts, wir haben die große Aufregung der "Ist das nicht cool?!"-Demos hinter uns gebracht, und jetzt krempeln wir die Ärmel hoch und arbeiten uns durch die Mischung aus technischer Verschuldung und Funktionstests. Ganz zu schweigen vom Schreiben von Unit-Tests