Jump to content

    

Сергей Борщ

Модераторы
  • Content Count

    9165
  • Joined

Everything posted by Сергей Борщ


  1. Тоже про это подумал, но автор темы пишет: Я так понял, что эти биты он настроил.
  2. Откройте, наконец, окно дизассемблера и пройдите проблемный участок по командам. Найдите команду, на которой происходит исключение, выложите участок кода и содержимое регистров. Смотреть на исходный код бесполезно - оптимизатор может перемешать его или выкинуть и отладчик будет показывать какие-то левые строчки, не соответсвующие исполняемым командам.
  3. А замерьте напряжение на линиях RS485 с переходником, улучшающим ситуацию и без него. Есть подозрение, что в этом переходнике есть растягивающие резисторы, сохраняющие состояние единицы на шине в паузах между передачами. Тогда для улучшения ситуации вам будет достаточно подтянуть линию A к +5 В, а линию B - к земле через резисторы ни 4.7 ... 1 кОм.
  4. Я отношусь к кубу философски: хотят мыши жрать кактус - пусть плачут и колятся, поэтому просто чаще всего молча прохожу мимо тем про куб.
  5. Не выставляется или вы не попадаете в последнее условие, потому что флаг сбрасывается после чтения SR и DR в первом условии? Полагаю, что все же второе. Я не знаком с кубом, но внимательно читаю документацию на контроллер и его регистры. Из этой документации становится понятно, что ваш обработчик написан неправильно: 1) Нужно один раз в начале обработчика считать регистр статуса и потом во всех условиях работать со считанным значением, а не теребить SR при проверке каждого флага, как это делают недалекие авторы куба. 2) Многие биты в этом регистре сбрасываются автоматически чтением DR после чтения SR и вызов USART_ClearITPendingBit на них никоим образом не влияет. Читайте справочное руководство (reference manual) на контроллер, а не только названия функций в кубе.
  6. Зачем ограждать семафором изменение параметра? Унесите семафор и confingClcCrc() внутрь SaveConfing();
  7. В сторону обработки ошибок по приему, например. Биты данных во всех посылках совпадают, биты четности для приемника с отключенной проверкой четности должны вызывать ошибку приема стопового бита (framing error). В вышей программе эта ошибка, вероятно, не обрабатывается. А поскольку биты данных во всех форматах совпадают - посылка принимается правильно.
  8. Потому что двигатель находится внутри конструкции (авиационного прибора), из которой торчит разъем на кабеле. Двигатель обычно находится в глубине конструкции и чтобы добраться до его контактов придется разобрать конструкцию почти до основания. Разбирать конструкцию чревато - можно или что-то сломать в процессе или не собрать обратно. А некоторые приборы вообще герметично запаяны. Я не знаю, откуда вы берете эти картинки, вот картинка из справочника Копылова по электрическим машинам: Но даже в этом справочнике нет той схемы, по которой эти двигатели включены в, наверное, половине авиационных приборов: Так почему и мне нельзя использовать подключение "не по справочнику"? И, кстати, вспомнил, используется такое включение:
  9. Вот да, меня тоже это смутило, поэтому я и задал вопрос на форуме, где может кто-то изучал курс электрических машин. Ваша аналогия с реле заставила заглянуть в документацию на реле: как видно, одно и то же реле на разное рабочее напряжение имеет одинаковую подводимую мощность (не считая последней строки). Если глянуть, для простоты прикидок, на реле с рабочим напряжением 3 и 6 В, то видно, что ток падает вдвое, напряжение растет вдвое, а сопротивление обмотки увеличивается вчетверо. понятно, что для укладки на тот же каркас вдвое большего количества витков потребовалась проволока вдвое меньшего сечения, отсюда и вчетверо бОльшее сопротивление, но количество ампер*витков осталось тем же. У меня же обе обмотки намотаны одинаковым проводом и, получается, логической ошибки нет: невозможно этим же поводом намотать бесконечное количество витков из-за ограничений на габариты обмотки и, следовательно, невозможно получить бесконечно маленькую мощность управления. Минимально достижимая мощность (максимальный КПД) должна получится при максимальном заполнении магнитопровода обмотками. А если начать уменьшать диаметр провода чтобы еще больше увеличить количество витков - ток начнет спадать быстрее, чем расти число витков и для получения того же количества ампер*витков придется уже поднимать напряжение.
  10. Вся авиация на нем летает. Эти картинки вообще непонятно откуда. Двигатель расчитан на питание обмоток возбуждения и управления напряжением 36 В частотой 400 Гц. Я предполагаю, что момент на валу прямо связан с магнитодвижущей силой, а она определяется произведением амперов на витки. И если мы количество витков удвоим при том же питании, мы получим ту же МДС при вдвое меньших амперах и вдвое меньшей подводимой мощности. Я не прав? На ваших картинках произведение амперов на витки одинаковое, у меня же варианты использовать одну обмотку со второй картинки либо обе с первой при одинаковом питании в обоих случаях. Вопрос - какое включение лучше.
  11. Да-да-да. Лабораторный источник, напряжение (по недосмотру) 12 В, ограничение тока при замкнутых выходных клеммах выставлено на 10 мА. Подключаем индикаторный smd светодиод с максимальным током по документации в 20 мА. Вспышка светодиода, щелчок реле в лабораторном источнике, сигнализирующий о переходе в режим стабилизации тока, светодиод тут же гаснет, источник переходит в режим стабилизации напряжения. Светодиод в мусорку. Проверено неоднократно.
  12. Имеем двухфазный индукционный двигатель ДиД-0.5, у него есть обмотка возбуждения (36 В 400 Гц) и две обмотки управления. Обычно обмотки управления включаются либо параллельно к выходу мостовой схемы управления, либо же конец одной обмотки и начало второй подключаются к источнику питания, а подачей напряжения управления частотой 400 Гц (со сдвигом по фазе на 90 градусов относительно возбуждения) на начало первой либо конец второй обмотки выбирается направление вращения, т.е. фактически для вращения в каждую сторону используется только одна обмотка управления. У меня схема управления имеет мостовой выход, а обмотки управления соединены последовательно с выводом от средней точки (соединение обмоток поменять на параллельное нельзя). Я могу подключить выход схемы управления к средней точке и концу одной из обмоток, т.е. использовать только одну обмотку, либо же подключить выход схемы управления к началу первой и концу второй обмотки, т.е. использовать обе обмотки, включенные последовательно. В первом случае ток через обмотку будет вдвое больше, но количество витков вдвое меньше, во втором случае - ток вдвое меньше, но количество витков вдвое больше. Собственно вопрос: правильно ли я понимаю, что момент на валу в обоих случаях будет одинаковый и, следовательно, при второй схеме включения я буду иметь тот же момент на валу при вдвое меньшем токе управления, т.е при вдвое меньшей подводимой мощности управления?
  13. Выражение "на полпути" здесь было применено в переносном смысле. Мы-то с вами знаем, что половина не может быть большей или меньшей, но бОльшая половина народа этого не понимает
  14. Модератор: тему переместил. Не забудьте, очень интересно.
  15. Есть какие-то 16 или 32-битные переменные, которые изменяются прерываниях, а читаются в основном цикле? Если да, то обращение к ним в основном цикле должно происходить атомарно, т.е. при запрещенных прерываниях. В противном случае возможна ситуация, когда прерывание меняет переменную между чтениями ее байтов в основном цикле. Или наоборот - прерывание может обращаться к переменной между записями разных ее байтов в основном цикле.
  16. Покажите, как вы описали обработчик. У меня все сохраняется. Покажите сам обработчик - может у вас там только асм-вставка с некорректным описанием и компилятор не знает, что эта вставка портит SREG. ISR(TIMER0_OVF_vect) { //тут код }
  17. Значит его нет. Но если у вас несколько разных Report-ов, то нельзя сделать один без Report-id, а остальные с Report-id. Это так, но это не весь Report. Конечная точка может передать за раз не более 64 байтов. Более длинные пакеты передаются за несколько транзакций. Если в очередной транзакции принялось меньше 64 байтов (даже 0 байтов) - это конец пакета. Поэтому пакет длиной 64 байта передается как одна транзакция длиной 64 байта и вторая длиной 0 байтов. 65 байтов передаются как 64+1. Как чтение таких пакетов реализовано в кубе - я не в курсе. Может он сам выделяет Report-id.
  18. Как вы поймете, что его нет? Я не знаю, как еще объяснить. Вроде уже и английскую цитату привел, и русским языком написал. Читайте по губам: Если у вас может быть больше одного типа Report-ов, то Report-id передается всегда. Вне зависимости от его значения. Если Report только один - его Report-id можно не передавать, в этом случае он не указывается в дескрипторе. Если ваш Report имеет размер 64 байта и вам нужно передавать Report-id - вы передаете 65 байтов.
  19. Поставьте себя на место второй стороны. Вот пришел пакет. Как вы его будете разбирать? Как только вы осознаете, что вторая сторона никак не сможет различать такие посылки - вы поймете, что вы или прочитали какой-то ненадежный источник, или поняли его неправильно. В Device Class Definition for Human Interface Devices (HID) четко сказано: Т.е. если ваше устройство имеет только один тип Report-а, то он не передается. И номер его совершенно ни при чем. Во всех остальных случаях ReportID передается.
  20. И как вторая сторона отличит этот пакет с первым байтом данных, равным 1 от другого, у которого в первом байте передается report_id = 1?
  21. Jlcpcb.com Но аттракцион неслыханной щедрости закончился, теперь не 10, а 5 штук.
  22. Может кто-то подскажет, а то что-то гугля выдает не то, что я хочу. Имеем сеть устройств (водяные счетчики), умеющих LoRaWAN 1.0.3 (реализация стека "из куба STM32"). Их задача только отсылать показания раз в час. Обратной связи (подтверждений приема) нет - если какая-то посылка или даже несколько пропадет - не страшно. Они все прекрасно зарегистрировались через OTAA и все замечательно работает. Теперь предположим ситуацию, что сервер регистрации сгорел (физически) и сессионные ключи шифрования на нем безвозвратно утеряны. Ставим новый сервер с нуля. В спецификации 1.0.3 нет никаких намеков на rejoin-сообщения, есть только фраза "An end-device has to go through a new join procedure every time it has lost the session context information". Это если устройство потеряло session context. Про ситуацию, когда session context потерян на стороне сервера в спецификации ни слова. Получается, после такого фатального события надо обойти все счетчики и передернуть им питание, чтобы запустить OTAA заново, раздать устройствам DevAddr и сгенерить новые сессионные ключи шифрования. Я все правильно понял?
  23. Спасибо. Скорее всего я ограничусь подъемом оригинальной железки - чтобы жаба не задушила за выкинутые 14 евро. А в боевом устройстве будет F042. Несовместимость с протоколом, опять же, плохо - планировал использовать canhacker. Но с удовольствием посмотрю ваш вариант, чтобы не содить по лигним граблям.