Fajny ten Dart. Jakoś wcześniej nie mogłem się do niego przekonać, ale moje ostatnie eksperymenta z ES6 trochę mi to ułatwiły.
Analizator i system typów robi spore wrażenie. OOP w Dart to chyba najlepsze co do tej pory widziałem – dziedziczenie, interfejsy, klasy i metody abstrakcyjne, mixins, overrides, listy inicjalizacyjne konstruktora, prosta inicjalizacja argumentów nazwanych konstruktora, po prostu trzeba to zobaczyć. Flutter to temat na kilka osobnych wpisów ;), a StatefullWidget mnie zachwycił. Poniżej mój pierwszy eksperyment – kolejne wcielenie apki do sterowania esp8266 za pomocą http request.
Kliknij w obrazek powyżej żeby zobaczyć plik źródłowy.Widać w tym przyszłość i to raczej pozytywną, zarówno dla użytkowników, jak i programistów. A i jeszcze jedno – nie sądziłem, że to kiedyś powiem, ale Visual Studio Code to świetny edytor ;).
Aktualizacja: oficjalnie zaliczam Dart i Flutter do grona zjawisk i technologii, które mnie zafascynowały (patrz strip na górze ;)).
Kliknij w obrazek powyżej żeby zobaczyć plik źródłowy.
i myślę, że ma to spore szanse jako alternatywa do FT232 na Androidzie. Tym bardziej, że Open Accessory Mode nie wymaga żadnych sterowników… Zobaczymy co z tego wyjdzie ;).
Mój Samsung nie ma usb-host ale open accessory mode działa ;). Już prawie… Jeszcze tylko dołożyć TTL level shifter 3.3<->5V i powinno działać.
Aktualizacja:
java.io.IOException: write failed: ENODEV (No such device)
at libcore.io.IoBridge.write(IoBridge.java:455)
at java.io.FileOutputStream.write(FileOutputStream.java:187)
at dji.midware.usb.P3.UsbAccessoryService$1.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)
Jest problem z open accessory mode, nierozwiązany od kilku lat…
Po co posiadaczowi Side AspeQt na Androida? Ano, coraz częściej znajduje jakiś program w necie i aby sobie go odpalić musiałbym iść po laptopa/czytnik kart CF. Nie chce mi się, a nic tak nie cieszy jak odpalenie jakiejś zdobyczy retro, na prawdziwym Atari.
Z AspeQt na Androidzie nie ma tego problemu – tablet albo telefon mam zawsze pod ręką ;). Dodatkowo mogę cieszyć się szybkim SIO (HS index 0) na niezmodyfikowanym Atari 130XE, którego używam na co dzień:
do katalogu z pobranymi z neta skarbami (xex) wrzucamy dwa pliki $boot.bin i picodos.sys stąd.
montujemy katalog w AspeQt:
I bootujemy:
Pikuś załatwia nawet długie nazwy plików 😉 i klawisza Option naduszać nie trzeba.
Wydaje mi się, że ludzie są raczej niechętni do instalowania softu na Androida poza sklepem Google, z tego też powodu pomyślałem: raz kozie śmierć! I założyłem sobie konto w Google Play Store. Od dzisiaj AspeQt jest teraz również dostępny tą pobłogosławioną przez Google drogą.
A oto żywy dowód na prawidłową obsługę usb-host przez Kazam Tornado:
Przy okazji powiększyłem trochę przyciski i jeśli ekran jest mniejszy od 5″ to log jest wyłączony (wyświetla się na pasku statusu), a hbox-y wypełniają cały ekran:
Z małych ważnych zmian: usunąłem orientację poziomą i dzięki temu można sobie wybrać plik do załadowania w Fileselektorze w pionie (więcej się mieści).
Piętnaście emulowanych napędów w AspeQt to było dla mnie zdecydowanie za dużo 🙂 więc „zandroidyzowałem” plik projektu z repo dla Androida i wydzieliłem co androidowe, dzięki czemu mój fork AspeQt dla Antka kompiluje się też pod Windows i pod Linuksem. Obsługa portu odbywa się wtedy przez standardowy moduł serialport-{win32,linux}.cpp. Przy okazji poprawiłem kodowanie znaków, które w AspeQt pod Windows było skopane od dawna:
Musiałem go tylko lekko zmodyfikować, bo na nazwę pliku oczekuję w pętli po stronie Qt (lame, ale brakło mi czasu na bardziej eleganckie rozwiązanie) i bez Cancel nie dało się z niej wyskoczyć:
QAndroidJniObject::callStaticMethod<void>("net/greblus/MyActivity", "runFileChooser", "()V");
QString fileName = NULL;
do
{
QAndroidJniObject jFileName = QAndroidJniObject::getStaticObjectField<jstring>("net/greblus/MyActivity", "m_chosen");
fileName = jFileName.toString();
if (fileName == "Cancelled") {fileName.clear(); break;}
if (fileName == "None") QThread::yieldCurrentThread();
}
while (fileName == "None");
A w Javie, cały widz polega na tym, że MyActivity jest singletonem i niestatyczne metody (jak w FileChooser) trzeba wołać w wątku UI Androida z instancji singletona:
public class MyActivity extends QtActivity
{
...
public static MyActivity s_activity = null;
...
public void onCreate(Bundle savedInstanceState)
{
s_activity = this;
}
...
}
public static void runFileChooser() {
m_chosen = "None";
MyActivity.s_activity.runOnUiThread( new FileChooser() );
}
i wtedy można z C++ wywołać QAndroidJNIObject tak:
Update: AspeQT na Androida jest dostępny w Google Play.
Jak niektórzy czytelnicy atarowych forów pewnie zauważyli, udało się. AspeQt działa na moich „Antkach” (4.2.2 Jelly Bean i 4.4.2 Kitkat).
Nie obyło się bez przygód. Z obsługą Kitkata miałem problem wynikający z dziwnego podejścia producentów lub ich nieświadomości: dostałem ostatnio od operatora jako nowy klient, bardzo fajny telefon: Kazam Tornado 348. Pod względem jakość/cena, polecam każdemu. Okazało się jednak, że tenże Kazam obsługuje OTG, czyli mogę sobie podłączyć np. pendrive, ale już USB Host na nim nie działa jak trzeba (pewnie jest nieskonfigurowany, a ja go rootować nie mam zamiaru). I cały czas, o ja głupi, myślałem, że to wina sterownika ftd2xx od FTDI, lub też zmian w KitKacie związanych z obsługą tzw. BroadcastReceiverów.
Jak widać powyżej na zupełnie budżetowym Kazam 345, wszystko śmiga aż miło (swoją drogą na prawdę fajny telefon, ale jakościowo Tornado vs Thunder dzieli ogromna przepaść). Support Kazam obiecał zająć się tematem. Może spodobało im się Atari…
Piszę to dlatego, że użytkownicy powinni się buntować. Dlaczego jeżeli sprzętowo coś jest dostępne, celowo pozbawiać użytkownika możliwości korzystania z tego? Bo co? Bo podłączy sobie przez USB klawiaturę/głośniki/kamerę dowolnego producenta? Paradoksalnie, tanie produkty, jak np. mój Lark FreeMe X2 nie mają z tym problemu. Ale już np. Samsung S5 mini, którego mam z pracy USB nie obsługuje wcale. To nic, że kosztuje krocie…
Przed AspeQT na Androidzie jeszcze daleka droga:
Muszę poprawić GUI, żeby dało się go obsłużyć wygodnie i na małym i na dużym ekranie.
Okno wyboru pliku i katalogu to w Qt5 na Androida jakaś masakra. Trzeba będzie poeksperymentować z dostępnymi natywnymi bibliotekami, które tą funkcjonalność oferują i obsłużyć to przez JNI.
Kontrola przepływu i prędkość transmisji, tego póki co się najbardziej obawiam. Póki co ustawiam FT_FLOW_NONE i prędkość na 19200. DSR nie chce działać, a po ustawieniu prędkości powyżej 19200 bez kontroli przepływu skutkuje odczytem bzdurnych danych.
1. Współdzielenie danych między Javą a Qt5 chyba mam opanowane:
W Javie to wygląda np. tak:
public ByteBuffer bbuf = ByteBuffer.allocateDirect(10);
public byte b[] = new byte [] {1, 1, 2, 3, 5, 8, 13, 21, 34, 55};
public static native void sendBufAddr(ByteBuffer buf);
// natywna funkcja w C++ do której przekazujemy adres bufora
// dane z bufora pakujemy do ByteBuffera w ten sposób:
bbuf.put(b);
// i wysyłamy adres do funkcji w C++
sendBufAddr(bbuf);
A funkcja w C++ w wersji minimalistycznej w QT5 wygląda tak:
extern "C" {
JNIEXPORT void JNICALL
Java_net_greblus_MyActivity_sendBufAddr(JNIEnv *env,
jobject, jobject buf)
{
jbyte *bbuf = (jbyte *)env->GetDirectBufferAddress(buf);
// i możemy robić z danymi w bbuf[] co chcemy
}
}
2. Pakiet jar ze sterownikiem do FTDI działa w Qt5 w MainActivity, więc wszystkie elementy układanki zaczynają do siebie pasować ;).
greblus.pl 