Перейти к содержанию
    

Как просто перенести С программу на мобильник

Добрый день,

 

Есть носимое устройство, состоящее их 3 модулей 

[1] датчики с кортексом М4 , которые собирают информацию и посылают по SPI примерно 1-2мбит/с на [2]

[2] линукс борда, которая получает данные из [2] производит вычисления, требует около 500МБ оперативки и сколько-то гигабайт для сохранения промежуточных данных и общается с [3] по сокетам

[3] веб интерфейс на жаваскрипте, который общается с [2].

 

Весь софт на [2] написан С, и использует только системные open/read/write для файлов, devspi и сокеты, все остальное - голый С (c C++ вставками), около пары сотен тысяч строк кода. Все компилится на прямую на gcc. Во время работы с процессора снимается около 200МФлопс (хотелось бы и 1ГФлопс, но процессор не тянет).

 

Я хочу с минимальными телодвижениями перенести всю работу с [2] внутрь мобильника, как я понимаю, процессоры современных мобильников с лихвою решат эту задачу и я смогу отказаться от линукс борды. Как я понимаю, SPI надо на usbhid заменить.

 

Вопросы, которые я не понимаю, как решить, подскажите, пожалуйста:

1. на сколько разных современных платформ мне надо это компиллировать, чтобы более-менее охватить все мобильники?

2. стоит ли думать в сторону WebAssembly, или это не подъемная для вебассембли задача и производительность веб ассембли не позволит это решить?

3. какую библиотеку для мобильного приложения надо пользовать, чтобы воспользоваться usbhid и sockets, или надо на что-то другое перейти?

4. чем все это компиллировать? Есть ли, например, кросскомпиллер, чтобы я просто в gcc указал опции, а он скомпилировал бы все это для мобильника или надо что-то куда-то ставить?

 

Спасибо!

 

ИИВ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я сварщик ненастоящий,

но 2,4) может просто собрать в emscripten и посмотреть насколько небыстро получится.

если совсем плохо, то попробовать перекинуть часть вычислений в gpu на glsl.

и обычные сокеты emscripten вроде в вебсокеты как-то оборачивать умеет.

 

про usb на мобилах ничего не подскажу, но заменить его на какой-нибудь wifi/bluetooth/nfc будет имхо куда портабельнее и проще, со стороны телефона.

и если бы данных до сотни кбит/c, а не пара мбит/c, можно было бы вообще через аудио попробовать данные пропихнуть в мобилу :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо большое, _pv!!!

 

Оказалось, что потестировать WebAssembly не так уж и сложно, и, к моему реально большому удивлению, на более-менее мощных мобильниках или на десктопах можно больш 500 МФлопс на нем получить.

 

Положил у себя тестировщик, возможно кому-то будет интересно, сорсы того же Сишника лежат там же рядом.

 

То есть почти все вопросы сняты, только есть желание все-таки испольковать USB соединение, а не WiFi, так как и питается устройство по USB, да и WiFi лишние помехи будет создавать.

 

Скажите, пожалуйста, какой простой интерфейс с SAMD51 через USB на веб интерфейс с жаваскриптом быстро и просто было бы реализовать?

 

Спасибо!

 

ИИВ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, iiv said:

Скажите, пожалуйста, какой простой интерфейс с SAMD51 через USB на веб интерфейс с жаваскриптом быстро и просто было бы реализовать?

в телефоне usb чтобы быстро и просто? для начала попробуйте с айфоном ;)

 

https://github.com/webusb/awesome

не следил особо, но этот webusb на десктопе-то если и как-то поддерживается, то не уверен что включен по умолчанию. на айфонах скорее всего никогда не будет.

если поддерживатся, то пожалуй https://web.dev/serial/ и CDC на устройстве.

а если нет, то может оказаться что придётся SAMD51 хостом для телефона сделать и через какой-нибудь mtp данные отправлять, и потом через file api из браузера читать.  может ли при этом "хост" питаться от "девайса" - вопрос.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо большое, _pv,

 

