juvf

не происходит ресета. или я не там пишу?

+1. Кнопки ресет не хватает. А как через кансоль сбрасывать проц?

Что значит "БЕЗКОНТАКТНЫЙ"? На сколько я понял, цепи этого датчика не должны иметь электрического кантакта с электродом/пластиной. Но, далее, измеренное значение передается по радиоканалу. Т.е. сам датчик гальванически развязан от внешнего устройства. Получаем систему: электород гальваничесчки развязан от датчика , а датчик гальваничечки развязан от внешнего устройства. Смысыл городить БЕСКОНТАКТНЫЙ датчик, если он и так развязан от внешнего устройства? Почему бы не сделать контактный датчик который и так ни с чем не имеет контакта, кроме как с электродом/пластиной? Или требуется обслуживать этот датчик в то время, когда на электроде высокое напряжение?

на этом форуме есть конкретная ветка для вопросов по АД. Костыль. Если будешь делать перенумерацию листов, или вставишь куда-нибудь в начало новый лист - не забудь в рукопашку проползти по всем листам и исправить коменты. Вообще 100% соблюсти ГОСТ в АД (как и в PCAD) можно только через костыли, которые ещё придется подпирать костылями. Работая на одном предприятии, мы схемы в кад системе рисовали только для трассировки, а оформляли по ГОСТ-ам в графическом векторном редакторе (корелДро или инкскэйп). На другом предприятии было принято решение оформлять все схемы в АД без костылей, но c отступами от ГОСТ-ов. например есть в АД такая няшка как многоканальные схемы. Всего 2 листа. Например на главном листе порт IN - это и есть обозначения перехода на др лист. ни чего общего с гостом. на схеме драйвера также переход на др лист обозначен портом IN. На обычных одноканальных схемах обозначаем переход на др лист через порт.

Ну и спор!!! Говорим об одном и томже. Я, Еще раз Вам объясняю. Если на входе УАРТа возникает отрицательный перепад напрядения, то он обязан начинать определять стартовый бит. Так он устроен и другого быть не должно! . и ещё раз Если на входе УАРТа возникает отрицательный перепад напрядения, то он обязан начинать определять стартовый бит. Именно ОБЯЗАН НАЧИНАТЬ, а не должен определить. в этом часть проблемы. во первых - по иголке уарт не должен определять стартовый бит. И давайте об этом спорить не будем. Если Вы считаете что должен - флаг вам в руки. Я считаю что не должен. Я написал свой уарт который, как Вы гоыорите, за битовый интервал берутся 3 отсчета ... и они мажоритируются и проблем с иголками нет. И в этом меня не надо переубежнать и я вас не собираюсь. останимся при своих. НО во-вторых: пришла иголка и после неё уровень лог "1" в течении длительного времени, допустим в течении ОДНОГО часа. Если по этой иголке, уарт должен решить что пришол старт бит. Пусть будет так. Тогда уарт через длительность одного байта должен принять байт, и это должен быть 0xff. Пришол стартовы бит - приняли байт. Но в случае альтеровского уарта этого не происходит. после иголки уарт не дает ни прирывания, не меняет свои статусные регистры, не меняет приемный регистр. У него меняются внутренние регистры и он переходит в говносотояние, которое можно определить только сигналтабом. И в этом говносотоянии он будет находится вплоть до следующего байта на RxD, а это может быть 1мс, 1минута, 1 час, 3 дня.... И с высокой вероятностью альтеровский уарт находясь в говносотоянии не примет нормальный байт. ps вот вариант реализации уарта. Ни каких вопросов, ни каких говносотояний. Так он устроен и другого быть не должно! Ну мк51 уже был.

Пересортировал согласно рекомендации - не помогло. Кто делал свои модули для Qsys/SOPC? Как сделать так, чтобы заголовочные файлы попадали в BSP? У меня ы sw.tcl есть команды create_driver MODBUS_Slave_driver set_sw_property hw_class_name MODBUS_Slave Но в BSP Editor-e на вкладке Drivers напротив моего модуля MODBUS_Slave стоит имя драйвера и версия none, а также нет галки Enable. см рис.

