Dlaczego GitHub nie lubi powrotu karetki?

  Od czasu do czasu zdarza się, że coś pójdzie nie tak, jak planowaliśmy. Każdemu zdarza się jakiś błąd, ale czasem niewiele od nas zależy...

CA80 z "nowym" programem.

Kolega @tapy zgłosił mi, że pliki *.hex pobrane z repozytorium nie są wczytywane przez bootloader. Terminal wyświetla: "Wrong format file." Dlaczego? Przecież u mnie działa!!! Po jakimś czasie dotarł do źródła problemu: okazało się, że GitHub modyfikuje przechowywane tam pliki. W dodatku robi to w perfidny sposób, bo tylko w czasie pobierania repozytorium jako *.zip. W moim komputerze wszystko było w porządku, bo pobierałem moje dane przez GH desktop. Nawet gdy zrobiłem to na innej maszynie, pobrane pliki były takie, jakie wysłałem. Oprogramowanie GitHub-a zamienia kombinację CR-LF na LF. Gdyby to było w zwykłych plikach tekstowych, zauważylibyśmy może błędne formatowanie tekstu i nic poza tym, ale pliki HEX są znormalizowane. Każdy bajt ma tam znaczenie. Plik składa się z rekordów, a każdy rekord zakończony jest znakami CR (0xD) i LF (0xA). Trzynastka (0xD lub po staremu 0DH = 13) przynosi pecha, więc ktoś postanowił ją usunąć... Na szczęście odczytem rekordów w moich programach zajmuje się tylko jedna funkcja, ale należało ją zmodyfikować tak, żeby działała poprawnie z plikami oryginalnymi i "popsutymi". Okazało się to bardzo proste, więc niezwłocznie (zajęło mi to chyba trzy dni) poprawiłem, a raczej dostosowałem kod do zaistniałej sytuacji. Mam nadzieję, że nie zostałem zdalnie obsypany przekleństwami... Gdyby nie kolega, żyłbym nadal w nieświadomości, a problem pojawiłby się w innych miejscach. Myślę, że nie wszyscy byliby tak wyrozumiali. 

Poprawiony kod jest już w repozytoriach:

- dla RC2014

- dla CA80-mini

 

Zielone cyfry trudno sfotografować.

 

Przy okazji sprawdziłem emulowanie klawiatury przez UART. Okazało się, że "terminal" ELWRO144 blokuje pracę emulatora, więc podłączyłem tylko wyświetlacz LED. 

Do wgrywania programów używam Arduino IDE, bo nie umiem inaczej. Programuję AVR-y "na rejestrach", ale nigdy nie robiłem tego w innym środowisku. Nie było mi to dotychczas potrzebne. Poza tym ten sposób wymaga najmniej nakładów - wystarczy dowolne UNO czy NANO do wgrania bootloadera i FTDI232 do programowania. Nie trzeba się przy tym martwić fusebitami...