Neo_Matrix

Я не обижаюсь, но вести бесполезную дискуссию не вижу смысла. Лучше поработать или почитать что то чем набивать рейт сообщений на форуме.

Пишите дальше... Вопрос был не вам задан, потому ответа жду не от вас. Удачи.

Не очень понятен сарказм, особенно как для "гуру с 3к+ сообщений". Взять паяльник, впаять и прошить, вы можете в своих поделках. Я задал вполне логичный вопрос, который позволяет сэкономить время перехода на другой чип не сравнивая 2 мануала. STM даже внутри своих серий дает Migration of applications from XXXX Series to YYYY Series, что позволяет быстро поправить код под другую серию, запустить в тест, а потом уже читать даташит, перед запуском в прод.

А есть ли апноут по переходу с STM на APM32F407? Так же не нашел ерраты или китайцы настолько круты, что не одной ошибки нет в узлах.

Jcxz успокойтесь, уже разобрался благодаря arlleex, который подсказал, что multibuffer и double buffer не одно и то же. Тему можно закрывать.

В целом понятно. Нужно просто попробовать включить прерывания, сделать ошибки каким либо образом и посмотреть что будет происходить, тогда будет точно ясно, как оно работает :) Ого, даже так. А я то думал, что мультибуфер это и есть двойная буферизация для uart

В rm сказано не двузначно, последовательным чтением sr -> dr или записью в rxne нуля. Так что если dma не вычитывает sr как утверждает arlleex тогда пишит 0 в rxne

Тогда не понятно как сбросить флаг ошибки и обязательно ли применять двойной буфер для этих целей? Думал использовать кольцевой без фифо. ПС. В каком байте произошла ошибка абсолютно не важно, важно знать их кол-во за промежуток времени. Как тогда dma сбрасывает флаги готовности? Записью 0 в sr? И если сбросить этот флаг заранее что будет с dma? Как сбросить в режиме мультибуфера нашел, записью 0 в rxne. Остается вопрос обязательно ли использовать мультибуфер?

Возникла задача использовать dma для передачи данных по uart, но параллельно необходимо отслеживать ошибки ne, fe, так как линия сильно зашумлена. Это необходимо для дальнейшей подстройки некоторых параметров самой линии аналитически. Но если используется dma, тогда контроллер сам проверяет флаг статуса байта в регистре sr и читает регистр dr, что приводит к сбросу флагов ошибок. Можно конечно поставить высокий приоритет прерывания uart контроллера, но как тогда в нем очистить флаги ошибок? Если прочитать sr->dr тогда контроллер dma не примет текущий байт (который может быть вовсе не спорченным) или передача вовсе прекратится так как у контроллера dma из под носа очистять флаг в регистре sr. Какие есть варианты отследить ошибки линии ?

Спасибо. В целом так и предполагал, просто первое что пришло на ум, это MPU