Эта проблема именно UART-а. Эту тему уже обсуждали. Да, вот именно.... старт импульс должен определятся либо в середине битового импульса, либо из 3-х выборок в середине бита. Но УАРТ альтеры начинает принимать после отрицательного фронта. Достаточно ложного импульса в 1 такт на 50 МГц. Причем ладно бы уарт по ложному импульсу принял бы ложный байт. Но альтеровский уарт по ложному импульсу кагбэ подвисает. может прийти иголка и уарт стартанёт, но байт он не примет. потом в линии будет тишина 1 час. Потом придет первый байт и будет ошибка кадрирования, хотя по осциллографу на входе уарта картинка эталонная - все времена выдержаны, все уровни, фронты.... всё ОК. Ни разу в жизни не видел фильтр на вход уарта. Все эти, как вы говорите "фильтры" делаются в контроллере. в авр, мсп430, мк51, пик и т.п. Посмотрите мою тему по этому поводу. См в ней осциллограммы. Ни какой экран не поможет защитится от этих помех. Помеха возникает при переключении драйвера. ваши экраны, гальваническая развязка и т.п. - не помогут. К тому же RS-485 это витая пара, а витая пара как известно более устойчива к помехам. Я написал тестовый проект, в котором имитировал ложный импульс в 1 такт. И альтеровский уарт улетел от этой "иголки". Тестовый проект и картинки результата в сигналтабе см в моей теме. Я отписал багрепорт в Альтеру. Сказали что разберутся. прошло.... уже полгода - тишина!

Написал свой модуль *_hw.tcl для SOPC. set_module_property DESCRIPTION "" set_module_property NAME MODBUS_Slave set_module_property VERSION 11.0 set_module_property GROUP User_components set_module_property AUTHOR Juvf set_module_property ICON_PATH gmo.png set_module_property DISPLAY_NAME MODBUS_Avalon set_module_property TOP_LEVEL_HDL_FILE modbusAvalon.v set_module_property TOP_LEVEL_HDL_MODULE modbusAvalon set_module_property EDITABLE false set_module_property SIMULATION_MODEL_IN_VERILOG false set_module_property SIMULATION_MODEL_IN_VHDL false set_module_property SIMULATION_MODEL_HAS_TULIPS false set_module_property SIMULATION_MODEL_IS_OBFUSCATED false Написал реализацию *.v. Для записи/чтения регистров своего модуля использую макросы IOWR_32DIRECT. Хотелось бы определить более понятные макросы, типа IOWR_MODBUS_AVALON_RXADDRESS. Определил в своем самописном модуле инклуде #ifndef __MODBUS_AVALON_REGS_H__ #define __MODBUS_AVALON_REGS_H__ #include <io.h> #define IOWR_MODBUS_AVALON_RXADDRESS(base, data) IOWR(base, 28, data) #endif /* __MODBUS_AVALON_REGS_H__ */ Написал свой *_sw.tcl # Create a new driver create_driver MODBUS_Slave_driver set_sw_property hw_class_name MODBUS_Slave set_sw_property version 11.0 set_sw_property min_compatible_hw_version 0.1 set_sw_property auto_initialize false set_sw_property bsp_subdirectory drivers set_sw_property supported_interrupt_apis "legacy_interrupt_api enhanced_interrupt_api" add_sw_property include_source inc/modbus_avalon_regs.h add_sw_property supported_bsp_type HAL Вроде всё правильно. ожидаю что в проекте BSP в папке include появится мой *.h файл. Но его не. не копируется он из паки модуля в проект. Что делаю не так? Как сделать так, чтобы в проекте появился мой инклуде с определениями?

Недавно такая же проблема была. собрал в qsys проц назвал его cpuSOPC. Добавил в проект ква файл cpuSOPC.qsys из корня проекта. Ква тоже писал, что не может найти мой компанент. Оказалось нужно было добавлять в проект не cpuSOPC.qsys, а /cpuSOPC/synthesis/cpuSOPC.qip

