khomin

Москва В компанию требуется программист, зп до 110к на руки https://progress-system.com/ Только присутствие, без удаленки и аутсорса Требования: - опыт программирования под stm32 или cc1352 - знание простой схемотехники - знание C code Желательно: - опыт Qt, WPF, Linux, немного Android Предложения направлять на почту [email protected]

Спасибо всем Вакансия закрыта

Актуально!

Update: Полностью удаленная работа не рассматривается! Необходимо присутствие в офисе (минимум 3 раза в неделю)

Москва, метро Щелковская, компания https://locuscom.ru/ Требуется схемотехник, зп. 65-80тыр. на руки (зависит от способностей) Требования и обязанности: - опыт разработки в Altium, - создание, наполнение, поддержание библиотек - чтение даташитов и понимание ключевых моментов - опыт формирования bom, генерирования gerber, написание монтажных карт, подбор/заказ компонентов - знание цифровой схемотехники: mcu (stm32, msp430, cc13xx), различные gsm модемы, gnss, интерфейсы (rs485, rs232, иногда ethernet 10-100), RF (430Mhz-2GHz) в целом уровень не очень высокий - будет плюсом умение набрасывать простые модели в Solid Works - программировать не требуется, но при желании можно это обсудить (в первую очередь нужен человек по схемам) - полная занятость, можно рассмотреть варианты по совмещению + студентов последних курсов Резюме и предложения направлять на почту: [email protected]

С коллегами нашли 8 шт BGS2 -E (Cinterion), из старых проектов, теперь лежат без дела Не паянные, в ленте Появилась идея продать и купить в отдел пиццы 4тр. за все, или 500р. штука м.Щелковская 8903-266-4166

[email protected]

И мне пришлите ТЗ пожалуйста khominvladimir @yandex.ru Или через хабр https://habr.com/users/khomin/

Добрый день Ищу работу https://electronix.ru/forum/index.php?showtopic=142769

Ищу работу. Москва. 25 лет. Опыт работы с STM32, MSP430 и AVR, подбираюсь к ПЛИС, быстро обучаюсь. Интерфейсы и протоколы: UART, I2C, I-Wire, SPI, Modbus, M-Bus, Радиоканал (CC1101), Ethernet (PHY MAC и W5200-5100), USB-HID. Опыт разработки приложений под Windows и Linux, преимущественно в Qt, использование в проектах Ethernet и USB. Имеется опыт разработки печатных плат в Altium, (двухслойных, средней плотности и без высокочастотных цепей), разработка футпринов компонентов, моделей в Solid Works. Владею паяльником, радиолюбительский опыт с 9-ти лет. Время от времени стараюсь делать заметки в блоге, http://we.easyelectronics.ru/my/khomin/ До настоящего времени работал в небольшой компании, специфика - учет ресурсов (диспетчеризация, удаленный сбор показаний т.д.), занимался разработкой электроники в этой области. Компании настал конец. Территориально интересует Москва и область. Заработная плата от 60 т.р. 8(903)266-41-66 [email protected]

Смотрю отправку в: /* When Tx Buffer unavailable flag is set: clear it and resume transmission */ if ((ETH->DMASR & ETH_DMASR_TBUS) != (u32)RESET) { /* Clear TBUS ETHERNET DMA flag */ ETH->DMASR |= ETH_DMASR_TBUS; /* Resume DMA transmission*/ ETH->DMATPDR = 0; } После старта, без появления глюка, данные отправляются сразу после ETH->DMATPDR = 0;, как и должно. После проявления глюка, светодиод на разъеме LAN так же "моргает" после записи нуля в DMATPDR, т.е. что-то через физику уходит. В регистре DMASR, разницы с проявлением глюка - не вижу. Биты TPS, NIS, ETS выставляются так же. в MMCTGFCR (transmitted good frames counter register) после записи DMATPDR счет так же увеличивается ... Честно говоря уже голову сломал, больше недели потратил - результат пока нулевой ( Думаю стек и драйвер от st не при делах. Сверял все указатели непосредственно в регистре DMA, указатели на дескрипторы и их содержимое, на буфер Tx, все верно и не отличается от работы до появления этого глюка. Думаю если создать свой буфер с дескриптором (да заполнить константами) и подцепить к DMA вместо буфера из стека, наверняка получится то же самое ... Уже и Errata на STM32F429 пересмотрел, ничего похожего не нашел, что не удивительно.

Спасибо. В целом стараюсь так и делать. Но вот коснулся STM32F4, решил борду не покупать, так как отличия от STM32F2xx показались не столь большими. А вот схему срисовал с демоборды, правда там использовался MII, внешний генератор и PHY был один из самых дорогих ) Не подскажете пожалуйста, как может называться - низкоуровневый Ethernet сниффер? На этом проекте по прежнему остается чудовищный баг, при котором через 5-10 минут MAC продолжает слать пакеты, но в сети они уже не проходят или не появляются ... При этом прием происходит без изменений. Перерыл все исходники, пробовал найти проблему но так и не получилось. Буфер и дескриптор заполняются без ошибочно, у MAC DMA все указатели на буфера так же верные. Содержимое регистров MAC и MAC DMA не отличаются до и после бага. На выводах TXD0-1 так же проявляется активность при отправке, а Wireshark-ом уже не видно ... Не понимаю, возможно пакет отправляется битым, возможно он не отправляется вовсе, но увидеть это нечем ...

