tonyk_av

То есть пилит при отправке 5500, так что ли?

Ещё раз запустил сканер. Картина другая. 10мс есть. Пробовал менять её до 1с- разницы нет.

Вызов wizchip_gettimeout( &to ) дал вот такие результаты. Вроде, адекватные значения.

И вот так все посылки от 5500 к ПК. В чём может быть причина?

Есть требования по минимальному расстоянию между элементами. Есть между линиями. Всё есть в требованиях на схемы. Но это именно минимальны. Схемы читаются, но приходится напрягаться. И выглядят, ИМХО, не красиво.

Даже три. Третий _WIZCHIP_IO_MODE_SPI_5500_, хотя он, вроде, идентичен FDM. Пробовал это менять, никак не влияет. Зато в примерах работы с Модбас показаны именно целые, не фрагментированные, пакеты. И разбивка одной посылки как 4+4+2 настораживает. Видимо, есть какая-то настройка у этого 5500, которая влияет на это. Только вот какая, где она описана?

Я первый раз столкнулся с сетевым контроллером, который вместо отправки одного IP-пакета с 11 байтами разделил его на 3 пакета. Бред какой-то. Он ведь тупо засирает сеть этими пакетами. И как объяснить ему, чтобы он отправлял всю посылку зараз, ни где не вижу.

Никакого PuTTY тут нет. Есть моя прога, которая принимает пакет и выдаёт его на экран. Таймаутов у меня нет. Но есть FreeRTOS. Неужели из-зп неё? Видимо, без снифера не обойтись. Тогда почему 11 байт, которые я отправляю одним send(), на ПК принимаются тремя посылками?

Сервер на ПК получает 3 посылки. И так только с 5500, поэтому и говорю, что он, 5500, делит.

А с какого перепуга он делит? Размер посылки меньше MTU, зачем делить?

TCP. Не устраивает то, что одну посылку в 11 байт 5500 разделил аж на 3. В чём может быть причина?

Удивительное рядом. На W5500 работают 3 сокета, 2 как серверы, один как клиент. С серверными всё в порядке, вопросов нет. А вот с клиентским чё-то непонятное. Вызов send() на W5500 для буфера размером 11 байт возвращает, ессно, 11. А вот сервер, к которому подключен W5500 через коммутатор, получает аж 3 посылки, то есть изначальные 11 байт дробятся на 3 посылки. Есть идеи куда рыть?

Ещё бы схемы приложил. А то, судя по тексту, МК и дисплей запитаны от разных LDO.

Я ищу способ сброса любого девайса на шине путём подачи определённой последовательности "0" и "1" на шине. Видимо, кроме старт-стопа ничего сделать не получится. Просто мне достались модули, у которых "Reset" тупо подключен к "+" питания, а они иногда уходят со связи. Ладно, сегодня пятница-развратница, поэтому будем пробовать технику старт-стоп.

Хм, получается, что если девайс перестал общаться и на SDA=SCL="1", то нужно выдать "старт", а потом "стоп", так что ли?

А где в нём описана процедура сброса слэйва?

Нет. На SDA и SCL высокий уровень. Попадались упоминания первой редакции стандарта I2C от Филипс, в котором был описан алгоритм сброса конечного автомата слэйва в исходное состояние, но я не могу найти ни тот, ни другой какой-нибудь документ с описанием этого алгоритма.

Всем привет! Пожалуйста, ткните ссылкой в документ, в котором описана процедура сброса устройства, переставшего отвечать.

А где можно взять документацию, в которой более-менее внятно были бы описан порядок портирования Beremiz?

Я претензий ни кому не предъявляю. Вижу, что здесь куча умников, а не знатоков, которые могут поправить ошибку человека. Буду искать помощи в другом месте. Тема закрыта.

Я же поправил #define configTOTAL_HEAP_SIZE ( ( size_t ) 1 * 1024 ) - прошу 4К Или это не 4К? Посмотрел ссылку. Там конфиг для gcc, а у меня Keil с Армовским компилятором. Есть и проект FreeRTOS под gcc, но там Startup сильно отличается от того, что в Keil. Я потому и прошу помощи, что изучать ассемблер ради поиска лишнего нолика в каком-то файле для меня на данном этапе- непозволительная роскошь. Видите ошибку - укажите на неё, а указывать менторским стилем на 24К без указания на то, откуда взята эта цифра, простите, моветон.

Проверил. Было #define configTOTAL_HEAP_SIZE ( ( size_t ) 4 * 1024 ) - просил 16К Стало #define configTOTAL_HEAP_SIZE ( ( size_t ) 1 * 1024 ) - прошу 4К Раскладка памяти: Результат тот же. Куда рыть?

Коллеги! Давно не работал с микроконтроллерами, но вот пришлось... Последним был ADuC845 на ядре MCS-51. Сейчас пришлось осваивать LPC2103. Учитывая то, что мне предстоит дальше, решил сразу начать работу под FreeRTOS. Эту штуку использовал раньше под AVR и остался вполне доволен. Для 51-ых программировал под Keil, решил и тут воспользоваться им. И тут началось... С архитектурой ARM7 пока знаком плохо, поэтому не могу понять причину вылета в DAbt_Handler при вызове vPortStartFirstTask(). Дайте пинка, чтоб я смог взлететь! Растолкуйте, в чём причина ошибки и как её исправить. Проект во вложении. 8DI.ZIP