у меня валяется какаято корка fifoed_avalon_uart "FIFOed UART (RS-232 serial port)9.3" v9.3, с опенкорс качал. Вроде все ваши нужды покрывает. Посмотрел вашу реализацию.... Не совсем понятно как это иинтегрируется в SOPC? Как этот уарт внедрить в NIOS? Начал свою реализачию делать через *_hw.tcl. Вопрос возник. У вас 2 шины, у меня 1. Сделал шину Avalon-MM slave. Её подключил к ядру ниоса и её же подключил к DMA. Воде авалон позволяет двух мастеров на шине иметь и колизии автоматом разруливаются. Будет так работать или обязятельно для кантроля нужна одна шина, а для DMA отдельная?

Как бы организовать умный уарт для ниоса? нужен уарт, который бы принимал данные и по ДМА складывал бы их в определённое место в озу. как только после последнего принятого байта пройдет определённое время, уарт должен генерировать прерывание. А при передаче хотелось бы загрузить пакет в озу и "дернуть старт". данные из озу по дма сами ми бы переправлялись в уарт. после передачи всего пакета уарт (или дма) генерировал бы прерывание или снимал бы флаг бизи. Ну до кучи можно аппаратно управлять внешним драйвером ~RE/TE. Есть мысли написать свой модуль уарт и посадить его на шину авалон. Только с чего начинать? как свои подобные модули делать? в QSys нужно добавить какойто контроллер авалон и на него цеплять свой модуль? Или сразу свой модуль писать с авалон-слейвом?

Если ещё актуально.... Да, со стандартным загрузчиком EPCS всё прекрасно работает. Только некоторые чипы перестали шиться флешпрограмматором. Стал конвертировать sof и elf в hex-ы, а из хексов делаю jic. по вашей ссылке jic делается сразу из sof. уже не помню почему я делаю через хекс, но по мойму сразу из софа что-то не пошло. может вектора прерываний не правильно настроенны в BSP?

Я метками NET отмечаю только цепи внутри одной схемы (одного листа) и мне не приходится искать эту цепь по всем листам схемы. Если какая-то цепь должна уйти на др лист, то я её уважу через ПОРТ. Щелкая по порту CTRL+ЛКМ переключаюсь на тот лист, куда ведёт этот порт.

понял..... мне кажется изврат. можно таблом прощёлкать свою посылку. если между 2-мя пакетами будет пауза меньше 4-х символов, то пакеты склеются. нужно тогда запрос давать не раньше чем через 5 символов после предыдущей транзакции.

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

При приеме пакета (для RS485) использовать передачу при выключенном передатчике, - что то я фокуса не понял :laughing:

O!!!! А запилить контроллер в отдельном 8-ми ногом МК - что-то не догадался. Действиетльно... там даже не 2 уарта нада.... можно уарт + и2ц или спи. Спасибо за подсказку. дак так и делал. причем контролировал 2 интервала, ещё и 1,5 символов между байтами OCR1B = TCNT1 + TICKS_FOR_1_5_BYTE; Но когда много этих модбасов стекается в 1 устройство.... тут уже возникают трудности.

Довелось мне Modbus реализовывать в синтезируемом процессоре в плис. Думаю.... да зачем мне проц грузить модбасом? Считать там интервалы в 1,5 и в 3,5 символов. Сделал контроллер Modbus аппаратный. Т.е. приходит пакет, контроллер принимает, проц вообще не участвует в приеме. после пакета прошло времени в 3,5 символа и если между байтами внутри пакета не было пауз в 1,5 символа и если совпал crc и если адрес "мой", то контроллер выставляет прерывание процессору. процессор знает в каком месте его озу лежит готовый принятый пакет. Проц парсит пакет, обрабатывает, записывает в определённое место озу ответ и дает контроллеру "старт". Контроллер выплёвывает ответ в уарт, сам считает и отправляет crc. Контроллер сам управляет ногами DE/RE драйвера RS485. С таким контроллером работать с модбасом - ну просто красота. Доставляет. Протокол не новый и достаточно распространённый, не менее чем CAN. Но если нету плис - то и нету контроллера. вот и возник вопрос - не придумали ли ещё готовый, законченный контроллер MODBUS в каком нить SOIC-8? Или может существует какой-нибудь АРМ в котором есть аппаратный контроллер modbus?

