rmatveev

Да, забыл сказать, что контроллер при этом продолжает работать. На кнопки реагирует и функционирует в остальном нормально. Нет, стойкий сбой. Перезапуск по питанию не помогает. Статистика такая: было отгружено 34 изделия. Из которых с такой неисправностью вернулось в ремонт 3 и еще два вышло из строя таким же образом. Т.е. всего 5 шт. Остальные, вроде, пока работают.

Вообще, был бы признателен за любые мысли по теме. А то я что-то в тупике

Друзья, есть изделие на базе ATmega88PA-AU. UART через микросхему SN75176BDR преобразуется в RS-485 без дополнительных развязок (развязка обеспечивается за счет питания всей платы от изолированного AC-DC). Связь работает себе работает, и вдруг перестает. При этом на вход контроллера сигнал доходит абсолютно нормальный. Но ожидаемого ответа контроллер не дает. Помогает перепрошивка. Причем тем же самым кодом (делал верификацию - код 1 в 1). Фьюзы я также проверил. В качестве программатора использую ACRISP MKII. В качестве среды разработки и прошивки - Atmel Studio 7 (7.0.1417). Не сталкивался ли кто-нибудь из уважаемых коллег с чем-то подобным?

А это в каком файле? Что-то пока ума не приложу где это. Вы не приложите скрин?

Друзья, мне бы хотелось как-то начать "метить" прошивки, которые я заливаю в устройства на этапе разработки. Когда-то давно, когда я еще кодил для МК51 и PIC я использовал несколько ячеек в начале памяти программ, куда автоматом записывал закодированную дату. Но это я делал с помощью своей утилиты - при компиляции я запускал свой батник, который во-первых формировал небольшой ассемблерный файлик с кодом даты, он уже линковался к основному коду и получалось у меня что-то типа такого: ORG 0000h goto Begin include 'date.src' retw __day retw __month retw __year ORG 0004h goto INTERRUPT Файл date.src формировался моим батником, там присваивались значения макросам __day, __month и __year. Это ассемблер для PicMicro. Я использовал тот факт, что у него между началом пользовательского кода и единственным вектором прерывания было 4 байта, в первый байт я вставлял команду перехода на начало, а в три оставшихся байта - дату. Она была хорошо видна при считывании кода из чипа. Было очень удобно потом идентифицировать прошивку, т.к. исходники я тоже сохранял по датам. В общем, такая была доморощенная система контроля версий. Было это году в 2000-м. Сейчас я пользуюсь Atollic TrueStudio и MBED и тоже задумался о том, как мне помечать прошивки. Может быть есть какие-то штатные способы? Или может по старинке найти в коде место, куда зашивать дату что бы ее легко было видно при считывании прошивки в ST Link Utility? Спасибо заранее за любые мысли.

Я проблемы изложил в вопросе: 1) Не понятно можно ли использовать прошивку, отлаженную на демо-плате, на собственной 2) В каком виде заливать прошивку на собственную: тот же BIN файл? 3) Как заливать эту прошивку: можно ли просто ее же залить по SWD?

Поясню в чем проблема. Отладочная плата удобна для прототипа: срок, функциональность, цена, документация - все отлично. Но она не очень подходит для серии: цена уже не такая сладкая, габариты могут не подходить, может понадобится разместить питание да и мало ли что еще.

Ну во-первых они уже есть Во-вторых это все-таки очень удобно: в MBEDе можно сразу открыть проект под плату, в STM32 CubeMX тоже можно сразу конфиг сделать за пару кликов. А иногда это еще и супер дешево. Например, Blue pill стоит полтора бакса (или что-то около того). Я такую стоимость могу себе представить только в каких-то сладких снах, да еще и при тиражах в десятки тысяч штук. Возьму, к примеру, STM8L-Discovery - так там есть сразу схема измерения тока потребления и дисплей. Сразу можно отладить без танцев с бубном и микроамперметром. А в SMT32F4-disc1 - сразу тачскрин. И в MBED он заводится за пару кликов. Я на этой плате, например, сразу запилил систему управления обратно-ходовым преобразователем. И даже разводить ничего не надо. В общем, меня наличие альтернативы в виде готовой полнофункциональной платы для прототипа очень даже радует. Отладил на прототипе прошивку и потом уже хорошо представляя задачу разводишь плату под свое устройство.