Копировать весь код и содержимое всех макросов достаточно накладно, скопирую основное. Это структура, внутри нее объединение, так что размер не велик, хотя и выглядит ужасающе. struct pppapi_msg_msg { ppp_pcb *ppp; union { #if PPP_NOTIFY_PHASE struct { ppp_notify_phase_cb_fn notify_phase_cb; } setnotifyphasecb; #endif /* PPP_NOTIFY_PHASE */ #if PPPOS_SUPPORT struct { struct netif *pppif; pppos_output_cb_fn output_cb; ppp_link_status_cb_fn link_status_cb; void *ctx_cb; } serialcreate; #endif /* PPPOS_SUPPORT */ #if PPPOE_SUPPORT struct { struct netif *pppif; struct netif *ethif; const char *service_name; const char *concentrator_name; ppp_link_status_cb_fn link_status_cb; void *ctx_cb; } ethernetcreate; #endif /* PPPOE_SUPPORT */ #if PPPOL2TP_SUPPORT struct { struct netif *pppif; struct netif *netif; API_MSG_M_DEF_C(ip_addr_t, ipaddr); u16_t port; #if PPPOL2TP_AUTH_SUPPORT const u8_t *secret; u8_t secret_len; #endif /* PPPOL2TP_AUTH_SUPPORT */ ppp_link_status_cb_fn link_status_cb; void *ctx_cb; } l2tpcreate; #endif /* PPPOL2TP_SUPPORT */ struct { u16_t holdoff; } connect; struct { u8_t nocarrier; } close; struct { u8_t cmd; void *arg; } ioctl; } msg; }; struct pppapi_msg { struct tcpip_api_call_data call; struct pppapi_msg_msg msg; }; Это некоторые макросы: #define PPPAPI_VAR_REF(name) API_VAR_REF(name) #define PPPAPI_VAR_DECLARE(name) API_VAR_DECLARE(struct pppapi_msg, name) #define PPPAPI_VAR_ALLOC(name) API_VAR_ALLOC_POOL(struct pppapi_msg, PPPAPI_MSG, name, ERR_MEM) #define PPPAPI_VAR_ALLOC_RETURN_NULL(name) API_VAR_ALLOC_POOL(struct pppapi_msg, PPPAPI_MSG, name, NULL) #define PPPAPI_VAR_FREE(name) API_VAR_FREE_POOL(PPPAPI_MSG, name) #define API_VAR_REF(name) (*(name)) #define API_VAR_DECLARE(type, name) type * name #define API_VAR_ALLOC_EXT(type, pool, name, errorblock) do { \ name = (type *)memp_malloc(pool); \ if (name == NULL) { \ errorblock; \ } \ } while(0) #define API_VAR_ALLOC(type, pool, name, errorval) API_VAR_ALLOC_EXT(type, pool, name, return errorval) #define API_VAR_ALLOC_POOL(type, pool, name, errorval) do { \ name = (type *)LWIP_MEMPOOL_ALLOC(pool); \ if (name == NULL) { \ return errorval; \ } \ } while(0) #define API_VAR_FREE(pool, name) memp_free(pool, name)

Как альтернатива можно Ваш log_printf написать в виде макроопределения. У меня сделано так, можете добавить в него свой семафор. Так же нужно подключить хидер с гитхаба: https://github.com/willwray/VA_OPT #define DEBUG_PRINTF(use, fmt, ...) do {if(use != 0U) printf(fmt, ##__VA_ARGS__);} while(0U) Возможно не будет работать на всех компиляторах.

Рассматривал реализацию работы в стеке LWIP API, при вызовах API функций LWIP, можно встретить следующий код: err_t pppapi_close(ppp_pcb *pcb, u8_t nocarrier) { err_t err; PPPAPI_VAR_DECLARE(msg); PPPAPI_VAR_ALLOC(msg); PPPAPI_VAR_REF(msg).msg.ppp = pcb; PPPAPI_VAR_REF(msg).msg.msg.close.nocarrier = nocarrier; err = tcpip_api_call(pppapi_do_ppp_close, &PPPAPI_VAR_REF(msg).call); PPPAPI_VAR_FREE(msg); return err; } Внутри макроса PPPAPI_VAR_ALLOC вызывается malloc с соответствующими проверками, далее идет вызов функции tcpip_api_call из контекста задачи TCPIP, после вызывается макрос PPPAPI_VAR_FREE который внутри вызывает free с соответствующими проверками. Из кода видно,что зона видимости(существования) переменной msg ограничивается текущей функцией, соответственно возникает вопрос, для чего создавать переменную в динамической памяти, с возможной фрагментацией оной, если можно просто создать переменную на СТЕКЕ задачи, с такой же областью видимости? Или это необходимо для процессоров с MPU?

Спасибо. К сожалению Питер, это слишком далеко. Да и с растаможкой будут оч. большие проблемы если речь и о производстве.

Ищу производителя пластиковых корпусов для РЭА, так же приветствутся свои специалисты по проэктированию. Первый тираж предпологается около 500шт, при определенных условиях до 1000шт. Если производители есть в ветке, прошу указать ориетировочную цену(можно в личку) на прессформу и отдельно цену за проэктирование, если такая услуга предоставляется. Размер от 80х80х40 до 100х100х60, окончательного проэкта пока нет. Корпус без подвижных частей, будет жк-дисплей+сенсор. Предполотается что будет минималистичная лицевая панель и достаточно сложная нижняя часть(много разъемов для подключений).

Посмотрите на производителя Бахар.

Алиэкспресс и продакшн на тысячи устройств, а тем более с циклом выпуска в 3-4 года явно не совместимы. Если даже контроллер поменяется и под него можно будет сделать новый драйвер, то делать новую плату, а тем более новый корпус+новую прессформу это уже не так просто. Банальные ncp551 на 2.8 вольта, когда пропали с продажи это был достаточно большой головняк, найти стабильную замену.

Помогите подобрать серийный вариант дисплея с разрешением 320х240(можно больше) и диагональю 3.1-3.5", приоритетный размер 3.5". Наличие емкостного сенсора обязательно, можно рассмотреть как независимое устройство. Температурный диапазон от -5 до +70, готов и более узкий вариант. Стоимость до 30, максимум 50$

Подыму старую тему. На данных макетках этот эффект проявляется почти со всеми припоями, потому как отверстия у них слишком большого диаметра и туда попадает припой с флюсом. Флюс закипает и начинает пузырится, паять их достаточно сложно, потому не рекомендую их для использования, точно такие же макетки на одностороннем тектолите без метализации ведут себя адекватно, может будет кому то полезным.

За лазерный маркировщик спасибо, узнаю, может есть у монтажной организации. А счего вдруг после едкого натра выбрасывать плату? Он медь не должен разъедать. Сколько плат дома переделал, сначала лутом, потом перешел на фоторезит, остатки которого смывал едким натром, ни разу нечего не окислилось после него. И я же не сказал, что всю плату засунуть в него, а заказать высечку со скотча по форме КП и снять локально каплей, остатки промыть водой, локально можно протереть одипинкой, лимонкой.

К сожалению платы не "колхозные", 4х слойные. Маска с них очень плохо слазит, а плат порядка 100штук, первая крупная пробная партия устройств. На самой первой просмотрели ошибку, так как керамика 0603 быстренько отгорала от перенапряжения, а на вход подавалось нормально фильтрованное напряжение. Зачисть скальпелем 100 плат не оч. приятное занятие, думал может каплей едкого натра повытравливать маску? Можно со скотча заказать высечку в виде посадочного места наклеить и залить натром? Или есть растворитель для маски? К сожалению не выйдет, мы не в России работаем.

Произошла ошибка при трассировке платы и вместо конденсатора в корпусе C(тантал) было сделанно посадочное место под 0603(керамика). Плат достаточно много, потому выбрасывать дорого, все платы предназначены под автоматический монтаж. В том месте где должен припаиватся конденсатор расположены полигоны достаточной ширины для напаивания тантала. Проблема в маске, каким образом можно снять частично маску с полигонов для ручного домонтажа конденсатора?

Подскажите, имеется ли у чипа AT91SAM9G25 защита от чтения прошивки? Если таковой нет подскажите недорогие чипы аналогичного уровня с такой возможностью и желательно продающиеся в виде готового модуля, например как эти: https://www.acmesystems.it/catalog_aria

Прошивал бутлоадер из этого репа ранее. Как ни странно перепрошил его еще раз и он стал определятся, как и должен версии 9,5. Но SPI флешки по прежнему не прошивает. Может что то выгорело ранее, а я не заметил этого. Так как STM.... прошивает без проблем. Или лицензии не хватает.... Вот фото платы:

Версии 9.2 и 9.5 отличаются по схемотехнике, не принципиально, прошивка у них одинаковая. У вас, вероятнее всего, при прошивке изменился серийный номер. Если весе работает - оставляйте как есть. Серийный понятное дело что слетел, но я восстановил прежний, что там был. И добавил лицензии. Работает как то странно, через несколько включений/выключений к ЮСБ софтина выдает что прошивка испорчена и требует восстановления, после перепрошивает и некоторое время работает нормально, потом цикл повторяется. Отладка по swd/o работает нормально. Но вот сегодня пробовал прошить spi флеху, так он с нее читает ff ff ff и пишет, что неизвестный чип памяти.