не думал, что там все так сложно может быть. А если все-таки по беспроводной связи общаться, то, скажите, пожалуйста, как будет правильнее - через те же сокеты с сайта гаджета? А если он по dhcp, то там браузер будет на SSL ругаться, так как подписать можно будет только или самому, или на статическом IP, а это никто делать не будет.

 

PS: гаджет хочется сделать максимально дешевым, и пока если там только SAMD51 без линукса и WiFi, то стоимость компонент и производства получалась 25 бакс и ужасно не хотелось бы эту стоимость увличивать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ну отчасти так череззадно получается от того, что это всё ещё и в веббраузер завёрнуто, так-то в андроиде особо сложностей не должно быть с usb, наверное. но айфоны отпадают (нужны вообще?).

можно разделить, сделать связь с железкой через отдельное приложение, а морду и считалку оставить в "браузере".

 

ну либо прикидываться со стороны МК USB аудио/видео устройством, до этих типов устройств из браузера добраться должно быть проще.

если без проводов, то наверное bluetooth гарнитурой прикинуться.

 

ещё есть Android Open Accessories,

ftdi даже отдельные чипы делал FT311/312 чтобы через USB с андроидом общаться. т.е. это usb host для андроида и uart/i2c/spi для МК.

возможно этот open accessories получше в браузерах поддерживается чем webusb. и из samd51 то же самое, что ft311 делает, изобразить можно.

 

ещё видел где-то вариант с памятью типа NT3H2111 (<1$), которую МК по i2c читать/писать может, а телефон через nfc, но прям из браузера до nfc тоже добраться непросто. да и скорость не особо большая, по аудиошнурку в микрофонный вход ту же сотню кбит/с просунуть можно.

данные непрерывно передаются?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, iiv сказал:

не думал, что там все так сложно может быть. А если все-таки по беспроводной связи общаться, то, скажите, пожалуйста, как будет правильнее - через те же сокеты с сайта гаджета? А если он по dhcp, то там браузер будет на SSL ругаться, так как подписать можно будет только или самому, или на статическом IP, а это никто делать не будет.

Не понял - какая связь между "беспроводной связью" и SSL? И причём тут "браузер"? У вас тут похоже "смешались в кучу- люди, кони..." :wacko2:

Изначально Вы вроде хотели как-то передать поток данных в смартфон? И про защиту данных (шифрование) не было ни слова.

Открыть TCP-порт в телефоне и принимать на него входящие соединения от устройств (без всяких браузеров и SSL) разве нельзя? имхо: это будет самый простой способ. Самый простой и совместимый с разными андроидами/айфонами/etc.  И минимально нагружающий девайсы на МК.

 

2 часа назад, iiv сказал:

PS: гаджет хочется сделать максимально дешевым, и пока если там только SAMD51 без линукса и WiFi, то стоимость компонент и производства получалась 25 бакс и ужасно не хотелось бы эту стоимость увличивать.

Для того чтобы сливать данные куда-то в сеть, WiFi не обязателен. Можно это делать подключив девайсы к роутеру по Ethernet.

Но можно и через WiFi. Самый дешёвый вариант: через ESP8266. Правда не уверен, что он будет успевать окучивать непрерывный поток в 1-2Мб/с.

49 минут назад, _pv сказал:

да и скорость не особо большая, по аудиошнурку в микрофонный вход ту же сотню кбит/с просунуть можно.

Вы тут порядком чисел не ошиблись?? :umnik2:  Вроде как даже лучшие телефонные модемы могли максимум 56Кбит. И то - это не на всякой линии получалось. Требовалась линия с более широкой полосой пропускания чем минимальная стандартная. А в микрофонном входе телефона там всё будет намного хуже. Имхо. Если получится несколько килобит/сек - это будет удача. Да и со сложными методами модуляции покувыркаться вдоволь придётся.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

19 minutes ago, jcxz said:

Не понял - какая связь между "беспроводной связью" и SSL? И причём тут "браузер"? У вас тут похоже "смешались в кучу- люди, кони..." :wacko2:

Изначально Вы вроде хотели как-то передать поток данных в смартфон? И про защиту данных (шифрование) не было ни слова.