Так это ни о чём не говорит. Что там в этих системах управления - это тоже вопрос. Там этот windows может быть использовать чисто для GUI. Всё остальное аппаратно. Не думаю что в каком нибудь осциллографе винда считывает с ацп по одной выборке, складывает в ОЗУ, фильтрует, и выводит на экран. Наверняка захват и обработка сигнала аппаратно. винде остается тока считать кнопки, задать правильный режим аппаратуре и по готовности данных отобразить их на экране.

на венде легко выставить приоритет задаче. можно выставить... как же он называется... . TimeCriticalPriority чтоли, ну или выше, чуть ли не реалтаймПриорити. При каком приоритете какие результаты? Какие результаты при самом высоком приоритете?

Вроде нашол как это сделать. в студии в свойствах проекта->Memory Setings->Memory segments Flash .bootloader 0xfd00 в eclipse для соответствующего сегмента нужно прописать "-Wl,-section-start=.bootloader=0x1fa00" в свойства проекта->c/c++ build->settings->tool settings->AVR C++ Linker->Other Arruments

Портирую проект из AVR Studio в Eclipse+AVR plugin. В студии в свойствах проекта->Memory Setings->Memory segments можно было добавить сегменты памяти. Как это делается в Eclipse?

Совершенно согласен с вашими рассуждениями... я тоже не представляю какого-то рационального решения при попытке переноса обработки событий на уровень ОС (я так понимаю, под "реалтаймовостью" подразумевается использование ОС)... Может, специалисты в "реалтаймовости" нам тут подскажут... Что такое поллинг? Это ожидание одной задачей несколько событий?.... Вот как ВАШ простой пример выглядел бы в FreeRTOS if( xSemaphoreTake((process2_end_packet_Flag , TIMEOUT) == pdPASS ) {//дождались события } else {//недождались события, вышел TIMEOUT } можно ждать и несколько событий.... пример на µС/OS uint8_t err; OSFlagPend(statusFlags, P2_END_PACKET | P2_BREAK_PACKET, OS_FLAG_WAIT_SET_ALL, TIMEOUT, &err); switch(err) { case OS_NO_ERR: //были УСТАНОВЛЕНЫ флаги P2_END_PACKET и P2_BREAK_PACKET до таймаута TIMEOUT break; case OS_TIMEOUT: default: //сработал таймаут или какая-то др. ошибка break; } ОС у задачи заберёт процессор (задача уснёт на мертво) в момент обращения к методу OSFlagPend() или xSemaphoreTake(). Как толко наступит нужное(ые) событие(я) или пройдет TIMEOUT времени с момента засыпания, то ОС сразуже сама разбудит задачу и передаст ей управление (при условии что нет незаблокированных более приоритетных задач).

при чем здесь детерминизм? ну будет таймер давать импульсы с точностью ±1*10^(-10000000000000000000000000000000) секунд. и что дальше..... примет обычный линукс это событие.... но у него там ещё к примеру 100 фоновых задач... сколько времени пройдет от импульса до выхода первого байта из порта? Если постучать бубном над приоритетами в линуксе, то можно назначить приоритет задаче отправляющей запрос (как в винде), но все равно, задача по отправке запроса получит больший слот времени, но не все 100% и время от прерывания до выхода первого байта запроса будет плавать. На сколько плавать? вопрос хороший... простой линукс изкоропки... без х11, 1 задача раз в 10 мс опрашивает устройства, 4 "фоновых" задачи по тсп отдают инфу. так задержки между опросами иногда получаются больше 100 мс, да и при передачи пакета.... по спецификации модбуса если в пакете между байтами пауза больше 1,5 символа, то пакет бракуется. на линуксе 1 задача постоянно шлет пакеты на скорости 921600..... так там постояк паузы до 2-3 символов. А настроить приоритеты на линуксе, даже без реал тайма - пока руки не дошли. *ЗАПЕСАЛ* а обычная винда какое колебание даёт? Измеряли?

ну уж тогда нужно говорить "linux" и "realtime Linux". Даже на вашей ссылке в одном месте слово линукс "Is realtime possible with Linux?" (даже в этом вопросе подрозумевается что обычный линукс не реалтаймовый), и на всем сайте они свой линукс называют "Realtime Linux". досы то разные бывают..... я просто думал что FreeDOS-32 многозадачный. ашипся, пока тока в планах ввести многозадачность.