Круто конечно! И приятно читать, что такие интересные вещи реализуются на отечественной ЭБ.
Почему реализация помехоподавителя именно на этой микросхеме? Куча параллельных каналов — почему не ПЛИС?
Ну и раз уж всё делается на ARM11, — то такой вопрос: какую ОСРВ использовали? Оценивали загрузку ЦП и БПОС? Я так понимаю, хоть навигационное решение выдаётся 1-10 раз в секунду, но ведь за помехами-то следить надо гораздо чаще — в режиме реального времени. Если не ошибаюсь, то битовая скорость сигналов ГНСС — около 512 бит/с, то есть ~2мс/бит. Какая скорость решения задачи получилась — в 2мс укладываетесь?
1. volatile в определении переменных не указываете — тоже очевидно, опустим? ;)
2. А если в нашей «высоконагруженной системе» бомбанёт ряд длительных прерываний вот в этом месте?
if (TmpH!=High) TmpL= ReadReg(TimerCounter);
… а таймер будет достаточно скоростным — имеем реальный риск всё же неверно считать данные.
Я бы крайне рекомендовал, если синхронизация настолько важна, всё же выключать прерывания на время считывания таких критичных значений. Конструкция проще, вероятность допустить ошибку меньше.
Главное, чтобы базовые блоки печатаемые могли доставляться и устанавливаться по месту исключительно роботами — причём, чем проще робот, тем лучше. Вплоть до самого завершения строительства. С последующим автоматизированным тестированием помещений — давление, излучения и т.п.
Заходят люди после пары лет полёта в базу — а там уже всё готово, и бутерброды горячие дымятся… Прямо представил, какое облегчение испытают :)
Хранение данных в оперативке + ионистор, запись в flash/eeprom только при пропадании основного питания.
Ячейки памяти убивают люди! ;) Писали как-то драйвер по работе с flash, ошиблись в цикле — приращали не адрес, а значение по адресу. Память убивается за несколько секунд…
Партия большая, хорошо продаются такие брелки? На операционную прибыль вышли, или пока в убыток работаете? Или же, прибор был сделан под конкретного крупного заказчика? А остальное — дополнительный доход?
а у меня вопрос — если радиомодуль 1, а сим-карты две, то как будет отрабатываться такая ситуация:
с первой симки я сижу в интернете, допустим смотрю видео-ролики.
вторая симка «рабочая» — и с неё могут позвонить в любой момент. Она что, будет недоступна всё время???
Наткнулся на пост про 7ю часть, решил почитать произведение. Прочитал все 7 частей (я бы назвал их отрывками) на одном дыхании — пишете хорошо!
Но теперь я негодую — мой мозг требует продолжения, я не могу ждать! Это как ломка у наркомана… Выкладывать маленькие отрывки раз в одну-две недели — это так жестоко :(
Вообще-то да, т.к. создание объектников происходит на стадии компиляции всего проекта. А до этого момента работа может вестись напрямую с самим ресурсом.
Растровое изображение подготовлено с помощью утилиты LCD Assistant. Полезнейшая в хозяйстве вещь, скармливаешь ей однобитный bmp-файл, а она выдает в текстовом виде байтовый массив, пригодный к употреблению в C.
Простите, не могу с этим согласиться. На выходе получаются нечеловеко-читаемые массивы. Изменить картинку в паре мест, изменить любой другой ресурсный файл — и снова всё конвертировать? спасибо, не надо.
Отработал для себя следующий вариант.
1. В makefile проекта создаётся цель convert, должна входить в зависимость для цели исполняемого файла. Цель представляет любые входные файлы (ресурсы) в виде бинарных объектников:
2. В скрипт линкера *.ld добавляются эти объектники. Если файлы вызываются редко, то в секцию .text. Можно и в .data, если скорость важна или динамическое изменение содержимого подключенных файлов:
3. При включении файлов в проект, при линковке в сгенерированном map-файле можно найти, какого вида сформировались ссылки для подключенных ресурсов (для этого в *.ld надо прописать KEEP(html/arsenal.o) в первый раз, если в коде нет ссылок на ресурс). Например:
Более того, если у вас файл имеет определённую структуру, то можно делать ссылку на структуру (файл распологать в секции .data!) и потом динамически обновлять содержимое файла через поля структуры… В общем у кого на что фантазии хватит.
1 раз повозиться с настройкой проекта — зато потом можно «на лету» подключать/изменять любые ваши ресурсы!
1. Вся статья написана в духе «это какое-то шаманство, но делайте так — и всё заработает», особенно вот эта фраза:
Сознательно не удаляю ту часть файлов, которую не использую, потому что некоторые важные файлы, хоть и косвенно, но ссылаются на них. Поэтому лучше скопировать все.
Надо было разорбраться и чётко написать, почему эти файлы и где используются. Вы уж определитесь, нужные это файлы или не нужные.
2. Магические числа, «непонятно откуда», но внезапно и удачно всплывающие имена полей структур… Больше напоминает первое знакомство человека с системой.
3. ИМХО очень плохой подход — копировать из библиотеки отдельные файлы для использования. Надо наоборот учить людей, что лучше подключать целую готовую библиотеку, желательно предварительно слинкованную статически! И не надо будет её каждый раз компилировать вместе со всем проектом. Неиспользуемые файлы исключать из списка компиляции Keil умеет, через свойства по ПКМ на файле.
Tutorial таким быть не должен.
А вообще, солидарен с мнениями комментаторов, что лучше под open-source IDE изучать разработку. Тем более, более универсальные среды. Сам пишу под все МК в Eclipse, в том числе под 1986ВЕ9х.
Возможно, отсылка к началу 2000х — тогда в МАИ, например, об учёбе мало кто думал, как сейчас — не знаю. В основном работали кто где может, а к сессии на стенах в комнатах общаги висели таблицы с «расценками» — какой предмет сколько стоит сдать. Матаном там разве что пахло. Сам в МАИ не учился, но захаживал в гости, отсюда и информация.
Почему реализация помехоподавителя именно на этой микросхеме? Куча параллельных каналов — почему не ПЛИС?
Ну и раз уж всё делается на ARM11, — то такой вопрос: какую ОСРВ использовали? Оценивали загрузку ЦП и БПОС? Я так понимаю, хоть навигационное решение выдаётся 1-10 раз в секунду, но ведь за помехами-то следить надо гораздо чаще — в режиме реального времени. Если не ошибаюсь, то битовая скорость сигналов ГНСС — около 512 бит/с, то есть ~2мс/бит. Какая скорость решения задачи получилась — в 2мс укладываетесь?
2. А если в нашей «высоконагруженной системе» бомбанёт ряд длительных прерываний вот в этом месте? … а таймер будет достаточно скоростным — имеем реальный риск всё же неверно считать данные.
Я бы крайне рекомендовал, если синхронизация настолько важна, всё же выключать прерывания на время считывания таких критичных значений. Конструкция проще, вероятность допустить ошибку меньше.
Заходят люди после пары лет полёта в базу — а там уже всё готово, и бутерброды горячие дымятся… Прямо представил, какое облегчение испытают :)
Ячейки памяти убивают люди! ;) Писали как-то драйвер по работе с flash, ошиблись в цикле — приращали не адрес, а значение по адресу. Память убивается за несколько секунд…
с первой симки я сижу в интернете, допустим смотрю видео-ролики.
вторая симка «рабочая» — и с неё могут позвонить в любой момент. Она что, будет недоступна всё время???
Но теперь я негодую — мой мозг требует продолжения, я не могу ждать! Это как ломка у наркомана… Выкладывать маленькие отрывки раз в одну-две недели — это так жестоко :(
Удачи вам в ваших творческих муках!
objcopy --add-section .text.rc*
как-то так наверное, в синтаксисе не уверен — надо проверять.
Простите, не могу с этим согласиться. На выходе получаются нечеловеко-читаемые массивы. Изменить картинку в паре мест, изменить любой другой ресурсный файл — и снова всё конвертировать? спасибо, не надо.
Отработал для себя следующий вариант.
1. В makefile проекта создаётся цель convert, должна входить в зависимость для цели исполняемого файла. Цель представляет любые входные файлы (ресурсы) в виде бинарных объектников:
2. В скрипт линкера *.ld добавляются эти объектники. Если файлы вызываются редко, то в секцию .text. Можно и в .data, если скорость важна или динамическое изменение содержимого подключенных файлов:
3. При включении файлов в проект, при линковке в сгенерированном map-файле можно найти, какого вида сформировались ссылки для подключенных ресурсов (для этого в *.ld надо прописать KEEP(html/arsenal.o) в первый раз, если в коде нет ссылок на ресурс). Например:
Кроме того, в том же map-файле или в файле определений символов можно найти ещё сгенерированные константы:
4. Сгенерированные ссылки и константы являются глобальными, и мы можем использовать их в своих си-файлах:
Более того, если у вас файл имеет определённую структуру, то можно делать ссылку на структуру (файл распологать в секции .data!) и потом динамически обновлять содержимое файла через поля структуры… В общем у кого на что фантазии хватит.
1 раз повозиться с настройкой проекта — зато потом можно «на лету» подключать/изменять любые ваши ресурсы!
Надо было разорбраться и чётко написать, почему эти файлы и где используются. Вы уж определитесь, нужные это файлы или не нужные.
2. Магические числа, «непонятно откуда», но внезапно и удачно всплывающие имена полей структур… Больше напоминает первое знакомство человека с системой.
3. ИМХО очень плохой подход — копировать из библиотеки отдельные файлы для использования. Надо наоборот учить людей, что лучше подключать целую готовую библиотеку, желательно предварительно слинкованную статически! И не надо будет её каждый раз компилировать вместе со всем проектом. Неиспользуемые файлы исключать из списка компиляции Keil умеет, через свойства по ПКМ на файле.
Tutorial таким быть не должен.
А вообще, солидарен с мнениями комментаторов, что лучше под open-source IDE изучать разработку. Тем более, более универсальные среды. Сам пишу под все МК в Eclipse, в том числе под 1986ВЕ9х.