Перейти к содержанию
    

zhevak

Свой
  • Постов

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

  • Посещение

Репутация

0 Обычный

Информация о zhevak

  • Звание
    Знающий
    Знающий
  • День рождения 30.03.1962

Контакты

  • Сайт
    Array
  • ICQ
    Array
  • Jabber
    Array

Информация

  • Город
    Array

Посетители профиля

2 600 просмотров профиля
  1. Когда элемент питания будет садится и его напряжение будет опускаться к 1.2 В и ниже, Микроконтроллер сможет работать при таком напряжении? Я не знаю, что за устройство Вы проектируете, но на мой взгляд самое оптимальное решение -- это использовать литиевый элемент типа CR2030. (Может быть я не прав, я ведь не знаю какую задачу Вы решаете.)
  2. Обратите внимание, что сначала нужно читать ADCL и только потом ADCH. (Даташит на ATMEGA48_88_168, стр.258) А Вы подключили include-файл ? .includepath "/usr/share/avra/" ; Путь к инклюдам .include "m168def.inc" ; Инклюд для ATMEGA186 Ну или опубликуйте свой код. Так людям будет легче помочь Вам. (Не стесняйтесь того, что ваш код может оказаться далёким от совершенства. Все мы когда чего-то не знали и делали очень глупые ошибки. Стыдиться надо не незнания, а того, что не хочешь знать.)
  3. Ну вот как бы LED лампы могут и не дать такого ярко-выраженного эффекта. Вот, с. 8 написано И там где-то по тексту рядом сказано, что наибольший эффект имеют галогенные ламы, обычные лампочки Ильича и солнышко, ибо пик в спектре их излучения и чувствительность чипа совпадают где-то на этих длинах волн. А у ЛЭД-лампочек спектр совсем другой. В документе даже рекомендации даны -- типа проверять свою продукцию галогенками перед тем как. Но ради спортивного интереса я бы с ЛЭД-лампочками тоже поигрался. Практика -- это много значит.
  4. ну или вообще не будет работать -- ...in a WLCSP package maystop operating whenexposed to direct sunlight. This effect can be reproduced by holding a 42 W halogen lamp at a distance of approximately40 cm:the BLE WLCSPdevice stops advertising immediately (Выделено мною -- сразу перестаёт работать.)
  5. https://www.dialog-semiconductor.com/sites/default/files/an-b-021_-_da1458x_wlcsp_light_sensitivity_v1.3.pdf -- Application note DA1458x WLCSP package light sensitivity alex_zhuravlyov -- успел чуть быстрее, пока я занимался копипастами :)
  6. Александр, спасибо за то, что взбодрили унылую серую жизнь! А Вы не пробовали затенять те или иные микросхемы? Хорошо бы вычислить того, кто "гадит в общий котел". Ещё вопрос -- Вы когда пробовали светить с разных направлений, Вы поворачивали плату или же плата была зафиксирована, а Вы светили фонариком с разных позиций? Хотелось бы исключить влияние пространственного положения IMU-шек. (Извините, за возможную некорректность. Просто очень интересный эффект и очень хочется найти причину. Я ни чуть не сомневаюсь в Вашем уровне знаний. Просто для чистоты эксперимента.
  7. диоды типа 4148 от света могут "подтекать". Замечено было ещё на стадии ознакомления с диодами Д9 и Д7 (если светить ему в... ну, выражаясь культурно -- со стороны анода, у него там стеклянный изолятор был).
  8. Вообще ожидается, что должно быть как раз наоборот. Может какие-то наводки от руки? Подносить руку с телефоном, но с выключенным фонариком не пробовали? Попробуйте вместо телефона обычный фонарик. С какого расстояния светили телефоном? А фонариком? А включать-включать фонарик на расстоянии (скажем -- один метр) -- как оно, потребление так же будет реагировать? Недавно в интернете вплывала тема, что давным-давно было замечено, что КТ315 реагируют на свет через свой корпус.
  9. Вряд ли поможет, но может быть подскажет правильное направление -- Недавняя статья на Хабре "Считывание защищённой прошивки из флеш-памяти STM32F1xx с использованием ChipWhisperer" (Яндекс находит)
  10. open62541 + STM32 + RTOS + LwIP

    Не знаю в какие двери постучать... Задача следующая: Имеется некий девайс на базе STM32F4xx, к нему прикручена "физика" DP83848, пара светодиодов и пара кнопок. Простецкий тестовый проект сгенерён под CubeMX. Созданный проект позволяет удалённо по UDP (по TCP/IP) управлять светиками и опрашивать кнопки. Всё красиво работает, проблем нет. Теперь нужно это же самое сделать под технологией OPC UA. В частности, я сориентировался на её конкретную реализацию -- open62541. Проблема в том, что я пока никак не могу поставить open62541 на FreeRTOS. Одних только моих мозгов не хватает. Хотелось бы найти тех, кто озаботился темой. Авторы упорно молчат. Я пробовал прикрутить амальгамный вариант open62541, июль, 2019. (Сейчас этой амальгамы нет, авторы open62541 более не рекомендуют пользоваться амальгамой.) Я пробовал создавать свою амальгаму. Пробовал поиграться с мульти-файловым решением. В общем, ничего пока толком не компилится/не собирается. Для справки, в проекте использую BSD-сокеты (не netcom), это чисто для удобства прикручивания open62541. Прошу отозваться, кто озабочен темой.
  11. На прошлой неделе я тоже словил нечто подобное. Я тоже использовал прерывания от внешнего устройства по EXTI. По невнимательности я забыл в main() перед главным циклом разрешить прерывания (__enable_interrupt()). Более того, я эту ошибку не сразу просёк! Девайс работал но как-то странно. Прерывания возникали и обработчик прерывания их даже отрабатывал. Но отрабатывал не каждое, а примерно одно из ста. Я тупил над кодом несколько минут. Копал, но не в том месте. Надо было сразу пойти в main(). Как только я прописал эту строку, девайс сразу начал функционировать как и ожидалось. Но для себя я отметил, что с прерываниями EXTI у STM32F0xx что-то не в порядке. Почему-то они умудряются каким-то образом "просачиваться". Я не знаю, с чем это связано. Понятно, что надо бы по хорошему покопаться поглубже, но пока руки не доходят (как обычно -- всяких дел выше крыши). Боюсь, что придётся отложить это интереснейшее исследование до Новогодних каникул. Параметры для повторения: проц STM32F030F4, питание 3.3 В, тактовая частота ядра 48 МГц. Прерывание от внешнего (цифрового, не аналогового!) устройства возникает каждые 60 мс. Фронт -- спадающий (из "1" в "0"). Внешнее устройство висит на SPI1, тактовая частота SPI -- 3 или 6 МГц (не помню!) Всё чрезвычайно просто -- устройство ставит прерывание на ногу процу, проц обслуживает устройство по SPI. В девайсе задействован ещё USART1, работает только на передачу (TX). Передача байтов происходит тоже по прерываниям (не через DMA.)
  12. Вот тут -- https://smdprutser.nl/blog/ товарищ проводит сравнение. Но, как я понял, он ничего, чтобы отличало один от другого, не нарыл. Ну, если, конечно, не считать, что китайский вариант может работать на более высокой частоте.
  13. Манчестер на STM32

    Если камень ничего больше не делает, кроме как из своей памяти извлекает байты и отправляет их в Манчестеровском коде, то наверно можно. По сути, МК должен через каждые 5 мкс изменять состояние одного какого-то бита в порте. МК -- достаточно быстрый, способен работать на 48 МГц. Мне кажется, что такого времени -- 5 мкс -- вполне достаточно для программного управления ногой. Но вообще задача решается куда проще на МК фирмы Atmel (бывш.) -- на AVR и на AT91Sxxx. Они умеют генерировать меандр синхронный с выходом UART. Сигнал называется XCK. Причём генерируют даже в паузах между передачами байт. На приёмном конце это весьма актуально. А вот, STM32, к сожалению, выдают меандр только для информационных битов USART. Во время вывода стартового и стопового битов меандр не вырабатывается. Я так думаю, что такое немного странное функционирование USART-ов в STM32 продиктовано не тем, что ST хотела предоставить разработчикам работать с Манчестером (как это было у Atmel), а возможностью перевести USART в режим, совместимый с SPI. Странное решение. Но, какое уж есть. У меня вот тут https://wp.me/p1H7g0-1Qm кое-что есть на эту тему.
  14. Коллеги! Двумя комментариями выше я привёл код, который отправляет МК в спячку. В коде ошибка! Правильный код должен быть таким: while (true) { SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk; // Задаём режим STOP PWR->CR |= PWR_CR_LPDS; // Регулятор (1.8 В) в энергосберегающий режим __WFI(); // Спать!!! } Вместо команды __WFI() я написал __WFE(). Написал и даже как-то не обратил на это внимание. Видимо, был сосредоточен на чём-то другом. Хуже того -- код с опиской (ошибкой) благополучно заработал. На присутствие в коде ошибки я обратил внимание только тогда, когда моё устройство стало вести себя мягко говоря странно. Моё устройство -- это телефонная трубка. При пятисекундном нажатии на клавишу "повесть трубу" (красная кнопка) устройство должно было засыпать или наоборот -- просыпаться. На деле устройство меняло режим работы не через 5 секунд, а через 2-3. Хорошо! Я увеличил порог до 10 секунд. Теперь устройство стало издевательски засыпать и просыпаться через 5 секунд. "Стрелка осциллографа" показала, что устройство засыпало не стразу, а только когда главный цикл (в main()) совершит ещё один оборот и команда __WFE будет выполнена повторно. Всё правильно! Команда WFI переводит МК в спячку не взирая на. А вот команда WFE работает немного по другому. Если флаг однобитового регистра события сброшен, то команда отработает как и положено -- отправит МК в спячку. Но если этот бит взведён, то команда WFE не сможет усыпить МК. Вместо этого она просто сбросит этот бит. Поэтому повторное выполнение команды WFE уже будет происходить со сброшенным флагом, поэтому только оно (то есть, повторная команда) и загонит МК в сон. Programming manual PM0215 так об этом и говорит (страница 29, в средине): Для таких как я это положение повторено в руководстве дважы. :) К стати, обратите внимание на последнее предложение -- однобитный регистр события программно не доступен. Ну, и что в итоге? После разумного подхода всё встало на свои места -- трубка засыпает и просыпается после 5-секундного нажатия, и энергопотребление в режиме STOP снизилось еще примерно на 10 мкА и составило примерно 9 мкА. Такие токи достаточно сложно измерять традиционными (китайскими) тестерами типа 828-го. На работе тестер показывает 9 мкА, мой домашний -- 14 мкА. Буду польщён, если этот камент кому-то поможет избежать проблем.
×
×
  • Создать...