Телеметрия (часть 1)
У двухосевого 1052 сравните корпус 10-pin MSOP и 16-pin LCC на странице 5.
И посмотрите 1-осевой 1051Z в корпусе 8-pin SIP на странице 4, который я собираюсь использовать, ибо 10-pin MSOP нигде на складах нет (cм efind.ru), а 16-pin LCC - кошмар.
Я паял MSOP, тоже не подарок. А у LCC есть выводы сбоку.
По поводу того, как привязан PPM, входы с пирометровых голов и с магнитометров - поругайте, если не лень 😃
А мне надо очень хорошо подумать, как строить программу чтобы корректно выходной PPM формировать, без задержек и прочая, а то сервы будут дрожать. Раньше я почему-то об этом не подумал.
А у Атмег прерывания реентерабельные? Т.е. что будет, если стукнет прерывание пока я обрабатываю другое прерывание? Подозреваю, что ничего страшного не произойдет, но все тайминги на моей совести 😦
Я вот одного не пойму - ну если всё равно городить внешний ОУ, почему сразу не поставить нормальный АЦП? 😃 Тот же корпус, но нет кучи пассива с пол процентными допусками, который ещё и отстраивать надо. Нету кучи математики для вычисления курса из того г-на, которое получится после усиления ОУ и оцифровкой меговским АЦП. Ну нафига себе проблемы то создавать? 😃
Видимо, тяга к аналогу, это как свинка. Надо один раз переболеть, чтобы потом на всю жизнь иммунитет…
Кстати, купить АЦП ничуть не сложнее, чем этот ОУ.
Прерывания в меге встают в очередь, по приоритетам. Внутри прерывания ничего не происходит, но после выхода из прерывания чип выполнит 1 команду и снова уйдёт в прерывание. Самое приоритетное в очереди.
Таблица приоритетов есть в ДШ.
Проблем с генерацией не будет - регистры таймеров с двойной буферезацией. То есть пока генерится один период ШИм, обновлять регистр можно как хош часто. В качестве нового значения будет принято то, которое было в регистре в момент окончания периода генерации.
Чёта я схему не пойму. А ШИМы там что, не аппаратные? 😃
Вот, фото моих пирометров 😃 Фото головы в сборе и графики чуть позжа.
А у Атмег прерывания реентерабельные? Т.е. что будет, если стукнет прерывание пока я обрабатываю другое прерывание? Подозреваю, что ничего страшного не произойдет, но все тайминги на моей совести 😦
Для нестинга (если Вы это имеете ввиду) у Атмег достаточно после входа в процедуру обработки прерывания установить флаг глобального прерывания (тем самым подтвердить прерывание). В следующем командном цикле может быть принято и обработано следующее прерывание (внутри текущего прерывания).
а, черт!..Полностью согласен! Про нормальный АЦП и по прерываниям. Походу PWM программный-дрожать будет в зависимости от сложности остального софта(подключал в свое время аналоговый стрелочный вариометр к 8051 без PWM- все вылизал, а стрелка дрожит, как осиновый листок). Не связывайся- много бестолкового секса будет 😃 . В приемнике можно- там ниче нет больше. А про выбор процессора, я лучше помолчу…(LPC21… 6 асинхронных каналов, например)…молчу 😵
PWM аппаратный будет, это я протупил просто. Схемку перерисую.
Насчет нормального ацп - мне меговского хватает.
Гуру, не будет наглостью попросить ссылок на доки, где описано, как правильно общаться по SPI между мегами?
Интересует не только передача данных, но и прошивка младшенькой меги силами старшей.
Ну и еще, до кучи, у старшенькой меги на том же SPI внешняя память должна висеть. Как это разрулить?
Раз набрался смелости, вот еще вопрос: а не сможет ли кто-нибудь за разумные деньги в несколько дней сделать пару печатных плат?
Заказывать на заводе - долго и дорого, да и надо-то пока только дорожки с одной стороны и никаких отверстий. Паять всё соплями к at90usbkey - неохота. И без этого есть что на нем поотлаживать 😃
Ну вот, грабли! Вилы! 😮 Ну вот, будем протокол придумывать! SPI- сдвиговый рег. обычный. В данной апп. OSD- мастер, вывод делать в кадровом прерывании, например, дополнительное прерывание вводить нельзя- будут строки выпадать, или сдвигаться, из- за очереди прерываний, а так, все ручками… Хотите ARINC-4xx освоить в “свободное” время 😛 ?? Для прошивки Мег, использую мегалоад- ниче удобнее не пробовал- автоопределение, по сбросу. Можно переписать на любой физ. интерфейс, а основную делать прозрачной, во время прошивки. Но, ARM7 имеют на борту заводской лоадер и оригинальные процедуры входа… SAM7S- USBloader, и всего 48 пинов! О чем еще мечтать?! вот под что плату нада делать, а не возиться с протоколом и читать всякую ересь 😉 !
Atmel’s AT91SAM7S is a series of low pincount Flash microcontrollers based on the 32-bit ARM
RISC processor. It features a high-speed Flash and an SRAM, a large set of peripherals, including
a USB 2.0 device (except for the AT91SAM7S32 and AT91SAM7S16), and a complete set
of system functions minimizing the number of external components. The device is an ideal
migration path for 8-bit microcontroller users looking for additional performance and extended
memory.
Собственная софтинка для прошивки at90usb128 со штатным бутлоадером через USB у меня уже давно готова. Пересылка данных по USB меге и обратно готова. Не быстро правда, всего 32кБ/сек, но для моих нужд хватит. 2 МБ полетных данных с флеша сольется в компук за минуту.
Нужно только вот дополнительно уметь прошивать мегу8 через SPI силами at90usb128, подключенной к USB. Для удобства обновления прошивок платы телеметрии. Ну да сам разберусь, спасибо.
Количество граблей и прочего шума в теме зашкаливает, теперь буду писать в тему по минимуму.
Если кто-то сможет через недельку помочь с парой опытных экземпляров печатки, не забесплатно, конечно - стукнитесь, пожалуйста, в личку или в почту!
Гуру, не будет наглостью попросить ссылок на доки, где описано, как правильно общаться по SPI между мегами?
Интересует не только передача данных, но и прошивка младшенькой меги силами старшей.
Ну и еще, до кучи, у старшенькой меги на том же SPI внешняя память должна висеть. Как это разрулить?
- Ссылок не дам (atmel.com 😃 ), но могу дать свои рабочие исходники обмена между мегами на C.
- Прошивку ведомой меги силами главной не делал, т.к. у меня в ведомых мегах весьма простые программы сбора данных, которые достаточно было отладить один раз, все навороты в главной.
- С внешней памятью и т.д. на том же SPI никаких проблем, просто выбираешь с кем надо обмениваться сигналами SS и все. Иногда приходится дополнительно перенастраивать CPOL и CPHA.
- Не пробуй сэкономить и отказаться от SS, отличный способ создать себе массу проблем. Мне пришлось потратить кучу времени чтобы данные передавались надежно.
Для нестинга (если Вы это имеете ввиду) у Атмег достаточно после входа в процедуру обработки прерывания установить флаг глобального прерывания (тем самым подтвердить прерывание). В следующем командном цикле может быть принято и обработано следующее прерывание (внутри текущего прерывания).
Тока выйдя из следующего прерывания мы окажемся в текущем прерывании, а дальше куда?
Надо писать код, сохраняюший вектор возврата. А это есть изврат. Гораздо проще написать грамотные прерывания, максимально короткие, чтобы всё успевало выполняться.
Гуру, не будет наглостью попросить ссылок на доки, где описано, как правильно общаться по SPI между мегами?
Интересует не только передача данных, но и прошивка младшенькой меги силами старшей.
Ну и еще, до кучи, у старшенькой меги на том же SPI внешняя память должна висеть. Как это разрулить?Раз набрался смелости, вот еще вопрос: а не сможет ли кто-нибудь за разумные деньги в несколько дней сделать пару печатных плат?
Заказывать на заводе - долго и дорого, да и надо-то пока только дорожки с одной стороны и никаких отверстий. Паять всё соплями к at90usbkey - неохота. И без этого есть что на нем поотлаживать 😃
Прошивка младшей описана в ДШ, в разделе memory programming. А как правильно общаться… Да как хочется, так и общайся 😃 Я для себя выдумал такой протокол:
#[addr][sender][lenght][data]
Адрес получателя, отправителя, длина поля дата и данные. Работает на любом протоколе, в том числе на И2Ц.
Когда чип не выбран лапкой CS, он по спецификации должен держать свои лапы в Z. При программиовании и ресете лапы МК также переходят в Z, по этому следует предусмотреть подтяжку, чтобы память не подгаживала на шину, когда рулящий чип в ауте.
Платы могу сделать бесплатно, вот как доставить? Возможно, на след. неделе буду в Москве, но не факт… Почта недели две идёт.
ПС. Я таки победил пирометры! 😛 Работают!!! Все 4, горизонт видят, всё мериют и вообще работают супер. Пока испытывали только на шесте, но на неделе полетим и запишем в полёте. Но даже на шесте по пирометрам можно было выровнять потожение шеста так, что проверка отвесом показывала 100% совпадение.
Ну вот. С Днём Рождения, блин! 😃 Может сам на себя посмотреть:
С детства роботов люблю!
С “демо” данными:
Что- то типа: “В ШТОПОРЕ”, с маркером автопилота…
Сорри, нет фото-камеры…(OSD 72x192 слева скорость, в центре- курс, справа вертикалка, внизу- скольжение+ контроль скольжения +8 aux индикаторов-%) Ну и не сделать толком больше на Меге ниче- все завязано на строчном прерывании… 😃 ~20kb -opt 3. Про обмен датой:
Самое простое- обмен по SPI. Скажем 32 байта туда<->сюда +1 sync, по одному в конце строчного прерывания- мастером!
Надо писать код, сохраняюший вектор возврата. А это есть изврат.
Всегда считал что он автоматом сохраняется в стеке 😃 а затем извлекается оттуда командой RETI. Просто в стеке окажется два вектора возврата, но и команд RETI будет выполнено две (может и больше уровней вложенности оказаться)
Проверено, работает. Но редко реально нужно.
Тока выйдя из следующего прерывания мы окажемся в текущем прерывании, а дальше куда?
Надо писать код, сохраняюший вектор возврата. А это есть изврат. Гораздо проще написать грамотные прерывания, максимально короткие, чтобы всё успевало выполняться.
Как я понял, Вы меня опять втягиваете в безсмысленный спор 😃 . А зря. Поверьте, кроме Вас есть еще люди, которые пишут и достаточно давно для AVR, да и для других процессоров.
Вложенные прерывания (Nested interrupts) вещь достаточно стандартная, и широко используемая. В случае AVR (как уже было сказано выше) по команде RETI автоматически из стека извлекается вектор возврата, причем количество вложенных прерываний ограничивается только размером стека. А вот STATUS регистр нужно сохранить в ручную, но это нужно делать вне зависимости от вложенности. В принципе, и вызов и возврат из подпрограммы происходят также, только не сбрасывается флаг прерываний. А отказываться от такого мощного инструмента как Nested interrupts (там где это необходимо), это действительно изврат.
причем количество вложенных прерываний ограничивается только размером стека.
Об этом я и написал, вы опять не хотите вникать в суть, видя лишь верх.
Если вы будете писать код, который не успевает обрабатывать прерывания, очередь прерываний запросто переполнит стек. Что есть путь в никуда, умышленное снижение надёжности своей программы.
Не говоря про то, что стек у АВР, понятие весьма условное 😉
Это не PDP-6, та позволяла вообще на одних прерываниях жить…
Инструмент мощьный, но пользоваться надо осторожно. Я от него отказался и пока не встречал задачи, где без вложенных прерываний ну никак не обойтись, хотя пишу в основном шельф-менеджеры.
>>А вот STATUS регистр нужно сохранить в ручную, но это нужно делать вне зависимости от вложенности.
???
Если когда и сохраняют статус, то при ручном отключении прерываний внутри большого и важного прерывания. Но я это видел крайне редко в чужих кодах… И то если есть опасность включения настроек компилятора, разрешающий вложенность. Так сказать, для страховки (у нас тут основной критерий к коду - возможность повторного использования, реюзибл), на случай переноса куска кода в другую программу или компилятор. Если настройки нет и cli включается, компилер это заоптимизует и уберёт сам.
Об этом я и написал …
Ну допустим не об этом Вы писали а о адресе возврата из прерывания, который вдруг куда-то исчезает. Возможно Вы не смогли правильно выразить свою мысль. Допускаю. Но к сожалению, создается впечатление, что это Вы в суть не вникли, но обязательно хотите оставить за собой последнее слово. Надеюсь, что это впечатление ложное.
Вложенностью прерываний можно и нужно пользоваться. А для того чтобы стек не переполнялся, действительно нужно уметь писать грамотный код (как Вы правильно заметили ранее).
>>А вот STATUS регистр нужно сохранить в ручную, но это нужно делать вне зависимости от вложенности.
А здесь я допустил неточность, признаю. Это нужно делать в С программах только для прерываний, реализованных на ассемблере или с атрибутом naked. Но это было просто к слову.
А по существу, я вообще-то ответил smalltim-у, и поскольку комментировать или задавать вопросы он не стал, значит информация его либо удовлетворила, либо была излишней. Тем не менее, если интересно (smalltim-у), могу предложить свой код проекта OSD (тоже по мотивам Томаса Шерера двухлетней давности) на ATMega 168 , написанный на AVR GCC, с вложенным прерыванием строчного синхро. С его помощью я пытался реализовать графический и текстовый режимы в одном экране, вобщем довольно успешно. Хотя, по себе знаю, хуже нет чем ковыряться в чужом коде.
Тем не менее, если интересно (smalltim-у), могу предложить свой код проекта OSD (тоже по мотивам Томаса Шерера двухлетней давности) на ATMega 168 , написанный на AVR GCC, с вложенным прерыванием строчного синхро. С его помощью я пытался реализовать графический и текстовый режимы в одном экране, вобщем довольно успешно. Хотя, по себе знаю, хуже нет чем ковыряться в чужом коде.
Не знаю как Тимофею но мне было б очень интересно посмотреть 😒 .
Да ради бога. Только e-mail в личку бросьте.
Ну допустим не об этом Вы писали а о адресе возврата из прерывания, который вдруг куда-то исчезает. Возможно Вы не смогли правильно выразить свою мысль. Допускаю. Но к сожалению, создается впечатление, что это Вы в суть не вникли, но обязательно хотите оставить за собой последнее слово. Надеюсь, что это впечатление ложное.
Вложенностью прерываний можно и нужно пользоваться. А для того чтобы стек не переполнялся, действительно нужно уметь писать грамотный код (как Вы правильно заметили ранее).
Я писал о возможности потери вектора возврата при уровни вложенности более 1. Поясню.
Стек может переполниться запросто, причём даже не самими векторами возврата. Любая функция, особенно, если вызывается редко и из прерывания, да написана не тобой, может резко возжелать стек. А там уже данные основного кода. И вот тут очередному прерыванию понадобится сохранить вектор. А некуда! И всё - ниточка прервалась и получаем “адресе возврата из прерывания, который вдруг куда-то исчезает”.
Понятно, что если функции не хватит стека, это само по себе нехорошо. Но проц может и не зависнуть от этого. А вот от потерявшегося прерывания зависнет 100%. Или уйдёт на нулевой адрес (рестарт). Причём переменные в памяти и регистры сохранят свои значения и если код писался без лишней инициализации (есть такие экономщики, ставящие на дефолтные значения по ДШ) армагидец обеспечен.
А вы можете выложить видео с последнего полёта куда-нибудь, где его можно скачать? На том сайте дают только смотреть…
Я писал о возможности потери вектора возврата при уровни вложенности более 1.
Вы, извините, говорите о тривиальных вещах, которые сами собой разумеются. И писали Вы не о возможности потери вектора, а невозможности использования вложенности без какого-то дополнительного кода, который нужно городить.
Надеюсь, что в Ваших программах Вы следите за вложенностью функций (а не только прерываний), потому что при таком подходе и они для Вас также будут представлять угрозу переполнения стека, так как тоже сохраняют в нем адрес возврата.
Вот, “босяцкий” индуктивный рпм сенсор, средствами меги, может работать БЕЗ ПРЕРЫВАНИЙ!
(Катушка- половина рас…еного РЭС-22)
[codebox]
int FeatureCalcRpm;
ADMUX |=_BV(REFS0) |_BV(REFS1); //2.56v at AREF pin
ADCSRA |=_BV(ADEN); //Включаем шнягу…
ACSR |=_BV(ACIC); //Компаратор- как источник сигнала ICP, по отрицательному фронту…
TCCR1B |=_BV(CS11); //|_BV(ICNC1); //Timer1_Freq=XTAL/8 минимальная частота измерения~30.5hz макс.~1mhz
или частота проверки бита захвата. У меня проверка в конце “тела” строчного прерывания 15625херц
if (bit_is_set(TIFR,ICF1)) {
TIFR|=_BV(ICF1); //сброс
TCCR1B = 0x00; //стоп
TCNT1=0x00; //сброс
FeatureCalcRpm=ICR1; //сохраняем
TCCR1B |=_BV(CS11);//|_BV(ICNC1); //старт
}
RotationzPerMinute=(XTAL/8/FeatureCalcRpm)*60; //>>1, если 2 магнита
[/codebox]
Резистором “чувствительность” можно менять область применения 😁
(без него-“измеритель шума”)