Хочу спросить спецов по семеству этого чипа - at91sam7s64
Кто делал портативные устройства с минимальным потребленгием на нем?

Щас мной разрабатывается новый проект (на всяк случай - ссылка).
(планируется как открытый проект)

Вот есть такой ньюанс.
Так как устройство портативное, нужно минимальное потребление (здесь не требуется большая тактовая), тактовая около 1МГц, и потребление хочется до 0,5-1 мА.
С целью снижения потребления тока чипом - Тактовая, планируется до 1 МГц .
Из используемой пеерферии I2C, PWM, UART, ADC, GPIO, IRQ при планируемой частоте около 1МГц.
Также планируется слип-режим.

если верить даташиту то реально, но хотяд слухи что есть приведения в этом чипе и он меньше 1мА не потребляет даже в слипе - что сильно обламывает...

Это реально на этом проце на практике?

Почему я задался этим вопросом:
очень не хочется что бы после запуска оказалось что он реально не может потреблять меньше чем 2-3мА(а можети больше)

Если верить буржуям, то усыпить менее 60мкА не удастся.
Всё моё устройство на at91sam7s64(256) в ждущем режиме (500Гц) потребляет менее 3мВт от 5В.
Меньше по ТЗ и не надо было...
Мне больше понравилось импульсно потребить на 55МГц и уснуть - эффективнее чем на 1МГц.
Код естественно из озу - съэкономите 2мА.

я так тоже собирался делать, потому что нужно например будет по i2c общяться, а потом снова спуститься в слоу режим или в слип


не совсем понял что вы имели ввыду и из-за чего выигрыш?

.

Извиняюсь что не совсем в тему, но вы уверены что вам там ARM нужен? вариант с 64-ногой мега128, например, не рассматривали? gpio у него больше чем у этого арма, если проблема только с портами.

спасибо, можно было бы. изучу этот вопрос на запас, но данный вопрос актуальнее
честно говоря, я не смотрел на нее, 128ю
та и не наблюдаю особого превосходства ATmega128 над AT91SAM7S
а вот 64 пина - это аргумент...
хотя в контексте вопроса данного топика, может преимущество и есть - я не изучал такое вариант

и цена с небольшой разницей между ними кстати
AT91SAM7S64-AU-001 - 52,63 грн ( AT91SAM7S128-AU-001 - 59,15 грн )
против
ATmega128-16AU - 49,47 грн

но а все же, как по этому вопросу?

.

Из всей открытости проекта не понял, почему не хватает ног. И тем более причину, почему выбран ARM (а не какая-нибудь мега с большим количеством ног), а даже если ARM, то почему не более оптимизированный по потреблению STM32?
Может, посмотреть в сторону MSP430F2274 или PIC24F?

вопрос с же не в выборе чипа, а в другом, в потреблении для AT91SAM7S64

Раз спросили, я отвечу на Ваш вопрос, ибо у кого то еще он может тоже возникнуть.

STM32 - ни когда в жизни, с ST связываться не буду, мне его на работе хватает с головой, до ненависти. + горький опыт политики ST, еще 2 года назад мне ясно на своем опыте - не связываться с ними. никогда по своей воле...
MSP430 - я не могу объяснить причину, начитался в одно время в инете и тут на форуме про них - решил не связываться, да и под линуксом их девелопить нельзя.
PIC24F - симпотично, одно время я любил пики, но потом... уже как 4 года стараюсь не связываться с ними, причина простая - микрочип напрочь отказываются "сотрудничать" с линукс.
AVR и ARM можно дебелопить из под линукса, вот и весь выбор.
не хочу спорить, это мое мнение - выслушаю с удовольствием все предлежения, с благодарностью.

а да, почему ARM вместо AVR в данном проекте... Сейчас схема и плата делается из расчета что бы можно было ее использовать и в будущем для других проектов, заказав на заводе всего один раз..
Если сразу заложить AVR то перспективность резко срезается.
А если ARM то есть шанс еще пару проектов(а то и больше) в этом же корпусе не расскручивая его сделать. этого многим не хватает. это мое мнение под которым я веду идею при разработке. и все.

.

