Jump to content

    

Neo_Matrix

Участник
  • Content Count

    141
  • Joined

  • Last visited

Community Reputation

0 Обычный

1 Follower

About Neo_Matrix

  • Rank
    Частый гость
  • Birthday 08/10/1985

Информация

  • Город
    Array

Recent Profile Visitors

1922 profile views
  1. Jcxz успокойтесь, уже разобрался благодаря arlleex, который подсказал, что multibuffer и double buffer не одно и то же. Тему можно закрывать.
  2. В целом понятно. Нужно просто попробовать включить прерывания, сделать ошибки каким либо образом и посмотреть что будет происходить, тогда будет точно ясно, как оно работает :) Ого, даже так. А я то думал, что мультибуфер это и есть двойная буферизация для uart
  3. В rm сказано не двузначно, последовательным чтением sr -> dr или записью в rxne нуля. Так что если dma не вычитывает sr как утверждает arlleex тогда пишит 0 в rxne
  4. Тогда не понятно как сбросить флаг ошибки и обязательно ли применять двойной буфер для этих целей? Думал использовать кольцевой без фифо. ПС. В каком байте произошла ошибка абсолютно не важно, важно знать их кол-во за промежуток времени. Как тогда dma сбрасывает флаги готовности? Записью 0 в sr? И если сбросить этот флаг заранее что будет с dma? Как сбросить в режиме мультибуфера нашел, записью 0 в rxne. Остается вопрос обязательно ли использовать мультибуфер?
  5. Возникла задача использовать dma для передачи данных по uart, но параллельно необходимо отслеживать ошибки ne, fe, так как линия сильно зашумлена. Это необходимо для дальнейшей подстройки некоторых параметров самой линии аналитически. Но если используется dma, тогда контроллер сам проверяет флаг статуса байта в регистре sr и читает регистр dr, что приводит к сбросу флагов ошибок. Можно конечно поставить высокий приоритет прерывания uart контроллера, но как тогда в нем очистить флаги ошибок? Если прочитать sr->dr тогда контроллер dma не примет текущий байт (который может быть вовсе не спорченным) или передача вовсе прекратится так как у контроллера dma из под носа очистять флаг в регистре sr. Какие есть варианты отследить ошибки линии ?
  6. Спасибо. В целом так и предполагал, просто первое что пришло на ум, это MPU
  7. Копировать весь код и содержимое всех макросов достаточно накладно, скопирую основное. Это структура, внутри нее объединение, так что размер не велик, хотя и выглядит ужасающе. 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)
  8. Как альтернатива можно Ваш log_printf написать в виде макроопределения. У меня сделано так, можете добавить в него свой семафор. Так же нужно подключить хидер с гитхаба: https://github.com/willwray/VA_OPT #define DEBUG_PRINTF(use, fmt, ...) do {if(use != 0U) printf(fmt, ##__VA_ARGS__);} while(0U) Возможно не будет работать на всех компиляторах.
  9. Рассматривал реализацию работы в стеке 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?
  10. Спасибо. К сожалению Питер, это слишком далеко. Да и с растаможкой будут оч. большие проблемы если речь и о производстве.
  11. Ищу производителя пластиковых корпусов для РЭА, так же приветствутся свои специалисты по проэктированию. Первый тираж предпологается около 500шт, при определенных условиях до 1000шт. Если производители есть в ветке, прошу указать ориетировочную цену(можно в личку) на прессформу и отдельно цену за проэктирование, если такая услуга предоставляется. Размер от 80х80х40 до 100х100х60, окончательного проэкта пока нет. Корпус без подвижных частей, будет жк-дисплей+сенсор. Предполотается что будет минималистичная лицевая панель и достаточно сложная нижняя часть(много разъемов для подключений).
  12. Алиэкспресс и продакшн на тысячи устройств, а тем более с циклом выпуска в 3-4 года явно не совместимы. Если даже контроллер поменяется и под него можно будет сделать новый драйвер, то делать новую плату, а тем более новый корпус+новую прессформу это уже не так просто. Банальные ncp551 на 2.8 вольта, когда пропали с продажи это был достаточно большой головняк, найти стабильную замену.
  13. Помогите подобрать серийный вариант дисплея с разрешением 320х240(можно больше) и диагональю 3.1-3.5", приоритетный размер 3.5". Наличие емкостного сенсора обязательно, можно рассмотреть как независимое устройство. Температурный диапазон от -5 до +70, готов и более узкий вариант. Стоимость до 30, максимум 50$
  14. Подыму старую тему. На данных макетках этот эффект проявляется почти со всеми припоями, потому как отверстия у них слишком большого диаметра и туда попадает припой с флюсом. Флюс закипает и начинает пузырится, паять их достаточно сложно, потому не рекомендую их для использования, точно такие же макетки на одностороннем тектолите без метализации ведут себя адекватно, может будет кому то полезным.