Enthusiast

Тактировать АЦП из под "Линукса" - бред. На мой взгляд, "Линукс" хорош на задачах с периодом обсчета от 1 мс и более с уходом времени обработки на мс. Если требования жестче, чем 1 мс, то лучше делать без ОС. Берите качественный тактовый генератор и будет Вам счастье.

В моём случае уход времени интервального таймера был в пределах 25 мкс (+/- 12,5 мкс) при стопроцентной загрузке процессора и "бомбардировании" платы сетевыми пакетами. В любом случае, что мешает выставить приоритет реального времени для своей задачи? На свежих ядрах такое вполне возможно.

Предлагаю обойтись без разработки драйверов, воспользовавшись стандартными возможностями "Линукса". Исходный код я приводил здесь.

В своё время я тоже столкнулся с подобными ошибками в четвёртой версии "Код композера". Я решил вопрос откатом на версию 3.3 "Код композера". Там связка "Матлаба" с "Код композером" работает однозначно. Последовательность действий по отладке следующая: создаю модель в "Матлабе", там же симулирую, запускаю выработку проекта на Си, далее автоматически подзывается и запускается "Код композер", туда подгружается Сишный проект, который автоматически собирается и двоичный исполняемый файл через внутрисхемный эмулятор, я использовал "XDS 510-USB", загружается и запускается на целевом микроконтроллере в "железе". Вуаля.

Все бы хорошо да только драйвер ядра с кодом обработчиков прерываний тоже ведь будет работать внутри операционной системы, подчиняясь ее планировщику задач. Таким образом, в конце пути переноса "Линукса" на сигнальный процессор мы получим лишь менее "отзывчивый" процессор. Стоит ли овчинка выделки, естественно, решать Вам.

Для сравнения приведу пример исходного кода на языке Си под "Линуксом" для обработки таймерного прерывания здесь. На мой взгляд, без использования операционной системы "отзывчивость" таймера на той же аппаратуре была бы лучше за счет не использования десятка миллионов строк исходного кода сегодняшнего ядра "Линукса". Увы, планировщик операционной системы "отзывчивости", отнюдь, не улучшает. А каким образом Вы собираетесь обойти операционную систему прямо в работе? Это возможно?

На мой взгляд, "Линукс" на сигнальном процессоре значительно увеличит время от прихода входного сигнала на процессор до выдачи выходного обработанного сигнала с процессора, то есть ухудшит "отзывчивость" сигнального процессора на входящие данные. В случае работы операционной системы время это увеличится на порядок за счет прохождения данных через ядро операционной системы. Если же в некоторых задачах "отзывчивость" процессора не важна, тогда не лучше ли применить процессор, изначально предназначенный для работы в операционных системах? Например, такой.

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

DMD, почему бы не создать свой микропроцессор, заодно осуществив его поддержку открытым компилятором GCC? Готовых микропроцессоров в сети полно, согласен. Однако мало кто делает аппаратное устройство микропроцессора и его поддержку компилятором совместно, создавая их друг для друга изначально. Лишь делая процессор и компилятор совместно можно получить заметный выигрыш по производительности. Это подобно "яблочным" изделиям: аппаратура сделана для своего программного обеспечения, в итоге качество изделия выше себе подобных изделий, где аппаратура и ПО создаются разными коллективами людей. Сделав для начала простейший микропроцессор и обеспечив его поддержку компилятором GCC, можно будет разговаривать с промышленными заказчиками, предлагая им решение, нужное лишь им. На мой взгляд, в нашей стране и не только в ней существуют отрасли, где типовые микропроцессоры не совсем подходят из-за особых требований к набору вспомогательных модулей и прочего. При соответствующем техническому уровню изделия искусстве продаж ещё и деньжат заработаете. Успехов!

Решил я не морочиться с низкоуровневой записью на диск и сделал запись данных в обычные двоичные файлы через fopen(), fwrite(), fflush(), fclose(). Данные записаться в двоичные файлы вполне успевают, а при пропадании и последующем восстановлении напряжения питания, на мой взгляд, все предшествующие данные из файлов должны восстановиться из журнала файловой системы ext3.

Нет, я использовал программное таймерное прерывание "Линукса". Привожу исходный код ниже. CONFIG_HZ - это параметр ядра? Честно говоря, я уже не помню его значение, выставлял всё по максимуму при сборке. Последний вопрос не понял, поясните. /* Configure and start timer for CAN bus I/O transactions */ /* Input: CanBusDescriptor for write and read to/from it */ /* Output: 0 - start is ok */ /* -1 - not ok (invalid) */ int StartCanBusTimer(void) { /* linux interval timer configuration */ struct itimerval TimerId; struct sigaction sigact; /* clear all flags and handler before using the signal action */ memset(&sigact, 0, sizeof(sigact)); /* define a signal handler for timer interruption */ sigact.sa_handler = &CanBusTimerHandler; if(sigaction(SIGALRM, &sigact, (struct sigaction *)NULL) != 0) { DEBUG_PRINT("Can not run a signal action!\n"); return -1; } /* configure timer */ /* At first time run the timer handler after minimal time (1 us) */ TimerId.it_value.tv_sec = 0; TimerId.it_value.tv_usec = 1; /* and every timing interval run timer handler again */ TimerId.it_interval.tv_sec = CAN_BUS_TIMEOUT_INTERVAL_SEC; TimerId.it_interval.tv_usec = CAN_BUS_TIMEOUT_INTERVAL_NSEC / 1000; /* start the timer */ setitimer(ITIMER_REAL, &TimerId, NULL); return 0; } /* It works at every CAN_BUS_TIMEOUT_INTERVAL_SEC */ /* Write data to the CAN bus and receive answer from it */ void CanBusTimerHandler(int SignalNumber) { /* write DataToTheCanBus to the CAN bus */ if((WriteToTheCanBus(CanBusDescriptor, (void *)DataToTheCanBus, UART_CAN_IO_NUMBER_OF_BYTES)) == -1) { DEBUG_PRINT("Can not write to the CAN bus!\n"); } }