Простите, но Вы бы не могли разъяснить Ваше понимание этого
Вы желаете использовать только нативные для линукс средства разработки и принципиально против использования всего виндового даже под вайном и/или Вас беспокоит исключительно лицензионная чистота? Или просто не хотите переключаться?
Я вот сижу под Infra-Linux (Ubuntu), но что касается разработки, то пока у меня всё в вайне или виртуальной винде. Вот такой маргинал Ещё и удобства обеспечил http://ubuntueasy.com/jemuljatory/zapusk-i...oj-v-virtualbox
Что касается выбора камня, то расскажу Вам об одном проектике - есть у меня большой контроллер на базе LPC2378, который обеспечен мощным BSP, так вот пришлось делать проект, в котором нужна его мощь, только иногда - много спим и иногда работаем. Дабы не бороться с описанными и неописанными в доке недорежимами пониженного энергопотребления, но таки использовать имеющиеся наработки, был сделан гибрид ужа и ежа - в новый аппарат был добавлен MSP430F2013 для управления питанием, который по команде от большого брата выключает ему питание. Но я не постеснялся положить рядом с LPC на имеющееся место PIC24 и STM32 для случая, когда потребуется не универсальное, а более дешёвое решение. Вот на прошлой неделе жареный петух клюнул - пришлось аврально поработать - написал начиночку для MSP430F2013 и BSP под PIC24FJ16GA002 - теперь наработки от LPC2378 пойдут и на этом камушке. Так что универсальность иногда бывает с другим лицом

Спасибо - почитаю, интересно.
я не хочу нахинать холивор - мне так всегда было спокойнее и приятнее (хотя и не всегда легче). очевидно что в разработке области радиоэлектроники без винды сегодня трудно, просто я свожу к минимуму ее использование.
у меня крутится в виртуалбоксе винда, и там только пикад, и все.
еще раз, я не хочу разводить холивор на эту тему уважаю чужой выбор и хочу что бы уважали мой выбор.

но а все же,
может есть ктото кто может сказать конструктивное чтото из личного опыта по дпнному вопросу потребления?


.

Когда нет обращений к FLASH памяти, то она "отключается" и перестаёт потреблять 2мА по 3.3В
Это происходит автоматически и никак не мешает работе.

Кстати SAM7S64 лучше Atmega128 наличием USB для будующих проектов иначе можно использовать SAM7S32 или SAM7S16 в меньшем корпусе и за меньшие деньги.

Преимущество SAM7S64 перед Atmega128 в наличии ПДП, т.е. при передаче данных в/из SSC,SPI,RSxxx... можно вообще выключать ядро - МК делает всё сам - выше производительность и ниже потребление.

PS: I2C (как и у других МК) лучше программный делать если это прибор а не игрушка.

Я принципиально не против, и пытался год назад пересесть на убунту. MPLAB IDE хотя и работает под вайном, но как вы MPLAB ICD при этом пользуете? Ни вайн, ни ВМВАРЕ USB практически не поддерживают, не считая усб-дисков....

пользуюсь VirtualBox2.1.4, а у него работа с USB-девайсами прямоугольная - тупой перехват - можно либо все девайсы перенаправить, либо отфильтровать какие отдать, а какие нет. Честно пока не включал именно MBLAB ICD, но с мостами и эмуляторами типа AVR Dgragon, Jet-Link, AVR JTAG ICE MKII (правда у этого свои глюки с USB безотносительно виртуалки), eZ430-RF2500 - работает

Честно говоря не разу не использовал JTAG на AT91SAM7S, и на моих платах он вообще не разведён и заземлён в целях экономии места и питания.
А для унификации программирования AT91SAM7S64 и AT91SAM7S32 я вообще пользуюсь SAMBA через COM порт, а не через USB.
Наличие третьего урезанного UART у AT91SAM7S позволяет остовлять его для вывода служебной информации и программирования.
Использую 6 контактный разъём на платах: GND,3.3V,DTXD,DRXD,TST,ERASE и мои волосы шелковистые

самая гремучая смесь автономности периферии и экомичности проца - MSP430. под линукс он девелопится: или GCC или коммерческий CrossWorks. это так - с ходу называемое.
получите сотни наноампер в спячке и полмиллиампера на 1MHz. устроит?

устроит ) и снова сменить проц 8))) я не спорю он может и хорош, но, у меня нет желания заменять текущий выбор проца, та и я уже с ним знаком както, а MSP430 прийдется изучать ибо новый.
а вот то что MSP430 под линем девелопится - не знал, почитаю еще раз, спасибо за инфу, спасибо.

Но все же, я вопрос хочу акцентировать именно на текущем выбранном контроллере - AT91SAM7S64

.

У современных ноутбуков и тем более нетбуков COM-порт всё труднее найти. А мост к USB подключить ничего не должно мешать

