User1285

У меня, к сожалению, нет опыта поддержки-ремонта массовых изделий, потому плоховато представляю возможные варианты выхода из строя изделий. Но, исходя из всего описанного выше, у меня тогда возникает некоторое замешательство...как же обеспечить устойчивую работу тех же устройств обработки и хранения информации если у меня в любой момент устройство может сброситься (от разряда или чего-то другого). У меня ж нет такого понятия как транзакции в БД, тут получается ситуация что я начал писать-менять какие-то данные и вдруг контроллер ребутнулся.. Хорошо если при этом пострадали только те данные, с которыми я работал в текущий момент, но где гарантия что этот ребут не вызовет повреждения данных в других ячейках внешней памяти. Возникает тогда вопрос в том что нужно: - при запуске контроллера производить проверку своей внутренней флеши и лишь после этого запускаться, - добавлять ко всем данным, хранящимся во внешней памяти, контрольные суммы и периодически производить их проверку (если данные хранятся структурами, то CRC к каждой структуре, если это массив данных, то CRC массива и т.д.). Но тогда также получается что хочу я этого или нет, но мой сервер должен знать расположение данных внутри каждого контроллера с тем, что если вдруг "побьются" данные, то отдав серверу ID ячейки он мне должен вернуть данные, которые лежат в данной ячейке. То же касается и массивов данных (но учитывая что CRC есть только для всего массива, то перезаливать нужно весь массив чтобы не усложнять все). Чтобы был меньше абстракций - это устройство контроля доступа. Соответственно данные - это номера карт, правила прохода, расписания и т.п. И этих данных много. В данный момент у меня работает таким образом что изначально данных во внешней памяти нет, а при работе с сервера приходят разные команды (типа добавить для карты N, расписание и правила), в результате в процессе работы внутри девайса формируется своеобразная база данных с возможностями поиска и т.п. Но она довольно хрупкая если ячейки вдруг начнут "биться". Ладно еще если пострадает какая-то из структур, ее можно перезапросить с сервере. Но если пострадают какие-либо из ячеек, завязанных на структурирование данных для ускорения поиска, то эти данные я не могу восстановить, т.к. они есть только внутри контроллер и сервер не знает о них. Выходит так, что данная архитектура системы плохо приспособлена для реалий жизни и нужно переделывать исходя из того что контроллер является менее надежным элементом и нужно структуру памяти каждого девайса формировать на сервере а потом заливать в девайс чтобы иметь возможность в случае необходимости ее перезалить. Второй вариант это, как было описано выше, использовать журналирование. Но это уже получается совсем другая сложность самого контроллера.

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

Прошу прощения, сосредоточился на программной реализации и забыл упомянуть что конечно будет добавлено бесперебойное питание. Будет стоять резервный аккумулятор, при пропадании основного питание будет происходить переключение на резерв, в случае просадки резерва устройство будет само отключаться и включаться лишь после подачи основного питания + некоторая задержка чтобы успел хоть немного подзарядиться резервный аккум.

Всем спасибо за помощь! Буду пробовать реализовать дублирование памяти. Кольцевой буфер с N старых версий проблематичен, потому как это, как мне кажеться) усложнит сильно алгоритм. Я добавлю к каждой записи контрольную сумму и в случае если контрольная сумма некорректная, то пытаюсь прочитать те же данные из второй копии памяти. А если и там проблемы с контрольной суммой, тогда буду считать данные не валидными и уведомлять сервер о проблеме. Интересно нужно ли в случае применения flash памяти типа AT45DF добавлять алгоритм разметки bad ячеек, чтобы если данные побились в ячейке, то исключать ее из дальнейшего использования...