Я могу купить любую из доступных китовых плат (дискавери, нуклео и т.д.), отладить на ней свою прошивку. А как мне потом сделать на базе этих наработок свою плату? Вот разведу я там микроконтроллер, но уже без USB, второго контроллера (который, как я понял, обычно на китовых платах занимается как раз заливкой прошивки на МК), может быть ножки, напряжение питания будет немножко не те. Что делать дальше? Предвижу, что там ничего сложного: та же самая прошивка, которую я до этого заливал через USB (bin файл) я теперь буду заливать через SWD с помощью ST-Link или той же демо-платы (на которых обычно этот ST-Link уже присутствует и "активируется" парой джамперов). Понятно, что если я при этом вынужден буду переназначить какие-то ножки или сделать еще какие-то изменения, то я просто пропишу это в функции инициализации. Вопросы: 1) Правильно ли я понимаю процесс? 2) Нет ли там тонкостей и подводных камней?

Друзья, у меня было два "хвостика" из Хоббикинга. Картинка в скрепке. Они отлично выполняли свою функцию, но тут сегодня случайно сломал одну, а новую заказать уже не возможно :((( Да и некогда - партия плат как раз завтра выходит из монтажа. Т.е. мне сейчас нужно срочно придумать как мне контачиться к процессору что бы залить в него прошивку. Если второй хвостик сломается (а мне прошить нужно более 1500 шт.) то это будет катастрофа :((( Выручайте!!!

Это уже вряд ли. Мне же хардверный Ethernet нужен...

Это вот она, что ли?

Да я чувствую, что избыточно. Может есть другие более подходящие платформы? PS. Еще рассматриваю фотки RPi 3b и что-то не вижу ничего что было бы похоже на WiFi модуль. А он там, вроде, заявлен.

Всем привет! Задумано следующее: на малинку ставится веб-сервер (именно веб, а не HTTP, т.к. подразумевается тонкий клиент, но возможно я с терминами немного путаю), который обеспечивает управление через тонкий клиент по Ethernet, по Modbus RTU поверх RS-485 малинка должна будет управлять объектом. Т.е. задача такая: на удаленном рабочем месте визуализация объекта и его управление по Modbus. Изначально я хотел под это дело использовать какой-нибудь NUCLEO на процессоре STM32. Но почитал немного о подробностях установки TCP-IP стека и веб-сервера на STM32 и понял, что эту задачу они выполняют, но как-то сложновато. Вроде как Raspberry Pi намного лучше с этим должна справиться. Да и комьюнити намного больше. Ваши мнения, господа?

Ничем Если это стоящая вещь, то я готов на нее внимательно посмотреть. Просто взор упал на MBED, мне понравилась концепция и я начал ее использовать. Но сейчас наступает некое отрезвление.

Эт точно ))) Ладно, я погляжу другие среды. У MBED OS в числе прочего есть еще важный недостаток - полная облачность. Нет интернета = нет кода. Локально там вообще ничего не работает. В наше время это, конечно, не очень большая проблема, но меня это немного напрягало.

Ничего себе "левые" :))) MBED OS - это среда разработки ARM Limited. Т.е. прям роднее некуда. И пока мне эта платформа видится во многом удобнее. Вы же не посоветуете какому-нибудь ардуинщику кодить на ассемблере и "не тащить левые библиотеки" :)))

