adnega

Что ж остается лишь пожелать вам удачи.

Дык, вы же их обрабатываете без проблем. Просто вы хотите параллельно зачем-то сгенерить гораздо большую по объему отладочную информацию и успеть ее выплюнуть. Старайтесь в отладку выкидывать только ошибки и результат обработчика HardFault. Что вам мешает подключиться к uart от модема и записывать весь обмен, а затем его обрабатывать (в том числе и с помощью спецутилит)? Дык, попытайтесь писать суть, а не "много букв". Не всегда, чем длиннее текст, тем там больше информации. Как называется ваша тема? И при чем тут printf, когда причина у вас в совершенно другом месте? Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать. У меня позиция, что отвечая на форуме - помогаешь не ТС, а всем, т.к. кто-то может столкнуться с аналогичной проблемой в будущем.

Еще в посте #9 уважаемый jcxz посоветовал проверить консерваторию. Я полностью поддерживаю его совет, а от себя посоветовал бы не переходить на необоснованное хамство в отношении людей. Подход, который вы используете не годится для решения коммерческих задач, а поскольку у вас есть руководство, то осмелюсь предположить, что ваша задачка не поделка выходного для. Если вы для себя или для начальства хотите получить подтверждение "эта задача не может быть решена", то вы ошибаетесь - задача элементарная, но вы решаете ее не с того края, отсюда и сложности. Попробуйте успокоиться и понять, что вам советуют. Я сам в том месяце работал с ESP8266 и МК уровня STM32F0. От сервера приходят UDP-пакеты и я на каждый должен ответить. Но пока я отвечаю на предыдущий, ко мне может прилетесь еще несколько новых. Памяти на всех нет в принципе. Поэтому, получив и обработав пакет, я помечаю, что нужно отправить ответ (один флаг). Получив другие пакеты - обрабатываю их и устанавливаю соответствующие флаги. Когда есть возможность отправить ответ, смотрю первый попавшийся флаг и отправляю соответствующий ответ сбросив флаг. Расход памяти минимальный, все пакеты обрабатываются, никто не теряется, никаких задержек нет. Предыдущий код требовал, чтобы сервер не отправлял UDP-пакет, не получив ответ на предыдущий, т.к. буфера перетерались. Все решает грамотная архитектура, а необходимость задержек, зависимость от размера буферов и т.п. являются свидетельством неграмотной архитектуры или ее отсутствия. Кто-то называет это консерваторией. Подход "через сутки разберусь, а дальше меня не волнует" тоже не признак профессионализма. Завтра начальство захочет новую фичу, и вы с большой вероятностью не сможете ее добавить, т.к. ваш подход обладает плохой масштабируемостью. Пару раз по банальным фичам ответите начальству отказом - на вашем месте будет работать другой программист. Оно вам надо?

Вы можете стандартными средствами TCP притормозить выдачу данных удаленной стороной, чтобы она вам буфер не перезаписывала.

А по какому каналу связь с сервером? Какой протокол?

Я писал так void USART2_IRQHandler(void) { if(USART2->ISR & (1 << USART_ISR_TXE)) { if(con.tx_t != con.tx_b) USART2->TDR = bl_export.bl_sp_tx_pop(&con); else USART2->CR1 &= ~(1 << USART_CR1_TXEIE); } if(USART2->ISR & (1 << USART_ISR_ORE)) { USART2->ICR = (1 << USART_ISR_ORE); } if(USART2->ISR & (1 << USART_ISR_RXNE)) { con.rx_tm = 0; bl_export.bl_sp_rx_push(&con, USART2->RDR); } } push и pop помещают и извлекают байты из кольцевых буферов tx и rx.

Я при помощи STM32F103C8 гнал поток 2.25 Мбод (RX замкнут с TX). Ни один байт не потерялся за значительное время.

А вы уверены, что теряет не приемная сторона?

Старайтесь не грузить шину более 70%. При высоких помехах пакеты могут теряться и их нужно будет передавать повторно (это может сделать контроллер CAN самостоятельно) - нужно, чтобы какой-то резерв был. С учетом обоих вопросов: Я бы сделал разделение приоритетов для слейвов. В Идентификаторе выделил бы один из старших битов под приоритет пакета с координатами, т.е. все более старшие биты идентификатора должны быть у всех узлов, передающих пакет с координатой одинаковым, затем один бит приоритета (0 - высокий, 1 - низкий), остальные младшие биты могут быть адресом узла (идентификатор должен быть уникальным). Каждый четный пакет передавать с высоким приоритетом, а каждый нечетный с низким приоритетом. Итого: если все хорошо - все пакеты всех узлов куда надо дойдут с максимальной частотой дискретизации. Если будут какие-то уплотнения (загрузка шины >100%), то сначала пострадает низкоприоритетный трафик, что приведет к тому, что часть узлов будут передавать с низкой частотой дискретизации, но гарантируется, что высокоприоритетный трафик не будет резаться, пока не срежется низкоприоритетный трафик со всех узлов.