Добрый день! Возникла проблема с обеспечением целостности данных при хранении данных в памяти с постраничным стиранием. Память AT45DB321. В частности есть устройство, которое имеет много сохраненных в памяти структур данных. Эти структуры никак не связаны друг с другом, они могут в произвольном порядке изменяться с сервера, добавляться новые, деактивироваться старые. И вот тут я задумался о том как быть с потенциально возможной ситуацией: - прилетело уведомление что нужно заменить структуру STRUCT_N, которая находиться посереди страницы памяти MEM_PAGE_X, - я запускаю процесс перезаписи страницы (либо путем вычитки страницы в ОЗУ и заменой нужных мне данных, либо внутренними стредствами микросхемы), - в процессе перезаписи произошел сбой питания, оно пропало (либо после стирания, либо когда данные начали грузиться в память), - после восстановления питания у меня получается ситуация что кроме текущей редактируемой структуры у меня пострадали еще структуры, находящиеся на той же странице что и редактируемая структура. Да, я не получил от девайса ответа что редактируемая структура была изменена и я повторю данную операцию. Но как быть с остальными данными? Проблема осложняется тем, что сервер абсолютно не владеет информацией о фрагментации памяти, на каких страницах какие структуры храняться и т.е. я понятия не имею какие именно стуктуры я потерял совместно с редактируемой структурой. Посоветуйте, пожалуйста, какие меры можно предпринять чтобы избежать подобного? Один из вариантов, который я вижу (не самое интересное как по мне решение): - формировать на сервере прямо блоки данных (с контрольными суммами), - при каких-либо изменениях сначала редактируются данные на сервере, пересчитывается контрольная сумма, - после этого отправляется команда модицикации на девайс и в ответе должна прийти контрольная сумма блока памяти девайса, - если совпало - то все ОК, если не совпало - грузим полный блок кода с сервера на девайс. Однако при это получается слишком сильная связь сервер-девайс, т.е. если я перешел на другую структуру памяти или другую микросхему с другим размером страницы-блока, то мне нужно и на сервере вносить изменения в алгоритм работы. Хотя с другой стороны это упростит задачу периодического контроля целостности данных, т.е. раз в N-й промежуток времени сервер просит дать ему контрольные суммы памяти и сверяет со своими данными. Стоит ли замарачиваться с этим?

Я понял, спасибо. Попробую добавить чтение еще и СИМ-карты периодическое. Возможно это как-то было связано с перебоями в работе киевстара, которые вчера наблюдались -под вечер смс долго не отправлялись, днем в телефоне одна из СИМ-ок (киевстар) выпала из сети и некоторое время не хотела регистрироваться....

Ну а все-таки есть ли какие-то рекомендации по поводу команд, которыми предпочтительнее мониторить состояние модема и которые более точно позволят определить подобную ситуацию?

Я понял, спасибо! Так это баг какой-то в прошивке? Или это я неправильно что-то делаю? А есть ли какая-то команда, по которой бы точно можно было понять что модуль в сети? Можно конечно периодически проверять состояние счета....но не будет ли проблем с оператором если делать это сильно часто...

