Перейти к содержанию

    

yuri_t

Свой
  • Публикаций

    163
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о yuri_t

  • Звание
    Частый гость

Посетители профиля

2 127 просмотров профиля
  1. Посмотрите язык SDL (ITU-T Rec. Z.100) - лучше ранних редакций
  2. Дизайн WDT должен отвечать (как минимум) следущим трбованиям - Иметь независимый от CPU генератор - Не иметь run-time точек конфигурации (как, например PIC WDT) Этим требованиям НЕ отвечают 99% встроенных в CPU WDT; Fault tolerant: 2 документа обзорного типа attached [attachment=112441:sam_boeing_slides.ppt] [attachment=112442:AIRBUS_A...Controls.pdf]
  3. По поводу WDT - чтобы нарушить работу CPU, достаточно альфа-частице поменять любой бит в CPU register или CPU RAM, в WDT такое изменение просто поменяет значение счетчика WDT, что некритично(ну сработает раньше/позже, ну и что?) Что касается дублирования в Fault Tolerant System - то это упрощенный частный случай. Посмотрите в Интернете, как, например, устроены системы управления в Boeing 777 и Airbus A320.
  4. Если говорить о fault tolerant системах (медицина, авиация)- только многоканальные системы могут обеспечить необходимую надежность. Очень часто каждый канал делается на процессорах разных компаний и софт пишется разными группами разработчиков(по единой спецификации). Что касается WDT - то он нужен, т.к. такая, например, вещь как обычное космическое излучение, может привести к зависанию даже очень хороший CPU.
  5. Кто-нибудь запускал U-Blox U201 и Amazon AWS IoT ? Была ли проблема с сертификатами ?
  6. RTOS для MSP430

    Рекомендую "родную" SYS/BIOS от TI. Работает надежно (использую bios_6_37_00_20 & xdctools_3_25_04_88, MCU MSP430F5359). Недостатки - Генерация ОС из скриптов ( надо скачивать и использовать XDC Tools) - Нет нормальных исходных кодов.
  7. Цитата(OlegALL @ Jul 16 2015, 09:52) Да, загрузил версию, которая работала. Сейчас не работает. 2 байта принимаются через раз Ну тогда подключаем "тяжёлую артиллерию" 0. Создаем отдельный тестовый проект 1. Програмируем UART на 9600 бит/сек (формат 8 бит 1 старт 1 стоп, без Automatic baud rate detection) RX/ ТХ прерывания- запрещены) согласно MSP430F41x2_Code_Examples (TI file slac288e.zip) При это рабоч частота проц и периферии должна быть >= 1 MHZ 2. Сначала проверяем передачу (не прием !) Пример кода Код  const char str_to_send[] = "Str to send\r\n";      int len = strlen((char*)str_to_send);   int i;   for(;;)   {       for(i=0; i < len; i++)      {          while(!(IFG2&UCA0TXIFG));          UCA0TXBUF = str_to_send[i];      }      delay_1_sec(); } Подключаем стандартный Windows/Linux serial port терминал и убеждаемся в правильности передачи. Если передача не проходит или искажена, с помощью осц проверяем форму и длительность импульсов, а так же формат(8 бит 1 стоп 1 старт) 3. Если передача работает, то проверяем прием 3.1 Разрешаем RX interrupts 3.2 Пример кода обработчика Код   // Globals     volatile int rx_val = 0;     volatile int rx_cnt_ok = 0;     volatile int rx_cnt_bad = 0;    #pragma vector=USCIAB0RX_VECTOR __interrupt void USCIA0RX_ISR (void) {       rx_val = UCA0RXBUF;       if((UCA0STAT & (UCFE |  UCOE )) != 0)       {           rx_cnt_bad++;       }       else       {            rx_cnt_ok++;            if(rx_cnt_ok >= 14)                rx_val++;    // Just to make the compiler happy       }   } 3.3 Ставим breakpoints на rx_cnt_bad++ и на rx_val++; 3.4 С терминала посылаем строки типа "1234567890123456" и убеждаемся что символы принимаются и ошибок нет 4. Переходим к реальному проекту
  8. STM32L и GSM модем

    Цитата(wmakc @ Jun 25 2015, 14:47) STM32L100RB и GSM quectel m95. Контроллер запущен от кварца HSE. Работает на частоте 29 МГц. Использовать watchdog не получается, так как необходимо длительная работа от батарей, контроллер должен спать несколько часов. При использовании чип антенны на плате при инициализации GSM, контроллер виснет (попадает непонятно в какие участки программы или сбрасывается). Видимо при регистрации в сети. Какие существуют программные или аппаратные решения данной проблемы? Когда модем устанавливает соединение с сетью, его ток потребления максимален. Поэтому,IMHO, есть смысл посмотреть осциллографом питание процессора в этот момент
  9. AMBA 3 (ну или AXI - не суть)

    Цитата(DASM @ Jul 19 2013, 06:39) Ну да, поток должен быть непрерывным (пока хотя бы кадр), матрица ждать не будет.С софтом я разберусь, меня и подход v4l устраивает.Вопрос то хардворный скорее. Понятно, что это относительно новый вопрос, раньше то кушали что дают. Но рассматривая процы со встроенным интерфейсом к камере я не понял, в какой роли на шине он там.Похоже все же ДМА мастер. А откуда CPU знает, что сейчас real-time device должен сбрасывать содержимое в память? Поллинг или прерывания - неэффективно. Real-time device должен быть ДМА мастер.
  10. AMBA 3 (ну или AXI - не суть)

    Eсли работаете с Linux, то, IMHO, для скоростных обменов данными нужно пользоваться Network-like подходом: co стороны Software можно взять уже существующие механизмы - sk_buff etc., со стороны hardware - device должен с помощью DMA загружать несколько буферов в памяти, и потом только вызывать прерывание (Linux NAPI etc.)
  11. Вышла TNKernel 2.7

    Эта версия посвящена ,в основном, устранению накопившихся багов. Огромное спасибо всем участникам проекта TNKernel !!!
  12. IMHO, для RTOS самые удачные API у VxWorks - лаконично и поддерживают практически все вещи, специфические именно для реал-тайм ОС. Их вполне можно взять за основу для OSAL(OS abstraction layer)
  13. Цитата(kosyak© @ Jun 22 2013, 12:13) Создаю очередь с параметрами tn_queue_create(&queue, NULL, 0). Отключаю макрос TN_CHECK_PARAM. И падаю в ХардФаулт при вызове tn_queue_send_polling(&queue, (void*)123), ... Как бы покрасивше поправить такое поведение? Так не верно Код#if TN_CHECK_PARAM    if(dque == NULL)       return TERR_WRONG_PARAM;    if(dque->num_entries <= 0)       return TERR_OUT_OF_MEM; #endif А так верно Код#if TN_CHECK_PARAM    if(dque == NULL)       return TERR_WRONG_PARAM; #endif    if(dque->num_entries <= 0)       return TERR_OUT_OF_MEM; Исправлю в следующей (2.7) версии
  14. SLFS

    Файловая система SLFS рассчитана на применение в небольших встроенных системах с использованием Serial Flash с размером сектора 4 Кбайт (M25PX64 etc.) SLFS использует FIFO принцип - при записи файл добавляется в конец внутреннего списка, а при чтении файл берется из начала списка. В большинстве случаев после чтения файл удаляется из SLFS и дисковое пространство освобождается. Если SLFS диск заполнен и добавляется новый файл, самый старый файл будет автоматически удален. Файлы в SLFS могут иметь произвольную длину. SLFS использует журнализацию при создании / удалении файлов и wear leveling (выравнивания износа) для системных метаданных. http://www.tnkernel.com/slfs.html