захотите от батарейки жить не две недели а два квартала - возникнет и желание


фигасе новый
ему уже 10 лет!

Делал проект на pic16F946. 18uA в среднем (включая LCD и прочее на плате), конечно спит большую часть времени. Подверждаю, что лучше гнать проц на максимальной его частоте, но минимально короткий промежуток времени, чем выбирать низкую частоту.

да, тут я не спорю, полностью согласен


я мел ввиду что новый именно для меня, а не вообще ))

а мне кажется, глядя на графики токопотребления, что разницы нет. всё дело в количестве затраченных тактов на одно полезное действие.

Не знаю про графики, я говорил основываясь на своих экспериментах. 10000 тактов требуют меньше энергии если их пройти на большей частоте.

я так и предпологал, (как Вы иговорите) что куда намного экономичнее находиться постоянно в слипе и просыпаться только сделать действие/реакцию на какоето событие...
чет мне кажется это нужно еще исследовать, ведь 40кГц потребляет мизер, правда и работает все время...
если источник питания не позволяет отдать большой ток(напримет от солнечной батареи) в режиме большой чатоты, то не прокатит такое...

.

что-то я не вижу физического обоснования в повышении экономичности от работы бурстами.

есть такая вещь как конденсатор

Физическое обоснование одно -- я говорил про внутренний RC осцилятор. Может, если гнать от внешнего, разницы может и нет. А частота внутреннего у ПИКа была 8МГц. И она не меняется, даже а только делится если вы выбираете меньшую. есть правда у него отдельный 32кгц, но это слишком медленно было для меня.

Вообще это интересная тема... кстати, а кто как меряет потребление тока, если оно идет рывками и на уровне 10-100uA?

ну так это надо было оговаривать, а то получается что все камни лучше пускать бурстами.

задумался, вспомнил, обговорил

О да, это вы очень верно подметили - интересный вопрос, кто как меряет когда контроллер в режиме "рывков" работает?

.

Если рывки не очень редкие, то можно и китайским тестером измерить. В противном случае измеряем потребление на полной скорости и в слипе, и считаем потребление исходя из соотношения работа/сон по времени.

Китайским вообще не получится, и вторым способом тоже плохо -- на полной скорости вся схема может просто не работать или работать совсем не так. Опять же это не отвечает на вопрос сколько же все-таки потребляет устройство в его обычном режиме?

Я делал такую схему для измерения:


Параметры резисторов и конденсаторов нужно выбрать в зависимости от частоты пульсов тока их диапазона макс-мин тока. Диод нужен для обеспечения работы схемы в момент загрузки, когда она бежит на полной скорости. Его надо тщательно проверять на leakage current в рабочем диапалоне токов.

Ставлю перед нагрузкой стабилизатор напряжения (как у батарейки) с малым (желательно практически фиксированным) собственным током потребления. Перед ним ба-альшой конденсатор (его заряжаю) с выключателем. Провожу измерение напряжения на конденсаторе высоковольтным вольтметром. За фиксированное время узнаю дельту. Ну а дальше просто I с небольшой ошибочкой равен dI

Неплохо, а зачем тогда стабилизатор? Не лучше ли всю нагрузку питать от конденсатора? Да, еще минус то, что баальшие конденсаторы имеют обычно точность +80/-20. Надо еще кондер мерять точно....

У меня батарейный девайс - соответственно меня интересует потребление при определенном напряжении питания девайса, с другой стороны удобно измерять достаточно большое dU. Таким образом я заряжаю конденсатор, например, до 9 В, а могу отключить примерно при 4 В, т.е. получаю более точное результирующее значение малой кровью. Естественно, точку во времени ранее момента достижения 4 В оцениваю по более грубым предварительным измерениям. А не помеха - её померять нужно аж раз в год, потому как средний ток потребления является только одним из факторов, определяющих время автономной работы. Т.е. для очищения совести разработчика/наладчика важно достаточно точно померять средний ток потребления (а чаще отклонение от контрольного образца), но для реальных условий (саморазряд батареи, уменьшение емкости/увеличение внутреннего сопротивления при понижении температуры окружающей среды и др.) можно смело умножать на коэффициент, т.е. просто лучше не будет.

Неплохой способ для измерения тока на этапе разработки, но видимо слишком долгий для QA на производстве.