Открыть TCP-порт в телефоне и принимать на него входящие соединения от устройств (без всяких браузеров и SSL) разве нельзя? имхо: это будет самый простой способ. Самый простой и совместимый с разными андроидами/айфонами/etc.  И минимально нагружающий девайсы на МК.

Я в этом новичек, поэтому написал, повидимому, задав очень ламерские вопросы.

 

Я пока умею из веб интерфейса по XMLHttpRequest брать или забирать данные, но заметил, что если хост не поддерживает SSL, то мобильники все повально ругаются и не пускают туда или советуют уйти оттуда.

 

Мне действительно надо просто данные с МК перетаскивать на Javascript, который исполняется в веб страничке. Если эти данные как-то можно сразу заслать в WebAssembly, то вообще классно будет.

 

EDIT: очень бы не хотелось бы писать App для смартфона, хотя бы потому, что ни разу это не делал, и нужно писать на Мак, Андроид, кучу разных планшетов, и, до кучи на все десктоповые платформы. Хочется остаться в веб интерфейсе на javascript-html-css + необходимые вычисления на WebAssembly.

 

19 minutes ago, jcxz said:

Открыть TCP-порт в телефоне и принимать на него входящие соединения от устройств (без всяких браузеров и SSL) разве нельзя? имхо: это будет самый простой способ. Самый простой и совместимый с разными андроидами/айфонами/etc.  И минимально нагружающий девайсы на МК.

Скажите, пожалуйста, а можно ли это сделать средствами WebAssembly и Javascript? Если да, вдруг Вам было бы не сложно, или сказать как, или сказать на какие ключевые слова нагуглить, а то сразу не смог найти, вылазит куча всего не по теме.

 

Спасибо!

1 hour ago, _pv said:

ну отчасти так череззадно получается от того, что это всё ещё и в веббраузер завёрнуто

согласен, но зато появляется хоть какая-то совместимость между платформами. У меня нет пока точного понимания кто будет пользователями (если я вообще решусь на эту идею), и, мне хотелось бы сразу сделать платформонезависимую конструкцию - то есть в веб браузере управление и отрисовка, в веб-ассембли - счет, тогда мой гаджет будет полностью платформонезависимым.

1 hour ago, _pv said:

ftdi даже отдельные чипы делал FT311/312 чтобы через USB с андроидом общаться. т.е. это usb host для андроида и uart/i2c/spi для МК.

Спасибо, это интересно, похоже если поставить такую прокладку, то совместимость по всем возможным платформам можно получить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, _pv said:

данные непрерывно передаются?

Могу немного подстроиться, но в SAMD51 внутренней памяти очень мало 192К и забита она полностью, я пока это делал на ItsyBitsy M4, там есть флешь на 2МБайта, можно частично буферизовать. Но сам МК (SAMD51) не тянет полную обработку, то есть все равно надо как-то данные сбрасывать на внешний более быстрый процессор и на нем считаться. Как я успел проверить, на ВебАссембли вроде все очень хорошо получается. На десктопах вообще 2ГФлопса можно плучить, но даже простенькие старенькие мобильники 200МФлопсов на вебассембли показывают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

21 минуту назад, iiv сказал:

Я пока умею из веб интерфейса по XMLHttpRequest брать или забирать данные, но заметил, что если хост не поддерживает SSL, то мобильники все повально ругаются и не пускают туда или советуют уйти оттуда.

Странно.. ещё несколько месяцев назад заходил с тела на свой девайс (он работает по HTTP (без S)) - браузер не ругался. Может конечно что-то изменилось...

Если надо будет HTTPS, то в первую голову следует проверить: хватит ли силёнок у ваших девайсов на МК на потоковое шифрование (AES какой-нить). Очень поможет в этом плане наличие аппаратного модуля шифрования в МК. Да и коннект надо будет держать непрерывно ("keep-alive" или ещё что-то использовать). Так как если при передаче тела HTTP-запросов/-ответов используется симметричное шифрование (тот же AES), то в момент TLS-рукопожатия используется асимметричное шифрование. А оно требует в разы больших ресурсов от МК.

