de M4x1m3 » 30 Avr 2021, 14:27
Après avoir regardé dans les détails le repo Delta, avec son implémentation external, je pense qu'il est possible soi :
- De passer tout à external v2, et de réimplementer certaines fonctions dans KhiCAS (mais ça impliquerais de se passer d'une fonctionnalité, plus de détails après)
- De faire une 3e version de l'API external, uniformisée, qui serait la même dans delta et Omega.
Je pense que la première solution est largement faisable :
- Code: Tout sélectionner
(void (*)(void)) numworks_draw_string, // Présent dans External V2
(void (*)(void)) numworks_draw_string_small, // Présent dans External V2
(void (*)(void)) numworks_set_pixel, // Présent dans External V2
(void (*)(void)) numworks_fill_rect, // Présent dans External V2
(void (*)(void)) numworks_get_pixel, // Présent dans External V2
(void (*)(void)) numworks_hide_graph, // Semble être utilisé car interraction avec l'env mpy Epsilon, je ne comprends pas pourquoi (surement réimplémentable)
(void (*)(void)) numworks_wait_1ms, // Implémentable (sleep(1))
(void (*)(void)) waitforvblank, // Présent dans External V2
(void (*)(void)) statuslinemsg, // Implémentable avec les fonctions d'external V2 (d'après le code sur gh)
(void (*)(void)) statusline, // Implémentable avec les fonctions d'external V2 (d'après le code sur gh)
(void (*)(void)) getkey, // Un peu plus complexe (car USB), nécessite surement un compromis / une 3e version d'external
(void (*)(void)) GetKey, // Duplicata de la fonction précédente
(void (*)(void)) alphawasactive, // Possiblement implémentable (faire un driver clavier dans khicas à partir de external_scanKey ?)
(void (*)(void)) lock_alpha, // Possiblement implémentable (faire un driver clavier dans khicas à partir de external_scanKey ?)
(void (*)(void)) reset_kbd, // Possiblement implémentable (faire un driver clavier dans khicas à partir de external_scanKey ?)
(void (*)(void)) back_key_pressed, // Possiblement implémentable (faire un driver clavier dans khicas à partir de external_scanKey ?)
(void (*)(void)) enable_back_interrupt, // Semble être utilisé car interraction avec l'env mpy Epsilon, je ne comprends pas pourquoi (surement réimplémentable)?
(void (*)(void)) disable_back_interrupt, // Semble être utilisé car interraction avec l'env mpy Epsilon, je ne comprends pas pourquoi (surement réimplémentable)
(void (*)(void)) os_set_angle_unit, // Impossible sans révision de l'API / grosse magie noire
(void (*)(void)) os_get_angle_unit, // Impossible sans révision de l'API / grosse magie noire
(void (*)(void)) os_file_browser, // Implémentable
(void (*)(void)) file_exists, // Présent dans External V2
(void (*)(void)) erase_file, // Présent dans External V2
(void (*)(void)) read_file, // Présent dans External V2
(void (*)(void)) write_file, // Présent dans External V2
(void (*)(void)) mp_hal_input, // Semble être utilisé car interraction avec l'env mpy Epsilon, je ne comprends pas pourquoi (surement réimplémentable)
Le compromis est donc dans le getangleunit et setangleunit (à voir s'il est possible de s'en passer, sinon on peut designer une manière plus large d'accéder aux settings de poincaré), et dans la gestion de l'USB (il est toujours possible d’interagir avec le HW en bas niveau depuis external, mais ce n'est sûrement pas une bonne solution, on a un HAL pour ça). À toi de voir ce qui t'irais vraiment pour KhiCAS, savoir si on fait une V3 external ou si on peut juste réimplémenter les fonctions implémentables dans khicas au lieu de les avoir dans l'API.
Si une V3 d'External devrais être faite, je pense qu'il faudrait vraiment essayer de faire ça proprement pour ne plus jamais avoir à y toucher.
"Regression testing"? What's that? If it compiles, it is good, if it boots up it is perfect.