Что мешает взять конденсатор с меньшей емкостью?
Но по правде да - используем этот метод при разработке и когда по набору признаков (токи/напряжения) прибор отличается от образцового экземпляра
ЗЫ А емкость конденсатора этим же методом меряется подключением в качестве нагрузки известного резистора (фиксацией тока нагрузки). Собственная утечка также оценивается по разнице результатов при разных нагрузочных резисторах и картине без нагрузки. Тут некоторые проблемы возникают всвязи с эффектом "памяти", но если о нём не знать, то всё достаточно осязаемо

угу, так то-есть практика показывает что работать "импульсом" это нормально.
ок.
вот тогда теперь еще такой вопрос такой:
развел я плату - ( запостил туда же ), получилось что почти все дороги 0,2-0,25мм...
сделать толще не получается, очень плотно дороги друг к дружке.
достаточно ли будет этих толщин дорог для "импульсного" алгоритма???

.

А конденсаторы байпассные на что? Расставляешь где нужно и должно быть всё путём. Конечно приятнее, когда питание подводится чуть более толстым, но и менее толстые при правильной топологии годятся. А при неправильной плохо будет независимо от ширины дорожек. ИМХО.

Достаточно для чего?? нормальная ширина...

всмысле, достаточная ли ширина дорожки, для "импульсного" режима работы
прикол то в том что вво время работы ядра ARM7 ток потребления контроллером может достигать 50 мА.
вот я про это и боюсь. но проблема в том что там толстые дороги не получается провести 8(
просто уже некуда 8(


да, но они по одному электролиту стоит на DC-DC и по одному возле контроллера.
опираясь на заложенный типо размер корпуса - больше чем 47мкФ по моему нету.
да,да я знаю что питание лучше толстыми вести, но там не получается, по трассе несколько мест где вынужденно сужается до 0,2-0,25мм
А вот как будет проявляться поведение и ограничение ширины дорожки при токе потребления в 50мА во время работы ядра арма на тактовой в 18МГц(или больше)

.

В даташите английским по белому написано, что на частоте 16МГц потребление при всей включенной переферии составляет менее 12.3мА по 3.3В и 12.1 по 1.8В, и даже на 48МГц не превышает 30мА. Вы там что светодиодами пыхаете на прямую?

Я ставлю 0603 0.1 мкФ на каждую ногу питания, один 2.2 мкФ на выход 1.8В, 2 шт 2.2мкФ на вход 3.3В - всё. расстояние 0.5мм между конденсаторами и ногами МК. Дорожки 0.2мм

э, нет. так не пойдёт. надо керамику (например, 0.1 мкФ как пишут коллеги) по-ближе к пинам поставить, ну и, ИМХО, желательно землю в районе корпуса без переходных водить. А электролиты небольшие в количестве аж 1 шт после стабилизатора ставлю, танатал. _afc_ насчёт емкостей в общем правильно глаголит

именно так у меня и стоит керамика, по 0,1 мкФ прямо под чипом на 3,3 и на 1,8 и там же сразу впритык стоят электролиты
+ по шине питания ещё несколько разбросано, а вот на каждый пин это перебор в данной конструкции, тут и так развернуть негде 8))
да и как личная практика показывает, этот камень себя уверенно чувствовал при постоянной работе со всей включенной периферией на 18МГц замечательно, с такой же комбинацией кондеров, это из личного опыта..
но в целом замечание полностью поддерживаю - но это сделано специально и осознано без страха и риска. 8)
( на всяк случай ссылка с схемой - http://projects.org.ua/forum/viewtopic.php?t=2141 )

посмотрел. странные моменты. Какое напряжение батареи? 3 В? тогда следует, что на месте DA1 MC34063 не годится - она имеет минимальное входное 3 В, а у Вас ещё и диод последовательно. Далее на DA2 нарисован повышающий стабилизатор, при этом на вход подаёте 5 В, а с выхода снимаете 3.2 В. А где узел отключения питания? Если его нет, то о микропотреблении с включенными стабилизаторами и ЖКИ вообще говорить нельзя. Непонятно назначение C28 - либо ШИМ-ом включать/выключать подсветку, либо организовывать регулируемый источник тока - для первого случая конденсатор только мешает, а для второго не хватает резисторов в эмиттере и базе VT3. Практически не знаком с AT91SAM, потому просто не знаю, есть ли возможность включать pull-down резисторы на портах - если нет, то со входами кнопочек несуразица получается - висячие входы или, при наличии включенных pull-up, оно просто не будет реагировать на кнопы; то же относится к джамперам J2-J4. Баззер вам вполне может понадобиться и без измерения счётчиком Гейгера, потому вполне можно его зацепить на 3 В. Схема импровизированного ЦАП-а для управления контрастностью ЖКИ имеет слишком большие сопротивления резисторов, чтобы корректно работать, да и как-то не вяжется с диодом в питании самого ЖКИ (зачем он вообще?). Да и регулировка контрастности для чего? Если по температуре, то датчик на борту должен быть, а не опционально. Не нашёл подтяжки по цепи D31 - могут быть проблемки. Узел детектора при наличии контроллера, ИМХО, должен из одновибратора нивелироваться до триггера Шмитта.
Короче, сыро. Так как до конца не понимаю назначение и ограничения, то советовать пока продуктивно не получится.

спасибо, Вы заметили пару мест которые я не увидел.
отписался в личку к Вам.
позже, постарюсь детально ответить тоже и здесь

Да, 3В, 2 батарейки по 1,5В
кстати
в корпус может еще вставляться "крона", а она 9В. и следовательно схемы включения DC-DC нужно менять... - но я пока крону не рассматриваю


угу, диод Шотки, на нем 0,2-0,4В упадет, это нужно для того что бы сделать низкий барьер, ибо используемтся "схема включения для умножения"
если честно я еще не нашел ничего достойного к замене MC34063 ... но спаасибо подталкнули - вылетело с головы...
Ранее, в версии с AVR был заложен LM2621 - он от 1,2(до 14В), но и он намного дороже.
просто еще не все еще у нас в городе можно купить, или стоит очень дорого, поэтому еще учитываю цену.
вероятно или даже возможно верну назад LM2621.

я участок с DC-DC специально сделал отдельно, он вообще будет как самостоятельный кусок платы, с возможностью полного отсоединения от платы.


раньше было последовательно 2 DC-DC, сперва 5в, а уже из них 3В
потом я сделал их от одного источника ~3V(2 батарейки) и упустил этот момент...
Спасибо что заметили, исправил в оригинале..


Отключать / включать глобально - кнопкой питания.
Основное время устройство будет спать
я это уже описывал как задумал.


1 - он заложен в резерв
2 - предусмотрен для ШИМ, но еще не факт что будет ШИМ в реале.


Да - pull-up можно, pull-down - помоему нельзя.
На кнопочки реагировать должен - ибо если порт на вход, то по их нажатию будет появляться "1" на входах с vcc3, иначе там на "висячих входах" 0В, то есть "0".


это не джамперы в реале - а просто патерны 8))
в которые или запаять светодиоды(тогда резисторы заменяются на по 510 Ом) или перимычки, но там должны быть "1" для программирования SAM-BA по DBGU