В текущей задаче у меня получился уход времени отклика задачи по таймерному прерыванию не более 25 мкс (+/- 12,5 мкс в ту и другую сторону). Установлен "Генту" на одноплатном компьютере с х86-процессором на 500 МГц.

Судя по гугловской статье, при количестве отказов от 2000 до 6000 на 1 ГБ в год можно сказать, что в ответственные применения динамическую память без коррекции ошибок ставить нельзя. Стопроцентно сбойнёт изделие, как пить дать. Даже ECC-память сбоит один раз в год, что, на мой взгляд, в некоторых приложениях недопустимо. Для автоматизации здания микропроцессорная система с динамической памятью вполне подойдёт, а вот на борт ставить изделие с динамической памятью я бы не стал.

К североамериканцам доверия больше будет? Тынц.

Судя по исследованиям количества отказов в серверах "Гугла", можно сказать, что применяя в своём "железе" динамическую память с аппаратным контролем чётности, можно свести вероятность сбоя к пренебрежимо малой. Тынц.

Чем плох fflush()? Последняя запись данных может быть потеряна, главное - чтобы сохранились все предыдущие данные и файл был доступен для чтения в последствии. Если записывать данные на жёсткий диск каждые 10 мс, то не откажет ли он от такой частой записи? Стоит ли кэшировать запись, к примеру, раз в 100 мс?

Привет, уважаемые форумчане! Имеется одноплатный компьютер, с которого необходимо записывать данные на жёсткий диск, примерно 100 КБ каждые 10 мс. Получится ли использовать стандартную линуксовую файловую систему, каждые 10 мс открывая файл, дописывая новые данные в его конец и закрывая его? Какую файловую систему лучше выбрать? Или без низкоуровневой посекторной записи на жёсткий диск не обойтись? Кроме требования по скорости записи есть ещё требование по сохранности данных при аварийном отключении питания: желательно, чтобы данные не портились при этом и были доступны при восстановлении напряжения питания. Буду рад совету, пишите.

Насколько я понял из объяснений представителей "Актела" в России в актеловских ПЛИСах процессор "Кортекс М1" выполнен аппаратно, а не программно, а в среде разработки процессорное ядро лишь включается или отключается. Поэтому запустить процессор внутри ПЛИС возможно лишь на определённых микросхемах, внутри которых имеется это аппаратное ядро.

Да, требовалось реальное время работы устройства. Я обсчитывал напряжения и токи высоковольтных линий электропередачи с периодом работы таймера в 100 мкс. Пользуясь случаем, от всей души поздравляю всех работников энергетической отрасли с наступающим Днём энергетика!

Несколько изделий, прошивка которых сделана мной с помощью "Матлаба", уже находятся в круглосуточной работе. Так что, на мой взгляд, модельно-ориентированному подходу доверять можно. Ранее я выкладывал простенькую модель для TMS320F28335 где-то в своих сообщениях, она может помочь в начальном освоении "Симулинка". Успехов!

"HyperLynx" имеется в составе программы для разводки печатных плат "PADS". В местных закромах доступна последняя версия 9.3 вместе с лекарством.

Я поржал от души! Спасибо.

На мой взгляд, позывом к решительным действиям служит ответ каждого человека на вопрос о том, должно ли наше государство каждому из нас в отдельности или стоит начать строить свою жизнь самостоятельно без помощи извне. На мой сугубо личный взгляд, никто никому ничего по жизни не должен. От этого и лучше отталкиваться.

Точно также, как это уже делают некоторые отечественные предприятия отрасли разработки программного обеспечения: начиная от серийного сопровождения и поставок составных узлов до предложения собственных комплексных решений.

Ну, наконец-то! Да нет никакого заговора о том как бы погубить русскую электронную и прочую промышленность. На мой взгляд, причина закрытия многих предприятий нашей страны заключается в неспособности руководства предприятий приспособиться к открытому и постоянно меняющемуся общедоступному мировому рынку товаров и услуг. Увы, неспособны управленцы старой советской школы вести за собой в новых условиях, а бывшие арбузники-лоточники хоть и молоды, но управлять предприятиями по-новому не могут и не хотят. К счастью положительные сдвиги в подготовке будущих руководителей уже видны. Как только молодые руководители-новаторы, изначально настроенные трудиться в условиях общемирового рынка товаров и услуг, придут в отечественную промышленность, то дело пойдёт. Я думаю, что не китайцев надо не пускать, а самим выходить на мировой рынок следует, сначала с составными узлами, а затем и с комплексными решениями.