xvr

Угу. Тогда просматривается такая схема: Из памяти отсчеты читаются последовательно и загоняются (в виде потока) в 2 последовательно соединенных устройства. (Потоков на самом деле передается 2 - данные и индекс) Первое устройство выделяет локальный максимум в окне фиксированного размера. Представляет из себя сдвиговый массив (длинной на все окно) и параллельную схему выделения максимума. Устройство выдает на выход значение максимума и индекс, данные выдаются в момент смены индекса Второе устройство представляет собой накопитель максимальных значений на 5 входов. Состоит из массива на 5 элементов, параллельного устройства сравнения (5 шт на каждый выход массива и входной сигнал) и схемы записи. В массиве значения упорядоченны, схема записи определяет положение, куда надо поместить входной отсчет (если он вообще должен быть помещен в массив), и формирует сигналы разрешения записи (для нужного элемента) и сигналы сдвига для всех элементов с меньшим значением/большим номером (под сдвигом понимается переписывание значения из ячейки с меньшим номером/большем значением) Уточнение - 2му устройству еще надо сделать блокирование выхода на некоторое количество отсчетов после обнаруженного максимума.

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

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

Мдя. Вы к вашему исходному array тоже через *array[1][0] обращаетесь? И зачем надо было лепить лишние '*' в описании void func(TypeD * temp), вы к исходному массиву тоже где то звездочки пририсовывали? Тип TypeD нужно использовать СТРОГО так же, как исходный массив - лишние звездочки будут изображать уже другие сущности

У них вообще EEPROM'а нет, прошивка грузится снаружи при каждом включении. Так что ни о каких битах защиты речи не идет - некуда их там вставлять :rolleyes:

Открою великую тайну :rolleyes: - как сделать из массива (любого) тип, который можно будет написать в параметрах функции (например). Берем исходное определение переменной - unsigned int __flash Program1[5][4] = {...} Меняем имя переменной на тип, удаляем = и всё после него и пишем typedef вначале, все typedef unsigned int __flash ProgramType[5][4]; Используем void func(ProgramType my_var) {...}

Проверьте тестером напряжения на выводах 2 и 6 ST в покое и при передаче данных. Оно должно быть стабильным. Если при передаче проседает - меняйте емкости на побольше

В Элкотехе есть (SN74LVC2G14DCKR)

На любую свободную

Да

1. В main нет зацикливания в конце 2. printf в обработчик прерывания не ставят 3. Передачу с задержками внутри тоже не рекомендуется ставить в обработчик прерывания 4. Непонятно предназначение конструкции for(;u>0;u--) counts = b[9]; в начале функции передачи 5. SM в прерывании не смотрел - на первый взгляд нечто монстрообразное (хоть бы коментарии написал :rolleyes: )

Нормальные люди для этого пишут Excel'овские таблички, а не фенестые екзешники по пол мегабайта :laughing:

Почти. +5В в левой и правой половине соединяться не должны - это РАЗНЫЕ цепи. То же самое касается замель слева и справа На нее понадобится еще один DC-DC, на сей раз отдельный. Подключать к Vdd2 & Gnd2 Повесить на +5В (те, что слева) Кстати, в DS на ADUM6132 указано, что Vddb тоже надо подавать (12В), иначе оно работать не будет :(

Для ADUM6132: Концы VDD и VDDL (1 и 3) объединить и повесить на +5В Между объединенными концами VDD и VDDL и землей повесить блокировочный конденсатор Концы VISO и VDDA объединить, между ними и GNDISO повесить блокировочный конденсатор Земли GND и GNDISO разорвать В остальном правильно

Похоже Алекс проектирует гибрид ужа с ежем :) Может взять бобину колючей проволоки и не мучится? Я до сих пор не понял с какого бока там нужен COM порт, почему не хватает одного TCP/IP (WEB + telnet)?

Да, вполне. Но учтите, что: Устройства перед тем как подключить в систему придется конфигурировать (как минимум прописать им адрес) ПК будет сама опрашивать все устройства по очереди. По собственному почину устройства не смогут ничего отправить в ПК Если это устроит, то modbus вполне подходит