У SIMCOM это называется EAT. Можно писать свое, довольно сложное приложение, а модуль будет его исполнять. Можно не только принимать/отправлять SMS, можно заставить модуль говорить. Например, SIM800C (там несколько моделей, желательно брать с памятью 32М).

Просто нужно понимать, что слейвы могут слать данные и без запроса. Например, мастер может сказать слейву: шли такие-то данные с такой-то периодичностью столько-то раз. У меня каждое устройство (узел) раз в секунду шлет SYNC-пакет с идентификационной информацией. Мастер (я его/их называю Сервером) получает все SYNC-пакеты, пересбрасывает таймеры в таблице узлов, при необходимости добавляет новые узлы в таблицу узлов, генерит сообщения "пропала/восстановлена" связь с узлом. Если таймер в таблице узлов досчитал до 10 секунд, то это означает, что узел не пресылает SYNC-пакеты уже 10 секунд, а значит его нет.

У вас реалтайм-система или как? Я делаю так как писали выше. Контроллеры сами с нужной частотой шлют данные. Мастер пакеты получает и перезапускает таймеры для каждого слейва. В любой момент мастер имеет информацию о "свежести" данных и может либо их использовать, либо сигнализировать о потере связи со слейвом.

Добавить в пакеты поле "идентификатор запроса".

Дык, достаточно подключиться логическим анализатором к любому картридеру с картой.

Вы передаете карточке в CMD3 нулевой RCA, в ответ карточка вернет в старших 16 битах новый RCA, который нужно передавать в качестве аргумента в последующие CMD9, CMD13 и т.п. В вашем очень подробном первом посте не хватает ответа на CMD3. Получается, что RCA=0xDA 0x71. Мне это подозрительно. Я за RCA не следил, но мне кажется там должно быть что-то типа 0x0001.

А какой card_rca вы передаете в параметрах команд CMD3 и CMD9? В остальном порядок команд правильный. Карты в ПК работают?

Действительно, реальная карта очень медленная. Т.е. по быстрому интерфейсу ей прилетает команда, спустя какое-то время карта по быстрому интерфейсу отвечает, а данные сектора выдаст гораааздо позже, но очень быстро. Применение SDIO в связке с DMA позволяет сильно разгрузить МК, хотя я делал и на SPI+DMA+ISR с деревом из callback-функций. С учетом того, что карта может приспокойно "задуматься" на полсекунды даже в режиме чтения, jcxz весьма справедлив.

А смысл обсуждать это? Есть стандарт - нужно ему следовать. Если 4 вычислителя не охота делать принципиально, то можно с картой общаться в SPI-режиме, и вообще без какой-либо проверки.

Рекомендую ознакомиться с SD Specifications Part 1 Physical Layer Simplified Specification Version 3.01: Более подробно про разные CRC описано в разделе 4.5 Cyclic Redundancy Code (CRC).

Я Колбана про ESP8266 читал в свое время. Хотя не носитель, но читалось легко.

Судя по всему, начинается с "0".

Крайне рекомендую залить blank.bin с адреса 0x10000. У меня без этого модуль не запускался. Либо полный erase.

Потерять на запуск USART день и говорить, что "мне даже нравится". Чего-то я не пойму плюсов от таких библиотек. //----------------------------------------------------------------------------- // void init_USART1(void) //----------------------------------------------------------------------------- void init_USART1(void) { if(rcc_state == RCC_STATE_PLL) USART1->BRR = FPLL / CONSOLE_BAUD; else USART1->BRR = FHSI / CONSOLE_BAUD; USART1->CR1 = (1 << USART_CR1_UE) | (1 << USART_CR1_TE) | (1 << USART_CR1_RE) | (1 << USART_CR1_RXNEIE); USART1->CR2 = 0; USART1->CR3 = 0; }

Внешней утилитой.

Если в системе координат, заданных ТС (хочу многопроцессорную систему с разделяемой памятью и широкой полосой; масштабируемую), то очень сложно. Заметно упростить можно переформулировкой: есть какие-то блоки, они могут получать данные и их обрабатывать, результатом работы блоки могут делиться с другими. Если данных много, то легче сделать на Ethernet; если очень мало, то на CAN.