Спасибо за внимание. Разобрался. Безумно стыдно и радостно ) Проблема оказалась в тактировании. Брал от MCO (PLL/3) = 50 Мгц. Подвинул бит делителя и пакеты пошли в сеть. Буду ставить кварцевый генератор

Оказалось у меня PHY работает не со всеми сетевыми картами. В локалке через switch работает нормально, а уже через switch другой марки - пакеты не пропускаются, так же и с компьютером - на ноутбуке пакеты принимаются, а на компьютере уже нет ( Подогнал токозадающее сопротивление до единиц ом, проверил всю схемотехнику, разницы пока не заметил. Самое интересно, что пакеты время от времени таки пролетают, но очень редко (~1 пакет в 3 минуты) Причем Autonegatioation определяет все как надо, биты "доступности" 100-F-H, 10-F-H выставлены

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

оказывается, через время прерывание от DMA Ethernet пропадают, при этом биты RXE-RXEI включены, не представляют где искать причину такого поведения ...

Спасибо, данные просто выплевываются по UDP. Добился отсутствия счета ошибок, теперь стек просто перестает работать через 5-10 минут отсылок и пинга )) Похоже это конец (

разобрался с отправкой, был косяк с очисткой pcb (protocol control block), каждый раз создавался новый, понятное дело через время залезал за пределы памяти. сейчас так: void MyTask(void *pvParametes) { struct pbuf * pb; struct ip_addr addr; struct udp_pcb *pcb; addr.addr = 0x5A6EA8C0; ETH_BSP_Config(); LwIP_Init(); for(;;) { pcb = udp_new(); udp_bind(pcb, IP_ADDR_ANY, 3003); udp_connect(pcb,&addr, 3003); pb = pbuf_alloc(PBUF_TRANSPORT, 512, PBUF_RAM); pb->len = 512; udp_sendto(pcb, pb, &addr, 3003); pbuf_free(pb); udp_disconnect(pcb); udp_remove(pcb); vTaskDelay(1000); } } Некоторое время работает, потом пинги пропадают ... Наверно потому, что счет ошибок в: идет с чудовищной скоростью ... происходит это здесь: err_t sys_mbox_trypost(sys_mbox_t *mbox, void *msg) { err_t result; if ( xQueueSend( *mbox, &msg, 0 ) == pdPASS ) { result = ERR_OK; } else { // could not post, queue must be full result = ERR_MEM; #if SYS_STATS lwip_stats.sys.mbox.err++; #endif /* SYS_STATS */ } return result; } т.е. через раз не удается записать msg в очередь ... не понятно почему так происходит и должно ли так быть ... стека на задачи отвел в 10 раз больше чем в примерах

да, это было первым с чего начал в общем, в процессе разбора, обнаружил ряд моментов: При старте, все работает нормально, через примерно минуту происходит "утечка" памяти, после чего даже в исходящем пакете появляются ошибки (время жизни и т.п.), это видно в wireshark-е выделенные розовым - уже битые пакеты. далее включил #define SYS_LIGHTWEIGHT_PROT 1 , по идеи это защита критической области по освобождению памяти, разницы не заметил. затем включил системную статистику стека, #define LWIP_STATS 1 и структуре lwip_stats.memp.memp[1] появился счет ошибок первое значение в .err по времени совпадает с появлением битых пакетов. причем ошибки появляются только в массиве memp[1], в других значение max не превышает avail. Далее, если так все оставить, счет прибавляется дальше, в конечном итоге работа полностью нарушается, происходит HardFault или просто все слетает ... Буду разбираться дальше )

увы нет, добавленные задачи не используют LwIP, там простые функции опроса кнопок и индикации ... и приоритет у них Idle Рад бы разобрать на низком уровне, да кругом одни указатели и даже содержимое буферов в отладке просто так не посмотришь ...

Здравствуйте. Собрал плату на STM32f429, PHY Ksz8041, FreeRTOS. Проект в Coocox, собрал из примеров от ST. При работе только со "штатными" задачами из примеров, все работает нормально (1 час пингов держал), но если добавить несколько собственных задач, стек LwIP через минуту-две перестает нормально работать (или возможно проблема с MAC), при этом сохраняется активность на TX-0-1 на PHY от MAC, все задачи исправно работают (стек не переполняется), пакеты так же продолжают приходить (прерывание ETH_IRQHandler срабатывает). Задача "ethernetif_input" и функция "low_level_input" так же выполняются ... Попытки играть с приоритетами, выделением памяти (heap_4), и т.п. результатов за два дня не принесли :( Знаю про "косячный" драйвер от ST, самые "известные" на форумах баги подправил, но ничего не изменилось Пытался запустить LWIP_DEBUG, но видимо во FreeRTOS retarget надо как-то буферизовать, происходит переполнение стека и оказываюсь в ловушке - vApplicationStackOverflowHook, пока не разобрался. настройки FreeRTOS: #define configUSE_PREEMPTION 1 #define configUSE_IDLE_HOOK 0 #define configUSE_TICK_HOOK 0 #define configCPU_CLOCK_HZ ( 150000000 ) #define configTICK_RATE_HZ ( ( portTickType ) 1000 ) #define configMAX_PRIORITIES ( ( unsigned portBASE_TYPE ) 15 ) #define configMINIMAL_STACK_SIZE ( ( unsigned short ) 128 ) #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 20 * 1024 ) ) Прием: void ethernetif_input( void * pvParameters ) { struct pbuf *p; for( ;; ) { if (xSemaphoreTake( s_xSemaphore, emacBLOCK_TIME_WAITING_FOR_INPUT)==pdTRUE) { while ((p = low_level_input( s_pxNetIf )) != 0) { if (p != 0) { if (ERR_OK != s_pxNetIf->input( p, s_pxNetIf)) { pbuf_free(p); p=NULL; } } } } ethernet_watchdog(); } } static void ethernet_watchdog(void) { /* When Rx Buffer unavailable flag is set: clear it and resume reception */ if ((ETH->DMASR & ETH_DMASR_RBUS) != (u32)RESET) { /* Clear RBUS ETHERNET DMA flag */ ETH->DMASR = ETH_DMASR_RBUS; /* Resume DMA reception. The register doesn't care what you write to it. */ ETH->DMARPDR = 0; } } Надеюсь на пинок в нужный вектор ... Все перелопатил, останется только изучать низкий уровень Ethernet (DMA, склейка-разбор пакетов и т.д.), что безусловно полезно и интересно, но уровень для меня пока высоковат ... В общем, товарищи, куда можно дальше копать?

Доброго времени суток. Собрал плату на Ksz8041, STM32F4 + LwIP. Подправил пример стека - "под себя". Столкнулся с тем, что через 100Мбитный хаб ничего не работает, а на прямую через сетевой switch все работает как должно. У PHY включен "Auto-Negotiation" внешней подтяжкой, пробовал так же программно, разницы нет. Link устанавливается, стек пакеты принимает (видно в буфере и по прерыванию Ethernet) и передает (заметна активность TXD0-1 CRS_DV), но wireshark ничего не видит. Увы не до конца понятен алгоритм с Auto-Negotiation, так же не ясно какой из регистров должен давать информацию (1,4 или 5) и нужно ли вручную конфигурировать PHY ? Кто сталкивался ..., отзовитесь пожалуйста ... пробовал вручную заполнять структуру ETH_InitStruct, ставил 10-100 Full-HalfDuplex, результата нет

Здравствуйте. Потихоньку осваиваю CoIDE, столкнулся с удивительной странностью, такого никогда не встречал. Препроцессор условия компиляции обрабатывает корректно (код "затемнен" или нет, соответственно) , а после компиляции в процессе отладки это условие игнорируется. Например: FreeRTOSConfig.h configUSE_IDLE_HOOK 1 tasks.s #if ( configUSE_IDLE_HOOK == 1 ) extern void vApplicationIdleHook( void ); vApplicationIdleHook(); #endif /* configUSE_IDLE_HOOK */ в таком виде в vApplicationIdleHook никогда не попасть, а стоит объявить define внутри файла или закоментить, как все работает. Может быть кто сталкивался с подобным ... в keil таких проблем нет ... Спасибо всем кто собирался ответить, проблема вылечилась прямым включением "FreeRTOSConfig.h" Хотя почему компилятор не выдал предупреждений, остается загадкой

проще использовать тот же механизм как с пакетами Modbus по 485, после превышение определенного интервала, соблюдение "тишины" будет означать конец пакета. Ну и конечно следить за переполнением приемного буфера

Спасибо большое. Вроде разобрался. Оказалось TMP112 работал в активном режиме. Отсюда ток "плавал". Методом проб добился потребления всей схемы в 2 мка на VLO и ~3 мка на LFXT. Показалось странным, что потребление от внешнего 32768 выше внутреннего, но жить можно.