по что Вы здесь сказали я не совсем понял к сожаленью


вот тут не исключаю Вашу правоту
изначально было в R-2R по 10-20к, но потом (в топике описано) при подсчете тока потребления пришлось из увеличить, возможно Вы правы, но мне кажется нормально.
Это я эксперементиирую.


в принципе не нужен, это предусмотренный резерв, патерн, в реале там может быть или резистор или перемычка


LCD бывают разные, я их много перепробовал, и даже в одной серии при одинаковом напряжении контрастности они по разному показывают, по сему отдан этот вопрос на пользовательсткую опциональность.


его можно впаять на плату вместо разъема.
или же впаятьразъем и сделать внешний термодатчик, тут на выбор, тоже специально.


не будет - буду использовать pull-up контроллера.


Извеняюсь, не совсем понял о чем речь.



не спорю, возможно сыро, не с кем обсудить тонкости.

собственно я все выше описал, если есть что предложить - с удовольствием выслушаю.

Заранее спасибо.

.

откуда такая уверенность? IMNHO, это заблуждение. А оборванные входы у КМОП-микросхем вообще очень неприятный момент.
Баззер-ом я обозвал аглицкий buzzer - считаю, что пищалки могут быть использованы не только для тревоги, но и для обозначения нажатия на кнопки и др.
это у Вас какой-то особенный опыт.
Насчёт одновибратора - так называемый "удлинитель импульсов" при наличии контроллера со входом внешнего прерывания, IMNHO, есть просто изврат. Аппаратно после детектора нужен аналоговый дискриминатор - вот в качестве его и нужно использовать триггер Шмитта. Есть вероятность, что такой триггер уже есть на соответствующем входе контроллера.

во время сброса встроенный pull-up не обязан быть включен

Ну и в личку накатал