rmatveev

Members
  • Публикации

    107
  • Зарегистрирован

  • Посещение

Репутация

1 Обычный

О rmatveev

  • Звание
    Осваивающийся

Информация

  • Город
    Москва

Электроника

  • Стаж в электронике
    10-20 лет
  • Сфера радиоэлектроники
    источники питания
  1. Подходит ли малинка для такой вот задачки?

    Это уже вряд ли. Мне же хардверный Ethernet нужен...
  2. Подходит ли малинка для такой вот задачки?

    Это вот она, что ли?
  3. Подходит ли малинка для такой вот задачки?

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

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

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

    Ничего себе "левые" :))) MBED OS - это среда разработки ARM Limited. Т.е. прям роднее некуда. И пока мне эта платформа видится во многом удобнее. Вы же не посоветуете какому-нибудь ардуинщику кодить на ассемблере и "не тащить левые библиотеки" :)))
  8. Вливаюсь в среду программирования MBED OS с платой STM32F429I-DISC1 и вот что заметил: 1) Почему-то PWM у меня нормально заработал только на ножке PF_6. Я перебрал, конечно, не все порты, которые поддерживают работу с PWM, но другие, которые я попробовал, не заработали. 2) Пытался сконфигурировать некоторые порты в качестве цифрового выходи и тоже фигушки. Нормально заработали только те, что подключены к зеленому и красному светодиодам (PG_13 и PG_14). На некоторых ножках был какой-то неведомый мне меандр, какие-то не захотели переходить в низкоомное состояние. В качестве базы я использовал код DISCO-F429ZI_LCDTS_demo (это из примеров по этой плате с работой ЖК индикатора и тачскрина). Что может быть не так? Может быть какие-нибудь библиотеки, подключаемые при работе тачскрина и/или дисплея занимают большую часть портов и не позволяют их использовать по усмотрению программиста? Или я еще что-то не понимаю в архитектуре ARM? (Сам я прихожу из AVR-ов)
  9. Друзья, задача такая: нужно сузить область приема Bluetooth адаптера (HC-05). Усиливать сигнал не нужно, нужно просто что бы связь могла осуществляться только из небольшой зоны в несколько кубических метров между антенной и землей (т.е. предполагаю, что антенна должна находиться вверху на опоре (метрах в 3-4 от уровня земли) и находясь под опорой должна быть связь, а при удалении на 2-3 метра от опоры связь должна пропадать. Этот приемник, который я привел выше, очень недорогой и у него есть встроенная антенна. Но она я так полагаю будет иметь почти сферическую диаграмму направленности: Может быть вокруг этой штуки нужно сделать какой-то кожух? Хотя, мне больше нравится вариант "отрезать" встроенную антенну и подключить внешнюю направленную. Правда, внешняя направленная пожалуй будет и коэффициент усиления побольше, так что возможно из-за отражения от земли и конструкций в итоге опять же обеспечить малую область приема будет сложновато. Какие ваши мысли, друзья?
  10. Какой-то странный код генерирует Atmel Studio 7

    Освежу тему: я тут попробовал поисследовать то, как описаны регистры в стандартных хедерах, которые были в стандартной инсталляции 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 регистрам есть побитный доступ. Нет ли у вас идей что я делаю не так? Либо может быть некорректно работает компилятор и что с этим делать? Либо регистры описаны неверно и как их тогда описать правильно?
  11. Пытаюсь скомпелировать несложный код с опросом бита 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, но там код вылезает из памяти). Соответственно, код не работает. Что я сделал не так?
  12. Друзья, привет! У меня возникло стойкое желание разместить платы в панель, на которой развести еще дополнительные цепи для тестирования, т.е. платы будут соединяться с панелью через мостики, через которые я планирую провести и эти тестовые дорожки. Однако, есть проблемы и сомнения: 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) Можно ли сделать схему для панели? Всем спасибо! Желаю хорошего дня
  13. Ну я пока использую ту самую "версию" с поднятой крышкой. Но спасибо за идею! Я попробую.
  14. Друзья, осваиваю новую для себя технологию - импорт 3D корпуса и формирования контура платы из STEP-модели. Скачал с официального сайта STEP-модель корпуса (Phoenix Contact), разместил ее на рабочем поле PCB редактора, сформировал из чертежа платы, собственно, контур платы. Разместил на рабочем поле компоненты (они автоматом все разместились вне корпуса. И тут я заметил, что стоит перенести любой компонент на плату, как он "зажигается" зелененьким: Хотя, на 3D View все выглядит хорошо: Еще обратил внимание, что по-началу компоненты как бы утопали в плату. Решил проблему изменением толщины платы в Design -> Layer Stack Manager и увеличил толщину диэлектрика с чего-то вроде 0,38 (не помню уже сейчас точно) до 0,691 (!!!). Число подобрал итеративно, что бы число, которое отображается на втором скришноте как 0,009 стало нулем. Но проблему это не решило. В чем может быть проблема? PS. Похоже, разобрался: видимо, чертеж корпуса сделан практически без пространства внутри, так что на плату и, тем более, на монтаж компонентов там нет места: Буду разбираться с корпусом PS2. Вообще странно - корпус как будто нарисован правильно и внутри действительно есть пустота:
  15. Т.е. правильный путь - это будет все-таки использование того 1300 стр. документа? А я правильно понимаю, что для STM32 по сути можно писать на трех уровнях: 1) обращаясь непосредственно к регистрам (это как раз то, что я всегда делал для AVR) 2) используя HAL 3) видимо, еще есть RTOS, но я думаю что у меня пока задачи не того уровня.