И вообще: HTTP лучше использовать только если без него никак. Если требуется работа именно с браузером. Если же на телефоне планируете самописное приложение, то (как я уже сказал выше) - лучше простой TCP-сокет. Шифрование и в него можно добавить, при желании.

Опять-же: если всё-таки придётся делать HTTPS, то советую обойтись без JSON и подобных текстовых форматов передачи данных. Текстовый формат сразу кратно раздует траффик, и ваши 1-2Мб/с превратятся в 3-6Мб/с; которые ваш МК уже скорей всего не потянет по программному шифрованию (если нет аппаратного модуля шифрования в МК).

 

21 минуту назад, iiv сказал:

Скажите, пожалуйста, а можно ли это сделать средствами WebAssembly и Javascript? Если да, вдруг Вам было бы не сложно, или сказать как, или сказать на какие ключевые слова нагуглить, а то сразу не смог найти, вылазит куча всего не по теме.

Нет, тут ничего не подскажу. Хотя JSON-ы у меня ходят через TCP-сокет. Но как TCP-сокет окучить из браузера - не знаю.  :unknw:

 

21 минуту назад, iiv сказал:

согласен, но зато появляется хоть какая-то совместимость между платформами.

Если нужно всё-таки из браузера, то я думаю можно ещё глянуть в сторону всяких SHOUTcast-протоколов (это то, в чём вещают онлайн-радиостанции).

SHOUTcast передаёт данные:

1. В бинарном виде (не нужно текстового кодирования данных, раздувающего объём).

2. Непрерывным потоком в одном соединении (не нужно частых рукопожатий множества TLS-сессий, требующих больших вычислительных ресурсов от МК по асимметричному шифрованию).

3. Поток данных передаётся единым файлом, от момента соединения и хоть до бесконечности.

4. Браузеро-совместимо (кроссплатформенно).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

22 minutes ago, jcxz said:

Вы тут порядком чисел не ошиблись?? :umnik2:  Вроде как даже лучшие телефонные модемы могли максимум 56Кбит. И то - это не на всякой линии получалось. Требовалась линия с более широкой полосой пропускания чем минимальная стандартная. А в микрофонном входе телефона там всё будет намного хуже. Имхо. Если получится несколько килобит/сек - это будет удача. Да и со сложными методами модуляции покувыркаться вдоволь придётся.

под микрофонным входом имелся ввиду не сам микрофон, а 3.5мм вход гарнитуры,

покувыркаться придётся, но не вижу причин, почему у древних модемов через какие-попало каналы (4кГц полоса вроде была обычно) на километры 56кбпс получалось, а двух аудиокодеков на 1м без посторонних шумов вдруг не получится хотя бы столько же.

 

https://github.com/romanz/amodem   в тестах 48kpbs через динамик-воздух-микрофон, прямо по проводу должно быть лучше.

https://github.com/quiet/quiet-js   40kbps обычной gmsk, без кувырканий, прям в браузере.

 

но требуемые 2мбит/с конечно не вытянуть.

 

50 minutes ago, iiv said:

Спасибо, это интересно, похоже если поставить такую прокладку, то совместимость по всем возможным платформам можно получить.

яблоки всё равно в пролёте, 

из браузера до этого Android Open Accessories ещё добраться надо,

да и в ПК поди не воткнуть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

18 минут назад, _pv сказал:

покувыркаться придётся, но не вижу причин, почему у древних модемов через какие-попало каналы (4кГц полоса вроде была обычно) на километры 56кбпс получалось, а двух аудиокодеков на 1м без посторонних шумов вдруг не получится хотя бы столько же.

Потому что 56кб/с получалось на тех линиях, где полоса как раз не была зарезана. И была шире 7кГц. причём - значительно шире. (Правильнее сказать: ширина полосы, нелинейность АЧХ канала в которой не превышала допустимую, вытягиваемую эквалайзером).

На полосе 4кГц вы даже 33600 бод не получите. Насколько помню...

Да и ТСу вроде как надо 1-2Мб/с. Причём: такую скорость от каждого из пучка подключенных девайсов. Суммарную скорость ТС не озвучил (сколько максимально одновременно может быть подключено девайсов? какая максимальная суммарная скорость приёма от всего пучка требуется?)

