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).
Nie doczekałem się na rozwiązanie problemu przez support Kazam, więc postanowiłem dać radę sam ;).
Postanowiłem zrobić to najprościej jak się da, bez wgrywania nieoficjalnych ROM-ów itp. Niestety trzeba telefon zrootować. na szczęście z użyciem Kingo Root jest to łatwe.
Przełączamy telefon do trybu przechowywania plików (dotknij aby skopiować pliki w powiadomieniu, po podłączeniu do laptopa) i tworzymy w katalogu głównym karty pamięci telefonu plik: android.hardware.usb.host.xml o zawartości:
<permissions>
<feature name=”android.hardware.usb.host” />
</permissions>
Odłączamy kabel USB.
Podłączamy go ponownie, tym razem już bez klikania w powiadomienie, tylko w trybie debugowania USB i łączymy się z telefonem:
adb shell
su
mount -o remount,rw /system
cp /sdcard/android.hardware.usb.host.xml /etc/permissions/
chmod 777 /etc/permissions/android.hardware.usb.host.xml
mount -o remount,ro /system
I po ponownym uruchomieniu usb-host działa (obie przelotki RS232-USB działają prawidłowo).
Bez powyższego da się np. podłączyć pendrive i skopiować pliki, ale żadnych innych bardziej skomplikowanych urządzeń.
Teraz spokojnie mogę zająć się debugowaniem AspeQt na KitKat i dalszą optymalizacją gui.
Udało mi się nieco zmodyfikować usb-serial-for-android, tak że teraz biblioteka obsługuje sio2pc-usb od Lotharka i Atari8Wareza, a niedługo także Prolific 2303.
Mam juz gotowe sio2pc-usb na PL2303 i jutro mam nadzieję odpalić go z Aspeqt na Androidzie 🙂 . Póki co muszę odespać Mega grill party.
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:
Binarka dla Windows z wymaganymi bibliotekami tutaj.
Udało się znaleźć przyczynę i pliki cas ładują się aż miło:
Dzięki temu zapisy do atr też powinny działać poprawnie. O dwa purge() za daleko i ftdi nie „zdanrzał” zapisać/odczytać danych z portu Atari.
Apk-a w zwyczajowej lokalizacji:
https://github.com/greblus/aspeqt/raw/android/android/apk/aspeqt.apk
QFileDialog w Qt5 na Androidzie jest fatalny. Na szczęście znalazłem minimalistyczny fileselector:
http://www.scorchworks.com/Blog/simple-file-dialog-for-android-applications/
który świetnie się sprawdza w AspeQT:
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:
QAndroidJniObject::callStaticMethod<void>("net/greblus/MyActivity", "runFileChooser", "()V");
Lekko zmodyfikowany plik tutaj.
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:
Ale nic na siłę, wszystko w swoim czasie ;).
Dla zainteresowanych repo na github:
https://github.com/greblus/aspeqt
Apka poniżej (pod tym linkiem wrzucam najnowsze wersje bez uprzedzenia ale w katalogu android/apk/ zachowuje poprzednie, z datą kompilacji):
https://github.com/greblus/aspeqt/blob/android/android/apk/aspeqt.apk
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ć ;).
Niestety chyba na chwilę odpuszczę próby odpalenia Sio2PC-USB na Androidzie bez roota z opensource-owego libftdi. Nauczyłem się obsługiwać JNI w QT5, wszystko niby działa, ale moje zmodyfikowane libusb coś niedomaga. libftdi zwraca error -4 przy próbie otwarcia pliku z wykorzystaniem wydłubanego w Javie (po nadaniu uprawnień) deskrypytora pliku… Może to być wina konfiguracji Antka, a tego bez modyfikacji obrazu systemu nie przeskoczę. Muszę spróbować czegoś innego:
Wracam do sterownika D2XX od FTDI. Ten działa z poziomu Javy na Androidzie zawijając ftdi i libusb w JNI w ładny pakiet Javowy (więc będziemy to zawijać dwa razy ;)), ale przynajmniej da się w nim otworzyć urządzenie. To był mój pierwszy pomysł jak to zrobić: Wywołać API Javowe sterownika przez JNI, wszystko z urządzeniem robić w MainActivity w Javie, a dane współdzielić z QT przez ByteBuffer. Teraz już wiem, że jest to do zrobienia i nie jest to trudne.
Jakby ktoś się zastanawiał, to walczę dalej z portem aspeqt na Androida, a dokładniej z obsługą czipu FTDI na Androidzie. Sterownik ftd2xx od FTDI to totalna porażka (segfault goni segfault) i z tego co widzę nie ma szans na obsługę FTDI za pomocą tego sterownika bezpośrednio z C++, bez roota i modyfikacji obrazu systemu.
Na szczęście jest jeszcze libftdi.
Ale i tutaj nie jest tak różowo. W pierwszej kolejności musiałem skompilować libusb na Antka, potem samo libftdi, a to wszystko, żeby się przekonać, że standardowe libusb nie potrafi otworzyć urządzenia bo nie ma do tego uprawnień. I choćby nie wiem jak kombinować z uprawnieniami w Manifest.xml, nic to nie da.
Jest alternatywne podejście: najpierw z poziomu Javy należy otworzyć urządzenie i uzyskać uprawnienia do usb. Potem przekazać deskryptor pliku urządzenia do libusb. To ponoć działa na delikatnie zmodyfikowanej wersji libusb (mam już ją skompilowaną na Antka).
Mój plan był prosty: z poziomu QT wywołuje klasę Javovą, która otworzy urządzenie i poprosi o uprawnienia, a potem zwróci do QT deskryptor pliku. Plan planem, ale JNI w QAndroidJniObject nie chciało mi działać. Teraz już wiem dlaczego :). Przykład Bogdana Vetry zawierał rozwiązanie problemu w pierwszym komentarzu: plik źródłowy w Javie, umieszczamy w katalogach odpowiadających strukturze pakietu, ale w android/src. Jak pakiet utworzę w android to nie zadziała ;).
Czyli:
1. Tworzymy nowy projekt QT Android.
2. W pliku .pro dodajemy:
QT += core gui androidextras
ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android/
W katalogu projektu dodajemy katalog android/src/net/greblus/MyJavaClass.java:
package net.greblus;
public class MyJavaClass {
public static int fibonacci(int n)
{
if (n < 2)
return n;
return fibonacci(n-1) + fibonacci(n-2);
}
}
i wywołujemy w C++ z QAndroidJniObject w ten sposób:
ret = QAndroidJniObject::callStaticMethod<jint>("net/greblus/MyJavaClass", "fibonacci", "(I)I", n);
Dwa wieczory spędziłem nad tym brakującym src, ale dzięki temu sporo się nauczyłem ;). QT5 to dla mnie w tym momencie toolkit nr 1.
libusb mam już skompilowane, teraz tylko mała modyfikacja libftdi i można próbować z otwieraniem urządzenia z Javy ;).
greblus.pl 