Moduł Szyfrowania USB

[H1M4W4R1]

Streszczenie

Co to za projekt? - Jest to sprzętowy moduł szyfrowania USB. Jego wydajność szczytowa to ok. 600kB/s (nie licząc przesyłu danych). W momencie przesyłu wydajność szczytowa spada do ok. 150-200kB/s. Jego interesującą zaletą jest możliwość pracy strumieniowej (np. możliwość szyfrowania transmisji RF np. LoRa czy sygnału wideo (w tym przypadku należałoby zastosować znacznie wydajniejszy MCU)). Wykorzystuje on mikrokontroler z rodziny STM32 wyposażony w USB FS PHY działające jako USB CDC.

Niniejszy artykuł opisuje proces powstawania tego projektu - od pomysłu do sprawnego urządzenia z API (oraz napotkane problemy).

Parametry techniczne

• Procesor: STM32 L432 KBU6 (80MHz)
• Napięcie zasilania: 5V (USB)
• Koszt wykonania: 10-40 PLN /szt. (100-5szt.)
• Szybkość szyfrowania (używając MCU): 150-200kB/s

Przydatne linki

Płytka i schemat, Firmware, API (C#), Dokumentacja (PDF)

Model obudowy jest w załącznikach do schematu i płytki. Projektowany był pod PCB Rev.1

Geneza powstania

Moduł powstał jako podręczne urządzenie do szyfrowania "sprzętowego" plików (głównie 100-200kB). Rozwiązania programowe są dość niebezpieczne, gdyż łatwo przechwycić hasło zwykłym keyloggerem. Więc technicznie wystarczy zwykły trojan, by haker mógł przechwycić plik i go zdeszyfrować. W związku z tym powstało rozwiązanie, które widać na załączonym obrazku.

Początki

Zacznijmy od słowa wstępu: przed rozpoczęciem tego projektu nie wiedziałem nic o elektronice poza prawami Ohma i Kirchoffa (fizyka).

Na początku pojawił się problem wyboru algorytmu - RSA czy AES są dość zasobożerne... trzeba znaleźć alternatywne rozwiązanie. Padło na VMPC autorstwa Bartosza Żółtaka, jeden z wydajniejszych a zarazem bezpiecznych algorytmów.

Następnie urządzenie zostało wykonane na płytce Arduino Nano (v3, new bootloader), aczkolwiek jego szybkość była niezbyt piorunująca. Powiem, że da się wykonać podobne rozwiązanie na ATMegach / ATTiny, jednakowoż nie można oczekiwać kosmicznych wydajności.

Potem natrafiłem na STM i ich program wsparcia start-upów. Jako, że posiadam swoją firmę chętnie skorzystałem z tej oferty. Za darmo otrzymałem dwie płytki Nucleo32 oraz programator STLinkv3

Dla studentów alternatywnie można skorzystać z wsparcia studenckiego.

Co z tym STM?

Mając już płytki Nucleo spróbowałem napisać program, który szyfruje dane odebrane z magistrali UART po czym zwraca je ponownie na tą magistralę. Działał dobrze, aczkolwiek 115.2kB/s to jednak dość wolny transfer.

Powstało więc pytanie: co wybrać SPI czy USB. SPI jest dużo łatwiejsze w implementacji i posiada większą wydajność jeżeli chodzi o przesył, aczkolwiek jest też bardziej podatne na błędy. Stąd wybór padł na USB, które jest zarazem bardziej uniwersalne.

Blue Pill / Black Pill

Jako, że moje Nucleo32 nie posiadały wsparcia USB poszedłem w stronę Blue/Black Pilla. Niestety, wszystkie zakupione modele nie lubiły się z moim komputerem i zwracały błędy enumeracji. Po około dwóch tygodniach zrezygnowałem z męczenia się z "Pastylami" i zacząłem szukać alternatywnego rozwiązania.

Co dalej?

No cóż... mamy problem - płytki nie chcą enumerować USB... a co gdyby tak zaprojektować własną płytkę? No dobra... spróbujmy...

Rozpoczęła się wojna z wyborem EDA - EasyEDA, Eagle, Altium Designer, CircuitStudio, KiCad... ostatecznie wypadło na to pierwsze ze względu na wygodny dostęp do JLCPCB ale to tylko kwestia gustu.

Teraz przydałoby się nauczyć jak zaprojektować płytkę z mikrokontrolerem... tutaj wypadło na sprawdzone rozwiązanie - YouTube. Gdyby ktoś był kiedyś zainteresowany projektowaniem PCB podrzucę też link. Bardzo dobrze tłumaczy swoje projekty, a na ich podstawie (no i oczywiście dokumentacji producentów poszczególnych podzespołów) zaprojektowanie płytki to banał.

Więc projekt jest gotowy?

W ten sposób miałem już projekt płytki. Jego wygląd można sprawdzić tutaj. (Revision 1). Zamówiłem złożone płyki z Assembly Service by JLCPCB. Jest tam parę zbędnych komponentów usuniętych w Revision 2.

Po jakichś dwóch tygodniach czekania (Nowy Rok) dostałem paczkę z DHL (oczywiście trzeba było opłacić VAT, ale to mniejszy problem). Więc mamy płytki...

Firmware?

Mamy płytki - czas zacząć tworzyć firmware pod nie. Napisanie pierwszej wersji zajęło ok. 7 dni. Posiadała wyłącznie podstawowe funkcjonalności modułu - inicjacja szyfrowania, wybór hasła czy szyfrowanie sekwencyjne, aczkolwiek działała i to było ważne. Czas było napisać API by przetestować sprawność.

API...

API napisałem w ok. 1 dzień (jednak C# to moja domena) no i nadchodzi chwila testu - czy urządzenie działa. A tu nagle zonk... Działa ale wolniej niż Arduino. Czemu?

Okazało się, że problem leży w sterowniku USB CDC Windowsa. Trzeba wykonać cache wszystkich danych do wysyłki po czym dopiero przesłać je na port - w przypadku wysyłania pojedynczych bajtów powstaje overhead wynikający z ECC (CRC) wbudowanego w protokół USB. Dobra poprawiliśmy API... I jaki wynik? 130kB/s. Nie jest źle.

Efekt: Proste API do używania

 // Connect to device at specific port
var module = EncryptionModule.Connect("COM8");

// Set password for VMPC
module.SetPassword("test");

// Initialize VMPC
module.InitializeCipher();

// Encrypt sequence
var encrypted = module.EncryptSequence("test");

Ulepszenia Firmware

Następnie trzeba było ulepszyć firmware. Powstała wersja z "unsafe USB", która zwracała informację o pozytywnym przyjęciu pakietu zanim ten został przetworzony. Działała ona bardzo dobrze, aczkolwiek należało mieć na uwadze, że mogła wpływać negatywnie na odbieranie danych. Stąd pod koniec stycznia powstała nowa wersja sterownika USB z wbudowanym cache'ingiem danych i przetwarzaniem ich w main loop.

Wynik?

Moduł szyfrowania sprzętowego USB, który bez problemu mieści się w kieszeni, a zarazem zapewnia dość duże bezpieczeństwo danych.

Wnioski?

• STM oferuje przyjazny program dla start-upów lub studentów (służą też doradztwem w kwestii doboru płytek do poszczególnych projektów)
• Należy uważać kupując Black/Blue Pill'e - często lubią mieć problemy z enumeracją USB
• Projektowanie płytek PCB nie jest wcale trudne, wystarczy umieć czytać ze zrozumieniem i obejrzeć parę poradników na YT
• Tworząc API dla urządzenia CDC w Windowsie trzeba pamiętać, by wysyłać wszystkie dane naraz (inaczej dane będą wysyłane pojedynczo, co wpłynie na wydajność)
• W dwa miesiące można bez żadnej wiedzy elektronicznej zaprojektować działające urządzenie

Porady?

• Nie przecinaj ścieżek USB innymi sygnałami. Może to skończyć się błędami enumeracji.
• Jeżeli wykonujesz prototyp nie oszczędzaj na punktach testowych - pomogą ci łatwo zdiagnozować błędy i ew. wpiąć się "na krótko"
• Do diagnozowania pakietów USB polecam BugBlat miniSniffer (mój akurat zakupiłem we francuskim https://lab401.com/). Urządzenie działa bardzo dobrze, uwaga na linuxy - soft linuxowy wymaga nieoficjalnej wersji wxWidgets.
• Cyna Sn42Bi58 jest bardzo dobra do lutowania... o ile lutownica może pracować w tak niskich temperaturach (moja np. ma min. 200 stopni, aczkolwiek to nie przeszkadza w lutowaniu)

Możliwości?

• Jak wynika z wcześniejszego opisu urządzenie bez problemu można przerobić na UART, co pozwala podłączyć je do dowolnego mikrokontrolera (praktycznie każdy posiada przynajmniej jedną magistralę UART, stąd istnieje możliwość wykorzystywania podobnego rozwiązania praktycznie w każdym zastosowaniu IoT)

Ostateczny kosztorys projektu:

• STM32 Nucleo x2 + STLink v3 - 0 PLN
• STM32 Pill Boards - ~50 PLN
• Płytki prototypowe (incl. montaż, VAT) - ~250 PLN
• Koszty druku obudowy: ~ 5 PLN / szt (15 PLN)
• BugBlat miniSniffer: ~300 PLN

Razem: 605 PLN

Pytania / sugestie:

Wiem, iż ta płytka nie jest idealna, aczkolwiek działa  Więcej do szczęścia nie jest potrzebne (nie posiadam na stanie analizatora widma / sond by przetestować ją pod kątem EMI, aczkolwiek szacuję, iż raczej powinna mieścić się w normach)

W przypadku pytań i sugestii jestem otwarty na propozycje. Sporo dodatkowych informacji można znaleźć na GitHubie  [https://github.com/H1M4W4R1/Encryption-Module]

P.S.

Te urządzenie jest bezpieczne - uwzględniając bezpieczne hasło to ilość kluczy do sprawdzenia to (hasło litery, cyfry, znaki specjalne, keyboard only, en): 92^n * 256^64, gdzie 92 - możliwe znaki hasła, n - długość hasła (unikalnej sekwencji znaków w haśle), 256 - bajt :D, 64 - długość wektora zapisanego w pamięci FLASH urządzenia.

 

Edytowano Luty 2, 2021 przez H1M4W4R1
usunięcie nadmiarowego zdjęcia

[Treker (Damian Szymański)]

@H1M4W4R1 witam na forum i dziękuję za opis oryginalnego DIY. Czegoś takiego chyba jeszcze u nas nie było

[Zealota]

44 minuty temu, H1M4W4R1 napisał:

Blue Pill / Black Pill

Jako, że moje Nucleo32 nie posiadały wsparcia USB poszedłem w stronę Blue/Black Pilla. Niestety, wszystkie zakupione modele nie lubiły się z moim komputerem i zwracały błędy enumeracji. Po około dwóch tygodniach zrezygnowałem z męczenia się z "Pastylami" i zacząłem szukać alternatywnego rozwiązania.

Być może miałeś wersje z rezystorem 10k zamiast 1.5k dla vusb.

[H1M4W4R1]

2 godziny temu, Zealota napisał:

Być może miałeś wersje z rezystorem 10k zamiast 1.5k dla vusb.

152, więc raczej obstawiałbym niskiej jakości rezonator kwarcowy...

Raspi Pico

Aktualnie czekam na moje RasPico (Raspberry Pi Pico), podobno mają 133MHz i dwa rdzenie - wtedy mógłbym wyrzucić USB na jeden rdzeń, a algorytm na drugi rdzeń, więc urządzenie w teorii mogłoby osiągnąć pełną przepustowość USB Full Speed (syntetyczne szyfrowanie na STM32 wykazywało wynik ok. 600-800kB/s przy 80MHz). A zarazem byłoby taniej  Low Level USB (RasPico) MultiCore

Upgrade

W międzyczasie bawię się z upgradem tego urządzenia, by mogło przechowywać w swojej pamięci zaszyfrowane hasła (PCB Revision 3, które nie jest jeszcze publicznie dostępne), aczkolwiek raczej testy na Pico dostaną wyższy priorytet... (P.S. nowa płytka też jest kompatybilna w 100% z starym firmware)

Praktycznie to jest to samo, tylko doszła pamięć SPI flash z rezystorami 22R w celu redukcji ewentualnych zakłóceń. Ta wielka płachta czystej płytki jest tylko by urządzenie dobrze siedziało w obudowie, tam będzie wlutowane złącze kątowe SWD+SWO.

A i po zamówieniu płytek poprawiłem te ścieżki SWD i są bliżej... Tak to jest jak się projektuje płytkę przysypiając...

Z dodatkowych rad

• Jeżeli używacie USB Full Speed, to naprawdę praktycznie nie musicie się przejmować impedancją... zwykle będzie działać. Jeżeli stosujecie bardzo krótkie ścieżki (rzędu 0.5mm od wtyku do MCU) to USB zwykle dobrze działa. (NIE STOSOWAĆ DO USB HS i SS, ANI DŁUGICH ŚCIEŻEK 1.5cm+)
• Dobrym rozwiązaniem jest umieszczenie rezystorów 0R na ścieżkach USB - zawsze można je podmienić na 22R, jak coś nie działa i często to wystarczy by naprawić całkiem sporą ilość problemów z enumeracją. (Czasem stosuje się 20R, ale 22R łatwiej dostać)
• Uważajcie na umieszczanie kondensatorów przy mikrokontrolerze - zwykle umieszczajcie je jako pierwsze, gdyż inaczej wasze MCU może nawet się nie zbootować do DFU
• STM32 obsługuje USB DMA w sposób zautomatyzowany, nie trzeba się tym przejmować
• Jeżeli macie złe napięcie na zegarze pamięci W25QxxJVSIG to prawdopodobnie macie ustawioną złą ilość bitów w mikrokontrolerze (np. Motorola 4bit zamiast Motorola 8bit)... Taki dziwny mankament mi się przytrafił

Zobaczymy jak pójdzie z Pico... postaram się wrzucić update jak tylko się z nim uporam.

Edytowano Styczeń 31, 2021 przez H1M4W4R1
SPI nie QSPI...

[MR1979]

Świetny projekt i co najważniejsze przeprowadzony od pomysłu do gotowego urządzenia w estetycznej obudowie! Gratuluję!

Czy po wpisaniu błędnego hasła urządzenie zwraca błąd czy odszyfrowuje dane błędnym kluczem?

Pozdr!

[H1M4W4R1]

9 godzin temu, MR1979 napisał:

Świetny projekt i co najważniejsze przeprowadzony od pomysłu do gotowego urządzenia w estetycznej obudowie! Gratuluję!

Czy po wpisaniu błędnego hasła urządzenie zwraca błąd czy odszyfrowuje dane błędnym kluczem?

Pozdr!

Niestety urządzenie nie ma w danych sumy kontrolnej, wiec deszyfruje dane, tylko wynik operacji jest taki jakby zostały zaszyfrowane dwoma różnymi hasłami. Teoretycznie implementacja CRC do szyfrowania nie jest trudna, ale należy mieć na uwadze, że VMPC jest szyfrem strumieniowym i symetrycznym, więc dodanie CRC jest potencjalnym ryzykiem łatwiejszego deszyfrowania. 
Aktualne API jest bardziej zorientowane low-level, więc technicznie na poziomie high-level wystarczy zsumować bajty pliku do uint32 i dodać na końcu sekwencji po czym podczas deszyfrowania porównać wynik sumy CRC i zdeszyfrowanych bajtów by sprawdzić czy hasło było poprawne.

Ważne jest też to, by dane na początku pliku w miarę możliwości się nie powtarzały, o tym można przeczytać więcej w dokumentacji VMPC.

Update

Dodałem sumę kontrolną w postaci komendy 0x10.

Na załączonym obrazku pierwsze 4B w linijce to zaszyfrowane dane przesłane do urządzenia, pozostałe 8B to suma kontrolna. Urządzenie posiada dwie 32-bitowe sumy - jedna sumuje dane wejściowe, druga wyjściowe, wystarczy zamienić je miejscami, by sprawdzić poprawność deszyfrowania względem sumy uzyskanej z szyfrowania. Suma nie jest elementem, który jest szyfrowany, więc korzystanie z niej pozwala na łatwiejsze złamanie klucza... ale jednak nadal to będzie dość długi czas

Update jest na Git

Edytowano Luty 1, 2021 przez H1M4W4R1
Update, cmd_0x10.h

[FlyingDutch]

Cześć,

projekt fajny, tylko nie rozumiem dlaczego nie wybrałaś wersji MCU (STM32 serii L4 lub F4) ze sprzętowym wsparciem dla AES'a z 265 bitowym kluczem (akcelerator) i sum kontrolnych (np. MD5). Mógłbyś wtedy osiągnąć dużo większe prędkości szyfrowania (no i masz gotowe API - bibliotekę kryptograficzną gotową). Patrz link:

https://www.st.com/content/ccc/resource/training/technical/product_training/8b/70/87/cd/04/6e/41/ee/STM32L4_Security_AES.pdf/files/STM32L4_Security_AES.pdf/jcr:content/translations/en.STM32L4_Security_AES.pdf

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiG-Kncq8juAhUC-hQKHTKEB0UQFjAAegQIARAC&url=https%3A%2F%2Fwww.st.com%2Fresource%2Fen%2Fuser_manual%2Fdm00215061-stm32-crypto-library-stmicroelectronics.pdf&usg=AOvVaw0s1IaDcCcsGxa6ndE6YPhG

Pozdrawiam

 

[H1M4W4R1]

@FlyingDutch

Po pierwsze chciałem zachować kompatybilność z aktualnym systemem, którego używałem. Technicznie to urządzenie ze sprzętową akceleracją może się bujać do 40MB/s a w ASIC pewnie parę GB/s

Po drugie chciałem spróbować czegoś nietypowego - Arduino np. nie ma wsparcia dla AES no i tutaj ląduje problem. Dodatkowo AES jest znacznie bardziej podatny na ataki niż VMPC. No i mamy wynik.

AES / VMPC według kryptoanaliz VMPC jest bezpieczniejsze i uruchomisz to nawet na MCU z 1980 roku

[MR1979]

@H1M4W4R1 Kilka uwag:

1. CRC nie jest algorytmem przeznaczonym do sprawdzania poprawności hasła. CRC służy do zapewnienia pewności transmisji danych (i ewentualnej korekcji błędów). Do sprawdzania poprawności hasła służą algorytmy wykorzystujące funkcje skrótu takie jak SHA. Najbardziej popularnym algorytmem do sprawdzania poprawności hasła jest BCRYPT (wykorzystuje kombinacje funkci skrótu SHA oraz losowo generowany ciąg znaków, tzw. sól).

2. Co do szyfrowania to skupiłbym się jednak na AES. Przemawia za tym kilka powodów. Po pierwsze AES jest powszechnie używanym standardem i był/jest poddawany kryptoanalizom przez setki badaczy na całym świecie. Po drugie większość nowoczesnych uC posiada sprzętowe wsparcie dla AES. Nie umiejszam tutaj VMPC, jednak w porównaniu do AES został on poddany zdecydowanie mniejszej liczbie prób i analiz.

3. Nie patrzyłem w twój kod i nie wiem jak generujesz klucz dla VMPC z hasła, ale do tego też są specjalizowane i sprawdzone algorytmy (key derivation algorithms): PKDF1, PKDF2, SCRYPT

4. Zapomnij o Arduino. Do każdego zadania dobiera się odpowiednie narzędzie. Tak jak gwóźdź można wbić kamieniem, zdecydowanie lepiej zrobić to młotkiem, a duże ilości gwoździarką. Arduino nie nadaje się do zadania które chcesz zrobić, bo zawsze będziesz musiał coś poświęcić: albo wydajność, albo bezpieczeństwo. W twoim przypadku potrzebujesz uC ze sprzętowym wsparciem dla funkcji kryptograficznych (wystarczy AES).

5. Jakkolwiek jest to bardzo kuszące, odradzam wymyślanie własnych algorytmów, lub nawet własną implementację istniejących algorytmów kryptograficznych. Jak widzisz powyżej w kryptografii każdy krok jest już dawno opisany odpowiednimi standardami. Większość słabości systemów kryptograficznych pochodzi z nieumiejętnej implementacji algorytmów lub próbie tworzenia własnych. Standardy po to są tworzone i intensywnie badane na podatności żebyś ty później nie musiał wymyślać koła na nowo.

6. Unikaj podejścia "security through obscurity". Nigdy nie opieraj bezpieczeństwa systemu kryptograficznego na tym że jakaś jego część jest ukryta lub trudno dostępna. Dobry system kryptograficzny to taki że pomimo pełnego dostępu do wiadomości zaszyfrowanej, oraz modułu szyfrującego i informacji o tym jak działa, atakujący wciąż nie będzie w stanie go złamać.

7. Na razie unikałbym też RPi Pico. Bazuje na uC RP2040, który nigdzie nie jest jeszcze dostępny jako samodzielny układ który mógłbyś zaimplementować na własnej płytce. Wątpię też że kiedykolwiek pojawi się wersja w na tyle małej obudowie że będzie to praktyczne do zastosowania w urządzeniu USB wielkości pendrive.

Dalej uważam że zrobiłeś bardzo dobry projekt, a powyższe uwagi pozostawiam do rozważenia na wypadek gdybyś chciał go rozwijać w przyszłości.

Pozdrawiam,
Marek

 

Edytowano Luty 1, 2021 przez MR1979

[H1M4W4R1]

@MR1979 

Wróćmy do początku - urządzenie nie powstało docelowo, by zastąpić szyfrowanie standardowymi algorytmami (AES, RSA etc.), których używam w szyfrowaniu danych wrażliwych, a bardziej do szyfrowania plików mniej podatnych na zainteresowanie hakerów np. arkusz techniczny projektu do realizacji (zwykle gier mobilnych) [...oraz by nauczyć się designu PCB / schematic capture]. Stąd zrezygnowałem z AES, a że chciałem też sprawdzić czy Arduino da radę zaszyfrować pliki. Wyszło co wyszło - wyszedł dowód, że nawet potencjalnie słabe MCU jest w stanie szyfrować dane z dość przyzwoitą prędkością - ten moduł po przeniesieniu na UART jest w stanie bez problemu obsługiwać dwukierunkowe szyfrowanie transmisji np. LoRa - tutaj AES CTR z swoją podatnością na duplikację kluczy zbytnio się nie nadaje, za to VMPC jak najbardziej, gdyż był projektowany jako szyfrowanie strumieniowe.

A Pi Pico ma dobre API do nauki USB LL, stąd padło na nie (i zarazem dwa rdzenie, więc dwie pieczenie na jednym ogniu). Jestem z tych osób co nie tworzą, by czegoś używać, tylko tworzą by tworzyć...

Punkt 1 - SHA można używać podczas szyfrowania danych na procesorze w komputerze (wtedy urządzenie służy wyłącznie jako KSA), implementacja SHA by zabrała znaczną ilość mocy obliczeniowej z urządzenia

Punkt 3 - VMPC KSA3

Punkt 5 - to jest oficjalna implementacja VMPC  I gdybyśmy zawsze stosowali się do standardów to byśmy nadal żyli w prehistorii

Punkt 7 - zawsze można wylutować (sarkazm)

Punkt 4 - oczywiście do muchy strzelam z rusznicy a do czołgu z pistoletu... i nie używam gwoździ tylko wszystko idzie na wkręty

[FlyingDutch]

9 minut temu, H1M4W4R1 napisał:

@MR1979 

Wróćmy do początku - urządzenie nie powstało docelowo, by zastąpić szyfrowanie standardowymi algorytmami (AES, RSA etc.), których używam w szyfrowaniu danych wrażliwych, a bardziej do szyfrowania plików mniej podatnych na zainteresowanie hakerów np. arkusz techniczny projektu do realizacji (zwykle gier mobilnych) [...oraz by nauczyć się designu PCB / schematic capture]. Stąd zrezygnowałem z AES, a że chciałem też sprawdzić czy Arduino da radę zaszyfrować pliki.

Cześć,

ale przecież użyłeś STM32 z serii L4 - cytat:

Cytat

Procesor: STM32 L432 KBU6 (80MHz)

Właśnie w tej serii są także modele MCU ze sprzętowym wsparciem dla kryptografi (wspomniany AES). Bardziej chodzi mi nawet o sprawdzoną bibliotekę kryptograficzną z np. algorytmami bezpiecznej wymiany kluczy. Tak jak kolega @MR1979 napisał staram się unikać pisania własnego kodu do kryptografi ze względu na niznaną podatność tego kodu na ataki. Oczywiście w tym projekcie, gdy piszesz to dla siebie do ochrony mniej istotnych plików nie ma to wielkiego znaczenia. Projekt oceniam bardzo dobrze.

Pozdrawiam

[H1M4W4R1]

@FlyingDutch

Okej rozpiszę kroki kolejno:

1. Powstanie pomysłu
2. Prototyp na Arduino Nano
3. Arduino jest dość wolne (wersja lekka algorytmu chodziła max 130kB/s w syntetycznym benchmarku)
4. Szukanie alternatywnych rozwiązań - ATMega? Cypress?
5. Wylądowałem na stronie STM dla wsparcia starupów i studentów
6. Dostałem STM32
7. Przetestowałem na Nucleo G031, wyniki były obiecujące (500kB/s w syntetycznym benchmarku, 64MHz)
8. Plan przerzucenia tego na USB... jednak UART na STM ma limit 115.2kbps
9. Testy na Pill'sach - nieudane
10. Projekt płytki
11. Firmware i testy, dopracowywanie

Stąd padło na STM32 - po prostu "tak wyszło". Pierwsza wersja algorytmu powstała (nie pamiętam dokładnie), ale gdzieś w środku listopada (14-21) 2020 roku i była napisana pod Arduino Nano v3. W skrócie - pierwsza wersja była na Arduino, a że potem trafiłem na STM to "głód wiedzy" chciał sprawdzić jak ten algorytm zachowa się na STM32 - będzie ok. 5-6 razy wydajniejszy.

P.S. Polecam brać poprawkę na to, że często niezbyt dokładnie się wysławiam i zostawiam niedopowiedzenia... 

[jaszczurtd]

Dnia 1.02.2021 o 12:03, MR1979 napisał:

@H1M4W4R1 Kilka uwag:

7. Na razie unikałbym też RPi Pico. Bazuje na uC RP2040, który nigdzie nie jest jeszcze dostępny jako samodzielny układ który mógłbyś zaimplementować na własnej płytce.

 

Doprawdy? https://allegro.pl/oferta/raspberry-pi-rp2040-17988625499

[_LM_]

8 godzin temu, jaszczurtd napisał:

Doprawdy? https://allegro.pl/oferta/raspberry-pi-rp2040-17988625499

Należy się złota łopata (porównaj daty):

https://www.raspberrypi.com/news/raspberry-pi-rp2040-on-sale/

Edytowano 20 lutego przez _LM_

[keram167]

@_LM_ byłeś szybszy . 

@jaszczurtd doprawdy takie to były czasy 5 lat temu, jak @H1M4W4R1 opisał swój projekt .