Jump to content

    

AndyBig

Свой
  • Content Count

    708
  • Joined

  • Last visited

Community Reputation

0 Обычный

About AndyBig

  • Rank
    Иногдящий
  • Birthday 09/19/1973

Контакты

  • Сайт
    http://
  • ICQ
    0

Recent Profile Visitors

1735 profile views
  1. Ковыряю дизассемблером исполняемую программу из недорогого тепловизора HT-1A. Производитель сильно облегчил это дело, оставив всю отладочную информацию в программе :) Ковыряю для того, чтобы немного улучшить и изменить интерфейс. И столкнулся с тем, что в некоторых моментах мне нужно не просто изменить байты в теле программы, а добавить их. Естественно, просто вставить их нельзя - полетят к чертям все ссылки на код и данные. Поэтому пришла мне в голову мысль добавить в конец файла килобайт 10, добавить в таблицу заголовков программы еще один, загружаемый в из этих 10 кб, и в этих 10 кб уже дописывать какие-то свои моменты, при необходимости прыгая на них из оригинального кода. Можно ли это сделать и если можно, то как? Что-то все мои попытки приводят к неработоспособности файла. Пока я пытался изменить заголовок NOTE на LOAD, пытаясь загрузить небольшой кусок этого файла в память по адресу, следующему за последним используемым программой :( Пока я не назначаю ему тип LOAD и не определяю адреса загрузки - файл работает, даже если я меняю его на NULL. То есть сам этот заголовок NOTE файлу для работы не нужен, как и секции, определенный в его адресах - .note.ABI-tag и .note.gnu.build-id При запуске измененного файла ОС тепловизора просто выдает сообщение Killed без подробностей. Системные логи, насколько я понял, не ведутся. [root@dragonboard ]# /work/app/ht-a1 -v 2 Killed [root@dragonboard ]# Система основана на Busybox v1.22.1. Вот лог загрузки, если это может помочь:
  2. У меня в девайсах загрузчик и основная программа зашиваются раздельно. В области загрузчика один из секторов отведен под хранение как раз таких вещей - серийник, версия железа, вариант сборки и т.п. Загрузчик умеет общаться с компом через USB и кроме обновления основной программы (шифрованной) умеет так же выполнять некоторые команды, в том числе обновление серийника. На компе имеется консольная утилита для работы с загрузчиком. В зависимости от параметров в командной строке она умеет заливать прошивку, обновлять серийник, параметры в EPROM и т.д. Сначала через JFlash заливается загрузчик. А потом прошивка производится через скрипт, вызывающий эту утилиту с различными параметрами и оценивающий результат ее выполнения: 1. Залить прошивку. 2. Залить параметры в EPROM. 3. Взять из файла текущий серийник и залить его в девайс. 4. Добавить в базу данных (SQLite) запись с данными о прошитом девайсе - дата прошивки, тип, серийный номер, UID микроконтроллера и т.п. 5. Увеличить на единицу текущий серийник и сохранить его в файл. То есть сначала вся новая партия девайсов прошивается загрузчиком через JFlash, а потом каждый девайс подключается по USB и запускается этот скрипт. После корпусирования девайсов они подключаются по USB, на компе запущенная программа на лету подхватывает подключенный девайс и показывает информацию о нем, и на корпус клеится соответствующий шильдик. Шильдики печатаются в типографии, сразу с серийными номерами. Из базы данных тоже печатаются наклейки с основной информацией текстом и некоторыми подробностями в штрих-коде, эти наклейки потом клеятся на коробки при упаковке. За несколько лет накладок не было :) В принципе, можно корпусировать сразу и прошивку через загрузчик объединить с наклейкой шильдика, но на случай обнаружения и исправления какого-то брака я сначала прошиваю, потом проверяю функциональность и только потом корпусирую.
  3. Так цена может на порядок гулять в зависимости от стиля программиста :) Простое мигание светодиодом можно тысяч на 30-50 растянуть :)
  4. Хм... Вроде обычный FTP - задаются логин-пароль, имя файла, путь файла и команда "скачать". Единственный момент, который для меня пока неясен - можно ли будет принимать его не торопясь :) Будем разбираться. Товарищи, работавшие с ними есть, подскажут, я надеюсь, если что :) Да, железо совсем неоптимальное и заказчик знает об этом. У него в планах перейти на новую версию железа с исправлениями и изменениями, но то будет отдельный проект. Пока нужно хоть как-то запуститься на имеющемся, идеальную работу от текущего железа он не требует :) Там и с текущим софтом, который тоже есть, не лучше обстоят дела. Написан он явно левой ногой с похмелья и очень-очень быстро :) Неее, этим я заниматься не буду точно. Заказчик эти алгоритмы в работе все равно не увидит, он увидит только результат их работы, а результат подробно описывается в ТЗ. Этого ТЗ вполне достаточно для заказчика, подробные алгоритмы ему и в ус не вдулись :)
  5. Прошу прощения не совсем понял про какой именно чип речь (STM32L4xx ?) и когда "тогда бы" :) Тут вроде не нужна моща, 1xx хватит с головой, да еще и не при максимальной частоте. Флэши с оперативкой тоже много не нужно :)
  6. Там на плате SPI-флэш на 4 МБ, для работы нужна максимум половина ее объема, остальное можно пустить под логи :) Естественно не по 200 байт текста ежесекундно... Параметризации чего именно? Нет, основное общение не по FTP :) Каким боком и главное зачем пихать FTP для периодической отправки пары сотен байт данных на сервер? Хотя есть мысль по FTP скачивать прошивки для обновления, вроде GSM-модемы Simcom умеют FTP.
  7. Ну опять же - я предполагаю, что заказчику нужен результат, а не козел отпущения с потерей месяца-двух, то есть он будет заинтересован в том, чтобы девайс работал, а не в том, чтобы найти виновного. Если возникнет ситуация, в которой недостатки железа начинают вешаться на меня - я просто разорву договор, не взяв оплаты и не отдав имеющиеся наработки. У меня есть источник дохода, так что с голода я не помру :) Я ведь говорил о сроках непосредственно разработки, согласование ТЗ и договора в них не входят :) ПО не начинает при этом глючить. Оно начинает эту фигню с датчиков сохранять и передавать на сервер, как ему и положено :) Потому что перед ПО не стоит задача определения качества показаний датчиков.
  8. Баги прошивки, возникающие при каких-то обстоятельствах - это да, мой головняк и я должен позаботиться о том, чтобы они не возникали. Но если изменилась температура -> поплыли показания датчиков, то это уже не ко мне :) Ну так ТЗ для того и составляется, чтобы потом не возникало непонятных претензий со стороны разработчика или заказчика :) Дополнительные работы за пределами ТЗ - это отдельная тема. Может быть я доделаю что-то сверх ТЗ просто по доброте душевной, а может быть на это будет отдельный договор со своим ТЗ. В принципе, если заказчик нормальный, то и ТЗ не особо необходим. А вот если он начинает лезть в бутылку, то ТЗ - это тот ограничитель, который может от его претензий отгородиться.
  9. Да, согласен, этот вопрос довольно скользкий. Тем не менее, на мой взгляд, если девайс работает без сбоев на столе, в тепличных условиях, когда выходы датчиков укладываются в оговоренные пределы, питание не прыгает, температура не -30 и не +70 и т.п., то это уже показывает работоспособность софта. Если, например, при температуре минус 30 перестает работать кварц или питание падает ниже предела, или с датчиков начинает сыпаться фигня - ну, это уже явно проблемы не прошивки. Я, конечно, могу заняться еще и оптимизацией железа под конкретные условия, но это уже отдельная задача :)
  10. С одной стороны - да, но с другой стороны у заказчика тоже ведь цель (я надеюсь) - получить в разумные сроки результат, а не только его демонстрацию. А результат он не получит пока не оплатит его :)
  11. Согласен, но думаю, что в случае глюков железа я смогу доказать что это глюки именно из-за железа. Если бы не GSM-модем, я бы дней за 10 справился, включая обновление прошивки (по USB или UART) :) Но модем для меня - неизвестная переменная, поэтому предполагаю 4-5 недель... Никак не буду, это же не повременная работа. Выполнение работ по вот этому ТЗ в такой-то срок стоит столько-то, и все :) Теперь мне становится примерно понятно от чего отталкиваться и на что ориентироваться, большое всем спасибо за советы и информацию. Особенно iosifk за несколько дельных мыслей и советов в разговоре по скайпу :)
  12. С железом там вроде бы уже решено, оно есть и как-то работает. Хотя не предусмотрено даже простейшего резистивного согласования уровней сигналов UART...
  13. И софт и оборудование для разработки и отладки у меня имеются. С STM32F1xx тоже работал немало. Загрузчики с обновлением прошивки писал, правда по USB. Основную часть - сбор, обработка и накопление данных - думаю, напишу за неделю не очень напряженной работы, но на всякий пожарный отвожу себе на это две недели :) Единственный вопрос - работа с GSM-модулем (SIM800/SIM53xx) - с ними я не работал, но полистал документацию - вроде бы больших сложностей не предвидится, да и есть знакомые, которые с ними работали и смогут подсказать если что. На работу с ним и с серверным протоколом отвожу себе еще пару недель. Заказчику буду озвучивать пять недель (пусть будет еще одна запасная неделя). Ну то есть 1000 руб/час - это считается нормальной ценой? Не завышенной? Дистанционное обновление прошивки - это необходимый заказчику функционал, так что будет по-любому :) Сейчас скачаю и попробую вспомнить свой пароль в нем :))