Читаем DS (соманда записи): Т.е. по умолчанию (528 байтные сектора) адрес страницы надо сдвигать на 10. Смотрим сорец: void data_flash_buffer_to_main_memory(void) { unsigned char* p_char; flash_receive_byte_counter = 0; page_convert = page_address; page_convert = page_convert << 9; т.е. сдвигается на 9 Чтение не смотрел.

Можете рассматривать ADUM как буферный элемент. Вход у него IA выход OA. Питания с каждой стороны должны быть свои. Гальваническая развязка для того и делается, что бы гальванически развязать 2 цепи, соответственно и питания у этих цепей должны быть гальванически развязанны. Кстати, 4х канальный ADUM здесь явно избыточен, достаточно будет одно канального (ADUM1100) Можно взять ADUM со встроенным DC-DC (ADUM6132), тогда отдельное развязанное питание не понадобится Батарейку :rolleyes: Нет. Нужно по 1му конденсатору на КАЖДУЮ м/сх, за исключением ADUM - для него 2 шт (по одному на каждое питание)

Насколько я понял этого человека, у него из физики есть только RS232 (UART), Ethernet отсуствует. Вот что бы этот TCP стек выпустить наружу, ему и нужен PPP. Возможно я его неправильно понял? Ау, автор !?

Я с ними не связан, но тоже согласен, что 'мультимастер здесь не нужен' :rolleyes: Осталось убедить в этом автора топика :laughing: Не может, протокол канального уровня должен обеспечить надежную доставку пакетов, а протокол уровня приложения сохранения недоставленных сообщений (в случае фатального отсуствия связи) где то. Но это гораздо сложнее, чем единственный мастер на ПК +1000% :beer: Про modbus тоже согласен на все 100% По поводу PnP: Получится, но в ограниченном объеме 'Все' - это сколько? Если их может быть 10-20 шт, то все ок. А если десятки тысяч, то 'все' ему будет сложно перебрать :cranky: Кроме того, каждое устройство должно иметь уникальный (и НЕБОЛЬШОЙ) адрес. PnP подразумевает - взял устройство из коробки, воткнул в сеть (без настроек) и оно заработало. В принципе даже это можно реализовать при условии, что устройства будут первый раз включаться в сеть строго по очереди (по 1 штуке). Вариант с 'собрал сеть из чистых (только из коробки) устройств и она заработала' не получится

Есть, но к COM порту оно никакого отношения не имеет. Вам нужен Remote Access сервер (RAS) на PC, и PPP стек на МК. А соединяться можно будет через telnet (кем кстати HyperTerminal и прикидывается при соединении через TCP/IP) Собственно сам telnet протокол простой как репа - нету там никакого протокола :laughing: Голый поток байтов через TCP 23 порт в обе стороны. (Справедливости ради замечу, что некоторые управляющие символы там все же есть, но если вам нужет интерфейс чисто текстовый, то можете про них смело забыть. А вообще на telnet есть соотвествующий RFC)

ADUM1401 включен неправильно - нафига ты ему входные и выходные сигналы вместо входа и выхода на питание посадил? RS485 тоже рекомендуется гальванически развязать, хз куда его воткнут :)

Ошибка где то. Сорцы будут, или нам включать телепатические способности?

Нет, modbus для одного мастера. Т.е. все будет происходить под жестким управление ПК. Возможно это подойдет, ПК вполне может периодически опрашивать все подключенные устройства по очереди. Вот только количество и адреса устройств должны быть известны на ПК, Plug & Play не получится

'Не совсем' - это мягко сказано :cranky: В RS485 сети должен быть арбитр, распределяющий кванты времени для обмена, если же и количество подключенных устройств заранее неизвестно, то это совсем чехол. Или делать сеть с поддержкой коллизий, как на аппаратном, так и на протокольном уровне. klin-2006, вам надо сначала разработать протокол взаимодействия устройств и ПК, остальное приложится B)