Прошу прощения, я лопухнулся, модуль не sim900d а просто sim900. Купил я эти модули лет 5 назад по хорошей цене и вроде как они были привезены откуда-то, или с Белоруссии, или с России, точно не припомню уже. С тех пор они лежали без дела, а теперь вот дошли до них руки. Кстати, модем светодиодом net led мигает с нормальной периодичностью индицируя что он в сети, однако оператор говорит что он не в сети :(

Добрый вечер! Столкнулся с проблемой - модуль вошел в непонятное для меня состояние. Он отвечает по UART на запросы CLCC,CREG и CSQ, однако при попытке позвонить на него оператор говорит что абонент не в сети. Вот лог опроса AT-командами: [21:40:10.0] AT+CSQ [21:40:10.0] +CSQ: 20,0 [21:40:10.0] OK [21:40:10.1] AT+CLCC [21:40:10.1] OK [21:40:20.0] AT+CREG? [21:40:20.0] +CREG: 0,1 [21:40:20.0] OK [21:40:20.1] AT+CSQ [21:40:20.1] +CSQ: 20,0 [21:40:20.1] OK [21:40:20.1] AT+CLCC [21:40:20.1] OK [21:40:30.0] AT+CREG? [21:40:30.1] +CREG: 0,1 [21:40:30.1] OK [21:40:30.1] AT+CSQ [21:40:30.1] +CSQ: 28,0 [21:40:30.1] OK и так далее с такой же периодичностью. С чем может быть связано такое поведение? Модуль зарегистрировался в сети нормально, отвечал на СМС [21:29:12.8] +CMTI: "SM",1 [21:29:12.8] AT+CMGL="REC UNREAD" [21:29:12.9] +CMGL: 1,"REC UNREAD","+38067ххххххх","","16/08/29,21:29:08+12" [21:29:12.9] 12 0 [21:29:13.0] OK [21:29:13.0] AT+CMGDA="DEL READ" [21:29:13.1] OK [21:29:13.2] AT+CSCS="GSM" [21:29:13.2] OK [21:29:13.2] AT+CSMP=49,143,2,241 [21:29:13.2] OK [21:29:13.2] AT+CMGS="+38067ххххххх" [21:29:13.3] > Output 2 on. [21:29:13.3] [21:29:17.0] +CMGS: 72 [21:29:17.0] OK [21:29:17.0] AT+CREG? [21:29:17.0] +CREG: 0,1 [21:29:17.0] OK [21:29:17.0] AT+CSQ [21:29:17.0] +CSQ: 24,2 [21:29:17.0] OK а когда я через 10 минут попробовал на него позвонить, то уже не дозвонился. Оператор Киевстар. Логика перезапуска модема ориентирована на отсутствие ответа на AT-команды и, соответственно, модем не перезапускает, т.к. на команды приходят ответы. Прошивка модуля - Revision:1137B07SIM900M64_ST Я в растерянности...

Да я честно говоря использовать VNC2 потому что бюджет проекта и временные рамки довольно ограничены и браться сейчас за переделывание-адаптацию какого-либо USB стека под FTDI это будет отнють не самое удачное решение. А особенно если стек еще и платный(имею ввиду Micrium USB Host Stack). Я думал что VNC2 уберет головную боль касательно USB хоста и позволит заниматься остальной частью проекта, но пока это не так. Написал в техподдержку FTDI, жду ответа.

да вроде бы все нормально с VID и PID:

Продолжаю работу по этому проекту. Купил платку с VNC2 на борту и платку дебаггера для VNC2 Судя по описанию микросхемы VNC2 и широкому ассортименту прошивок, все должно было пройти гладко. Однако скачал прошивку "UART to FT232 Host Sample Application ROM" c сайта FTDI firmware, прошил ей свой чип VNC2, но он не заработал как было обещано в роли моста. Тогда пришлось устанавливать среду разработки Vinculum II IDE и лезть в исходник этой прошивки (они есть в примерах идущих вместе со средой разработки). Запустив это все под дебаггером я увидел что VNC2 (насколько я понимаю) не обнаруживает подключенного чипа FT232: в функции VOS_HANDLE ft232_host_attach(VOS_HANDLE hUSB, unsigned char devHostFT232, unsigned char ftport) { usbhost_device_handle_ex ifFT232; usbhost_ioctl_cb_t hc_iocb; usbhost_ioctl_cb_vid_pid_t hc_iocb_vendor; common_ioctl_cb_t ft232_iocb; usbhostft232_ioctl_cb_attach_t ft232_att; VOS_HANDLE hHostFT232; // find FT232 class device hc_iocb_vendor.vid = USB_VID_FTDI; hc_iocb_vendor.pid = USB_PID_FTDI_FT232; // user ioctl to find first FT232 device hc_iocb.ioctl_code = VOS_IOCTL_USBHOST_DEVICE_FIND_HANDLE_BY_VID_PID; hc_iocb.handle.dif = NULL; hc_iocb.set = &hc_iocb_vendor; hc_iocb.get = &ifFT232; if (vos_dev_ioctl(hUSB, &hc_iocb) != USBHOST_OK) { return NULL; } // now we have a device, intialise the FT232 driver for it hHostFT232 = vos_dev_open(devHostFT232); ... проверка условия vos_dev_ioctl(hUSB, &hc_iocb) всегда возвращает USBHOST_NOT_FOUND. Может ли кто-то что-то подсказать по этому поводу?

спасибо, я к этим чипам и пришел. VNC1L дороговатый. VNC2 больше заинтересовал. Но теперь заказчик чего-то задумался относительно USB и тех изделий :)

В устройствах микросхема FT232 используется по своему назначению как преобразователь UART-USB. Изначально эти устройства рассчитаны на подключение к ПК через USB. На ПК используется специальный софт, который принимает данные с устройств и отображает информацию о состояниях устройств, пишет логи. Однако возникла необходимость собирать данные с этих устройств без помощи ПК, т.е. рядом с устройством располагать еще одно устройство(микроконтроллер+обвязка), которое будет иметь на борту USB HOST и соответственно как и ПК будет получать данные с устройств через USB.

Добрый день! Прошу совета-помощи по возникшей проблеме. Имеются устройства, в которых USB реализован на FT232. При подключении к компьютеру видно что устройства постоянно выдают пакеты данных на скорости 115200. Возникла необходимость разработки хоста, к которому будут подключаться данные устройства и который будет принимать и обрабатывать эти пакеты данных. Однако, просмотрев зарубежные форумы, встретил плохие обзывы по поводу USB хоста для FT232, пишут что не хочет работать и предлагают уходить от FT232. К сожалению, в данной ситуации нет возможности уйти от FT232, т.к. устройства уже есть и их нужно использовать. Может ли кто-то что-то посоветовать по этому поводу? Есть ли у кого-то опыт в подобных вещах? Спасибо!

Чтобы устранить коллизии в идеале бы хорошо как-то синхронизировать передатчики, ну или хотя бы сделать выбор промежутка времени передачи для каждого из передатчиков псевдослучайным. Вообще для таких вещей лучше бы использовать приемопередатчики чтобы можно было иметь обратную связь и понимать доставлен ли пакет или нет. Для начала уточните насколько Вам важны передаваемые данные и насколько можно жертвовать тем что часть пакетов будут теряться из-за коллизий, помех и т.п.

Добрый день! Прошу прощения если подобная тема уже поднималась. Возникла проблема - необходимо обеспечить помехоустойчивость радиоканала. Есть уже готовое железо, собранное на TXC101 и TRC101, частота 433,92МГц. Железо менять нельзя, могу только программно улучшать что-то. Канал односторонний, т.е. полноценную передачу данных с ACK сделать не получается. Соответственно стоит задача обеспечить максимальную помехоустойчивость отправляемой информации. Мне необходимо передавать пакеты длиной порядка 500 байт. Скорость 9600. Однако не хотелось бы сильно наращивать размер пакета, т.к. это удлинит время передачи. Передавать по несколько раз одни и те же пакеты тоже не сильно хорошо, т.к. передаваемые данные меняются постоянно(где-то раз в секунду) и потому очень желательно чтобы каждый пакет доходил максимально полным(максимально восстановленным). Посоветуйте пожалуйста как сделать правильно: - сначала попытаться ужать исходные данные а потом закодировать чем-то типа кодов Хемминга? - или при помехоустойчивом кодировании нежелательна предварительное сжатие (архивация) данных? - стоит ли использовать перемежение(перемешивание) для лучшего восстановления битых блоков данных? - какое кодирование лучше применить? (у меня контроллер atmega8 , не сильно много места свободного и вычислительной мощности) - насколько сильно разрастается размер пакета при кодировании позволяющем восстановить порядка 25-50% битого пакета? Я читал про коды Рида Соломона но я думаю наврядле я смогу реализовать нечто подобное. Коды Хемминга я так понимаю проще будет реализовать, но достаточно ли мне будет этого. Какие есть оптимальные варианты? Спасибо!

Я планирую использовать частоту ШИМ-а больше чем 16 кГц и понимаю что потери на переключение возрастут, хотя если использовать скоростные ключи то думаю может не сильно возрастут. Сейчас использую ШИМ порядка 10 кГц и когда двигатель нормально засинхронизирован (пока по датчикам холла), то ни ключи ни сам двигатель практически не греются.

Т.е. насколько я понял, на рисунках в аппликейшенах от microchip AN857 - Brushless DC Motor Control Made Easy и подобных отображается лишь общий принцип. Просто исходя з данного рисунка мы должны подавать именно прямоугольные испульсы. А на самом деле для того чтобы обеспечить возможность регулирования скорости и крутящего момента эти импульсы должны иметь ШИМ наполнение. Я правильно понимаю? Частота (8/16кГц) указываемая в характеристиках регуляторов (например http://www.hobbyking.com/hobbyking/store/_...arehouse_.html) это и есть та самая частота ШИМ наполнения импульсов? В момент разгона мы одновременно и наращиваем частоту импульсов и увеличиваем заполнение ШИМа?

Добрый вечер! Начал разбираться с бесколлекторным двигателем (outrunner для авиамоделизма) и система управления для них. Возникли некоторые вопросы, на которые не смог найти ответы. Простые ESC управляют двигателем подавая на три его обмотки прямоугольные импульсы сдвинутые друг относительно друга на 180 градусов. На вход ESC получает сигнал управления такого же типа как и сервоприводы, т.е. импульсы частотой порядка 50 Гц и , в зависимости от длительности импульса, ESC должен включить определенные обороты двигателя (или реверс, или остановить двигатель). За счет чего обеспечивается стабилизация частоты вращения двигателя? Только за счет частоты подаваемых на его обмотки импульсов? Ведь если эти импульсы идут без ШИМ наполнения (т.е. средний ток фактически не меняется) то каждый этот импульс дает двигателю максимальный толчек и двигатель будет стремиться раскрутиться на максимальные обороты. При этом ESC отслеживая обратные ЭДС на свободных обмотках (в каждый момент работают две обмотки) синхронизирует последовательность подаваемых импульсов на обмотки. И в итоге ж обороты будут наращиваться. Как же всетаки обеспечить заданные входным серво-сигналом обороты? Где я что неправильно понимаю? Изучил аппликейшены от атмела и майкрочипа и все равно не дошло за счет чего обеспечиваются нужные обороты. Ткните пожалуйста носом куда смотреть, что почитать чтобы понять :) Спасибо!

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

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

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

такого режима там действительно нет, это все будет делаться программно. Вы совершенно правы. Я сегодня уже нагрузил небольшой емкостью (меньше чем 30 процессоров) и уже получилась почти синусоида. Вот подобные подводные камни меня и интересовали. Надеюсь получиться с ними справиться используя дополнительные буферы. А что имееться ввиду под "регулярным" буфером? Я читал что именно так делать правильно, возвращать на другой SPI вместе с тактовой частотой, однако , к сожалению, у меня на мастере выделяется всего один SPI на всю цепочку контроллеров. Есть ли какие-то методы чтобы засинхронизировать входные в мастер данные (MISO) с его исходящей тактовой частотой?