18 минут назад, _pv сказал:

https://github.com/romanz/amodem   в тестах 48kpbs через динамик-воздух-микрофон, прямо по проводу должно быть лучше.

https://github.com/quiet/quiet-js   40kbps обычной gmsk, без кувырканий, прям в браузере.

А какое отношение эти проекты имеют к обсуждаемому вопросу? Там вроде работа идёт на звуковых картах компов, а не на микрофонном входе телефона.

У линейных входов определённых звуковых карт, полоса пропускания может быть достаточно широкой (скорей всего на тех, на которых тестировали > 10кГц).

В любом случае к микрофонному входу сотового телефона (причём произвольному, любому) эти проекты не имеют никакого отношения. С такого входа если вытянете 1-2кб/сек - это будет большая удача. А скорей всего - и килобита/сек не получите. :unknw: Имхо.

 

PS: Среди каналов связи смартфона ещё можно рассмотреть Bluetooth. Но не знаю как там с одновременной работой с несколькими удалёнными устройствами. Да и со скоростью может не хватить. Особенно на айфонах....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, jcxz said:

Да и ТСу вроде как надо 1-2Мб/с. Причём: такую скорость от каждого из пучка подключенных девайсов. Суммарную скорость ТС не озвучил (сколько максимально одновременно может быть подключено девайсов? какая максимальная суммарная скорость приёма от всего пучка требуется?)

Девайсов обычно 2, в урезанном варианте - только 1, наверное есть задачи, где девайсов 3 или 4, но таких задач очень мало и можно в этом случае требовать, чтобы пользователь втыкался в коспьютер, а не в мобильник.

Трафик с одного девайса примерно 1.1мбит/с, теоретически наверное до 500кбит/с можно уронить, но SAMD51 может не справиться, то есть я пока не проверял.

 

То есть в мобильной версии не более 2 девайсов, с каждого по 1.1мбит/с. Могу буфферизовать до 2-3 секунд, но, больше не осилю, если не менять МК, на котором все сейчас крутится.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

12 minutes ago, jcxz said:

А какое отношение эти проекты имеют к обсуждаемому вопросу? Там вроде работа идёт на звуковых картах компов, а не на микрофонном входе телефона.

У линейных входов определённых звуковых карт, полоса пропускания может быть достаточно широкой (скорей всего на тех, на которых тестировали > 10кГц).

В любом случае к микрофонному входу сотового телефона (причём произвольному, любому) эти проекты не имеют никакого отношения. С такого входа если вытянете 1-2кб/сек - это будет большая удача. Имхо.

quiet-js из браузера работает, можно и с телефоном потестить.

 

с чего бы при стандартных 44кГц сэмплинга полосе вдруг стать сильно уже?

https://www.cirrus.com/products/cs42l73/

из какого-то айфона или айпада вроде бы кодек, не особо он хуже каких-нибудь стандартных realtekов что на всех материнских платах ПК обычно распаяны.

в любом случае ТСу не хватит, хоть и самое "кроссплатформенное" решение. я лишь предложил как альтернативу такому же медленному nfc. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 минут назад, iiv сказал:

Трафик с одного девайса примерно 1.1мбит/с, теоретически наверное до 500кбит/с можно уронить, но SAMD51 может не справиться, то есть я пока не проверял.

Это бинарный траффик? Без ASCII-кодирования?

Если сомневаетесь, что даже с таким траффиком МК справится, то о каких ява-скриптах (которые работают с JSON?) или о каком HTTPS вообще можно говорить (да ещё видимо без аппаратного модуля шифрования?) ? Их тогда уже однозначно не потянет.

 

7 минут назад, _pv сказал:

с чего бы при стандартных 44кГц сэмплинга полосе вдруг стать сильно уже?

https://www.cirrus.com/products/cs42l73/

из какого-то айфона или айпада вроде бы кодек

Потому как полоса пропускания она не только (а скорее даже не столько) определяется частотой дискретизации кодека. Она намного меньше.

Видел где-то в сети ссылки на проекты по передаче данных через этот самый микрофонный вход. Там как раз и говорилось насколько помню об <1-2кб/сек.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...