Интересная технология, спасибо. А нет ли возможности совсем избавиться от буфера в ОЗУ? В приведенном коде всегда создается буфер на стеке, куда копируется сгенерированное при компиляции изображение.
В DIO нативный код был не от хорошей жизни, библиотека писалась для JavaME c ее ограничениями (каждый класс давал +500байт в бинарник). Поэтому и сложная система взаимодействия нативного и жава кода (все жавовые нитки там зеленые).
Кстати, сама библиотека довольно широко разошлась, Eclipse Kura ее использует. Было бы неплохо ее переписать чисто на жавке с сохранением АПИ
Есть еще библиотека DeviceIO (https://wiki.openjdk.java.net/display/dio) от того же оракла, поддерживает все linux платы (теоретически, т.к. не использует ничего вендорспецифичного). GPIO работает поверх sysfs
Нужно отметить, что статью на реддите раскритиковали за вводящий в заблуждение заголовок. Народ ожидал увидеть распределенную систему, но никаких настроек для этого не приводится.
Пробовал такой станок. Столкнулся с тем, что текстолит по высоте неровный и с конусной фрезой точность получалась низкая. На одной из картинок я вижу, что ваша палата тоже как-то криво стоит. Как у вас получаются равномерные вырезы?
Давайте не будем обижаться, а рассмотрим вашу работу с точки зрения общества. Вы ж не в «я пиарюсь» блог пишете.
На данный момент, по вашему же опыту, стоит проблема выбора системы для своих проектов. Неверный выбор чреват значительной потерей времени и никто не гарантирует, что положительные отзывы означают стабильную работу с вашем конкретном случае.
Как я понял, TNKernel вас долгое время всем устраивала, пока вы не нашли критический баг. Принцип OpenSource подразумевает, что каждый может внести посильную лепту в создание и поддержание проекта. Что ж, возможно, в случае с TNKernel вариант «все переписать» действительно проще, чем «исправить». И мне сразу понравилась ваша первоначальная идея сохранить API. Но что же сообщество в конце концов получило? На мой взгляд, еще одну систему, несовместимую или малосовместимую с родителем, и чей статус так же неочевиден для будущих инженеров, как и статус TNKrrnel, ChibiOS и прочих с гораздо более громкими именами.
Вы упоминаете, что не доверяете другим проектам из-за потенциальных проблем. Сомнительный аргумент. Вы же не будете утверждать, что считаете свой код безупречным? Согласен, всегда важно досконально разбираться в работе приложения, которое используешь. Но RTOS в большинстве случаев — не rocket science. И в принципе, каждый уважающий себя эмбедер раз в жизни пишет свой вариант планироващика. Вот только полезность для окружающих такого действия сомнительна. В тоже время разобраться в работе существующих систем до уровня «знаю как сам писал» не вызывает сложности. И на мой взгляд, было бы гораздо полезнее довести вашу первоначальную идею до ума. Полезнее для общества, не для ваших конкретных проектов. Поэтому я и задал вопрос: а какие еще задачи вы решали, создавая свою систему? Может для PIC32 нет такого широкого рынка RTOS как для Cortex? Или АПИ TNKErnel такой необычный, что слезть с него очень тяжело?
Кстати, если тон комментариев вас не устраивает, то отвечать вовсе и не обязательно. Мы ж не лицом к лицу беседуем.
А вы проводили какое-нибудь исследование этой области? Просто таких систем пруд-пруди, та же ChibiOS имеет все описанные свойства (про контроль стека не уверен), а заявленных для поддержки платформ там на порядок больше. Поэтому создание с нуля еще одной ни с чем не совместимой системы выглядит как удовлетворение собственных амбиций за счет работодателя. Может вы еще какие-то проблемы решали? С IP например?
Забыли еще проект литреса с библеотеками. Имея читательский билет, можно получить логин/пароль на доступ в онлайн библиотеку литреса. Странно, что это так плохо рекламируется.
Странный способ провести исследование интереса, на словах-то многие готовы вложится в предзаказ. Вы утверждаете, что проект практически завершен. Может стоит открыть прием переводов через тот же пэйпэл? 20$ не такая уж большая сумма, многие бы рискнули, но зато эти «многие» были бы реальными заказчиками, а не говорунами.
Спасибо, почитал еще более внимательно и нашел, что double null-terminating — это просто требование для конкретной функции, где на вход может быть подано несколько файловых путей за раз, каждый из которых является простой null-teminated строкой (два 0 для wchar), а вся последовательность терминируется дополнительным нулем (еще 2 нуля).
Получается, что инструмент очень умный и проверил, что параметр не простой, а для особой функции. Уф, а то я уже стал сомневаться в собственном рассудке.
Все-таки нужно заметить, что аналогом его делает только железо, да и то не полностью (NFC? WiFi Direct?). Софт просто не сравним с самсунгом (просто голый андроид?). Ну и про поддержку писали уже. На С3 с осени вышло порядка 4 OTA обновлений.
Действительно, при статическом буфере memcpy не вызывается, а обращение к буферу заменяется на загрузку заранее подсчитанного значения.
Интересная технология, спасибо. А нет ли возможности совсем избавиться от буфера в ОЗУ? В приведенном коде всегда создается буфер на стеке, куда копируется сгенерированное при компиляции изображение.
В DIO нативный код был не от хорошей жизни, библиотека писалась для JavaME c ее ограничениями (каждый класс давал +500байт в бинарник). Поэтому и сложная система взаимодействия нативного и жава кода (все жавовые нитки там зеленые).
Кстати, сама библиотека довольно широко разошлась, Eclipse Kura ее использует. Было бы неплохо ее переписать чисто на жавке с сохранением АПИ
Есть еще библиотека DeviceIO (https://wiki.openjdk.java.net/display/dio) от того же оракла, поддерживает все linux платы (теоретически, т.к. не использует ничего вендорспецифичного). GPIO работает поверх sysfs
Нужно отметить, что статью на реддите раскритиковали за вводящий в заблуждение заголовок. Народ ожидал увидеть распределенную систему, но никаких настроек для этого не приводится.
На данный момент, по вашему же опыту, стоит проблема выбора системы для своих проектов. Неверный выбор чреват значительной потерей времени и никто не гарантирует, что положительные отзывы означают стабильную работу с вашем конкретном случае.
Как я понял, TNKernel вас долгое время всем устраивала, пока вы не нашли критический баг. Принцип OpenSource подразумевает, что каждый может внести посильную лепту в создание и поддержание проекта. Что ж, возможно, в случае с TNKernel вариант «все переписать» действительно проще, чем «исправить». И мне сразу понравилась ваша первоначальная идея сохранить API. Но что же сообщество в конце концов получило? На мой взгляд, еще одну систему, несовместимую или малосовместимую с родителем, и чей статус так же неочевиден для будущих инженеров, как и статус TNKrrnel, ChibiOS и прочих с гораздо более громкими именами.
Вы упоминаете, что не доверяете другим проектам из-за потенциальных проблем. Сомнительный аргумент. Вы же не будете утверждать, что считаете свой код безупречным? Согласен, всегда важно досконально разбираться в работе приложения, которое используешь. Но RTOS в большинстве случаев — не rocket science. И в принципе, каждый уважающий себя эмбедер раз в жизни пишет свой вариант планироващика. Вот только полезность для окружающих такого действия сомнительна. В тоже время разобраться в работе существующих систем до уровня «знаю как сам писал» не вызывает сложности. И на мой взгляд, было бы гораздо полезнее довести вашу первоначальную идею до ума. Полезнее для общества, не для ваших конкретных проектов. Поэтому я и задал вопрос: а какие еще задачи вы решали, создавая свою систему? Может для PIC32 нет такого широкого рынка RTOS как для Cortex? Или АПИ TNKErnel такой необычный, что слезть с него очень тяжело?
Кстати, если тон комментариев вас не устраивает, то отвечать вовсе и не обязательно. Мы ж не лицом к лицу беседуем.
Получается, что инструмент очень умный и проверил, что параметр не простой, а для особой функции. Уф, а то я уже стал сомневаться в собственном рассудке.