Вливаюсь в среду программирования MBED OS с платой STM32F429I-DISC1 и вот что заметил: 1) Почему-то PWM у меня нормально заработал только на ножке PF_6. Я перебрал, конечно, не все порты, которые поддерживают работу с PWM, но другие, которые я попробовал, не заработали. 2) Пытался сконфигурировать некоторые порты в качестве цифрового выходи и тоже фигушки. Нормально заработали только те, что подключены к зеленому и красному светодиодам (PG_13 и PG_14). На некоторых ножках был какой-то неведомый мне меандр, какие-то не захотели переходить в низкоомное состояние. В качестве базы я использовал код DISCO-F429ZI_LCDTS_demo (это из примеров по этой плате с работой ЖК индикатора и тачскрина). Что может быть не так? Может быть какие-нибудь библиотеки, подключаемые при работе тачскрина и/или дисплея занимают большую часть портов и не позволяют их использовать по усмотрению программиста? Или я еще что-то не понимаю в архитектуре ARM? (Сам я прихожу из AVR-ов)

Друзья, задача такая: нужно сузить область приема Bluetooth адаптера (HC-05). Усиливать сигнал не нужно, нужно просто что бы связь могла осуществляться только из небольшой зоны в несколько кубических метров между антенной и землей (т.е. предполагаю, что антенна должна находиться вверху на опоре (метрах в 3-4 от уровня земли) и находясь под опорой должна быть связь, а при удалении на 2-3 метра от опоры связь должна пропадать. Этот приемник, который я привел выше, очень недорогой и у него есть встроенная антенна. Но она я так полагаю будет иметь почти сферическую диаграмму направленности: Может быть вокруг этой штуки нужно сделать какой-то кожух? Хотя, мне больше нравится вариант "отрезать" встроенную антенну и подключить внешнюю направленную. Правда, внешняя направленная пожалуй будет и коэффициент усиления побольше, так что возможно из-за отражения от земли и конструкций в итоге опять же обеспечить малую область приема будет сложновато. Какие ваши мысли, друзья?

Освежу тему: я тут попробовал поисследовать то, как описаны регистры в стандартных хедерах, которые были в стандартной инсталляции Atmel Studio (iom48pa): PORTD++; 67a: 8b b1 in r24, 0x0b ; 11 67c: 8f 5f subi r24, 0xFF ; 255 67e: 8b b9 out 0x0b, r24 ; 11 ADCSRA++; 680: f8 01 movw r30, r16 682: 80 81 ld r24, Z 684: 8f 5f subi r24, 0xFF ; 255 686: 80 83 st Z, r24 _SFR_IO8(0x7A)++; 688: f7 01 movw r30, r14 68a: 80 81 ld r24, Z 68c: 8f 5f subi r24, 0xFF ; 255 68e: 80 83 st Z, r24 _SFR_MEM8(0x7A)++; 690: f8 01 movw r30, r16 692: 80 81 ld r24, Z 694: 8f 5f subi r24, 0xFF ; 255 696: 80 83 st Z, r24 Как можно видеть - с PORTD (в хедере определяется как _SFR_IO8) компилятор работает правильно. А вот с ADCSRA (в хедере _SFR_MEM8) - нет: используются инструкции LD и ST вместо IN и OUT. Причем, даже если я прямо в коде укажу регистр через _SFR_IO8 (как и PORTD), то это не помогает. Вероятно, это связано с тем, что PORTD находится в нижней памяти, а ADCSRA - в верхней, насколько я помню - там есть различия в доступе, в частности, к нижним SFR регистрам есть побитный доступ. Нет ли у вас идей что я делаю не так? Либо может быть некорректно работает компилятор и что с этим делать? Либо регистры описаны неверно и как их тогда описать правильно?

Пытаюсь скомпелировать несложный код с опросом бита ADIF (бит запроса прерывания от АЦП) в регистре ADCSRA и вот что получается в коде: if((ADCSRA & (1<<ADIF)) != 0){ 628: 0a e7 ldi r16, 0x7A ; 122 62a: 10 e0 ldi r17, 0x00 ; 0 ADCSRA |= 1<<ADIF; if((ADMUX&0b00001111) == ADCH_OUT){ 62c: 0f 2e mov r0, r31 62e: fc e7 ldi r31, 0x7C ; 124 630: ef 2e mov r14, r31 632: f1 2c mov r15, r1 634: f0 2d mov r31, r0 temp1 = ((ADCH<<8) + ADCL)*100/205; Как видно, никаким ветвлением и не пахнет Пробовал разные варианты оптимизации - никаких принципиальных изменений (кроме O0, но там код вылезает из памяти). Соответственно, код не работает. Что я сделал не так?

Друзья, привет! У меня возникло стойкое желание разместить платы в панель, на которой развести еще дополнительные цепи для тестирования, т.е. платы будут соединяться с панелью через мостики, через которые я планирую провести и эти тестовые дорожки. Однако, есть проблемы и сомнения: 1) Когда я буду выламывать платы из панели - что случиться с дорожками? Они не превратятся в бахрому? 2) Альтиум как-то слабо поддерживает мой колхоз. Во-первых после того как платы помещаются на панель командой Place -> Embedded Board Array/Panelize я перестаю видеть дорожки и мне приходится разводить панель в слепую. ( А вот так это выглядит в 3D режиме: Вообще, на сайте Альтиума написаны такие замечательные слова: but it is not advisable to place any other objects that would represent the actual physical design (Не рекомандуется размещать на панели любые физические элементы, взято отсюда: http://www.altium.com/documentation/17.0/display/ADES/PCB_Obj-EmbeddedBoardArray((Embedded+Board+Array))_AD ) Т.е. получается, я вообще пытаюсь использовать Альтиум для того, для чего он не совсем предназначен. Из этого вытекают другие неприятности: похоже мне придется разводку делать без названий цепей и DRC (проверка правил разработки), соответственно, если я где-то случайно соединю не ту цепь или не что-то не разведу, это останется незамеченным. А плат на панели я собирался разместить порядка 15-20, такая задача выглядит довольно сложной.... Вопросы: 1) Что скажете по поводу дорожек после выламывания? 2) Посоветуйте что-то с Альтиумом: 2.1) Как отобразить дорожки на 2D View? 2.2) Можно ли сделать схему для панели? Всем спасибо! Желаю хорошего дня

Ну я пока использую ту самую "версию" с поднятой крышкой. Но спасибо за идею! Я попробую.

Друзья, осваиваю новую для себя технологию - импорт 3D корпуса и формирования контура платы из STEP-модели. Скачал с официального сайта STEP-модель корпуса (Phoenix Contact), разместил ее на рабочем поле PCB редактора, сформировал из чертежа платы, собственно, контур платы. Разместил на рабочем поле компоненты (они автоматом все разместились вне корпуса. И тут я заметил, что стоит перенести любой компонент на плату, как он "зажигается" зелененьким: Хотя, на 3D View все выглядит хорошо: Еще обратил внимание, что по-началу компоненты как бы утопали в плату. Решил проблему изменением толщины платы в Design -> Layer Stack Manager и увеличил толщину диэлектрика с чего-то вроде 0,38 (не помню уже сейчас точно) до 0,691 (!!!). Число подобрал итеративно, что бы число, которое отображается на втором скришноте как 0,009 стало нулем. Но проблему это не решило. В чем может быть проблема? PS. Похоже, разобрался: видимо, чертеж корпуса сделан практически без пространства внутри, так что на плату и, тем более, на монтаж компонентов там нет места: Буду разбираться с корпусом PS2. Вообще странно - корпус как будто нарисован правильно и внутри действительно есть пустота:

Т.е. правильный путь - это будет все-таки использование того 1300 стр. документа? А я правильно понимаю, что для STM32 по сути можно писать на трех уровнях: 1) обращаясь непосредственно к регистрам (это как раз то, что я всегда делал для AVR) 2) используя HAL 3) видимо, еще есть RTOS, но я думаю что у меня пока задачи не того уровня.