Jump to content

    

prst

Свой
  • Content Count

    702
  • Joined

  • Last visited

Everything posted by prst


  1. Подскажите плиз как борольться с Altium-овским глюком, ну или как победить, а может и чтото у меня не правильно (не исключено) Когда делаю Annotate, то, при переименовании всей схемы меняются местами части микросхемы. Библиотека сделана своя (как к примеру как тут или тут), в ней микросхема разбита на слоки как "части". Не исключено что может влиять какато галочка, но я вроде все перепроверил... Помогите плих побороть это. Становится вот так : http://ybex.com/d/q3c275dwd7xr85f5zb6rz7ye...g1qdi07ux0.html В то время как должно быть вот так : http://ybex.com/d/euuwkw8outxe1k4vp7okw3ur...va7bg05eus.html
  2. таксь, проблемма, причём какая-то странная. вот я написал это своё OTP, причем оно основано на том что предлагал TI, только в коде еще одним слоем протокола обросло, тоесть проблема явно не в коде... Я его шью в 0x380400(для моего TMS320F28335) но оно шьет только секцию .InitBoot (она там у меня 28байт) и при попытке писать следующую следом секцию .text (которая начинается с 0x380420) вываливается с ошибкой... Длина указана даже чуть меньше чем за вычетом тез 28байт. Тоесть все вместе меньше чем 1к*16. Более того, оно же ещё и позволяет перезапитывать, по идее не должно, так как OTP одноразовое. Потом я попробовал вообще все в оду секцию впихнуть, не зашило. Ну и теперь, я уже сомниваюсь - а пишет ли вообще CCS5.4 в ОТП, может этото из за того что фришная версия отладчика? Но думается это я уже начинаю фантазировать, короче не могу понять почему не программируется ОТП-шная секция...
  3. А я ж чуть више писал, вот так (ну только можно еще через -o явно задать имя bla-bla.bin) d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>hex2000.exe -boot -b -can8 -pllcr=10 -divsel=2 ../Debug/28335_Boot1 st_OTP2CANRAM__git.out Translating to Binary format... "../Debug/28335_Boot1st_OTP2CANRAM__git.out" ==> .InitBoot (BOOT LOAD) "../Debug/28335_Boot1st_OTP2CANRAM__git.out" ==> .text (BOOT LOAD) "../Debug/28335_Boot1st_OTP2CANRAM__git.out" ==> .cinit (BOOT LOAD) "../Debug/28335_Boot1st_OTP2CANRAM__git.out" ==> ramfuncs (BOOT LOAD) Сегодня изучал формат бин-файла - один в один как расписано в протоколе для бутлоатера от тексаса. сделал распечатку и побайтно все проверил - Оно! ;) (там в конце исходникоа есть коментарий с стримом начинается с 0xAA08 .... ) Но еще не проверял это залить...
  4. hex2array - это для С6000, я сегодня попытался её завести, но что-то как-то оно криво работает, не стал время тратить, файл открывает, но не читает... Но больше всего я решил потратить время на разбирательство что ж такого из себя представляет бинарик который на выходе hex2000.exe. И судя по тому что я понял, это правильный бинарик, тупо бин всего стрима для программы, без всяких заполнений лишних... По крайней мере, результат совпадает с несколькими hex2bin конверторами.. Далее, я начал исследовать что внутрях бинарика, и вот каково же было моё удивление, что оказуется, тот пример, что предоставляет Тексас для бутлоадера, как раз и есть самый простой парсер этого бинарика... Тоесть они его сразу разворачивают в память из потока. и потом тупо возвращаяет указатель на точку старта который в бинарике идет после 18го байта. Короче, то что я мучался когда писал свой загрузчик первого уровня, все коту под хвост, ибо одно и тоже, только у меня перемудренне и с развернутой инициализацией..., а у тексаса все намного проще. А вот второго уровня не зря писал. И вот по нему у меня остались вопросы. Я чтото запутался вкрай. Программа допустим размером в 4 флэшовых секции, так вот нужно в DSPFlash начинать писать с секции A или к примеру с секцции D? Если писать с D то получается красивое нарастание адреса пока не дойдет до конца секции А, точнее до секюр-зоны. Если напичнать писать с секции А (ну логично же что А это первая, с неё то и надо начинать, как бы...) то получается идиотизм с постоянным перепрыгиванием (буквой Z по карте адресов) с конца предыдущей секции на начало другой, меняя при этом намерено адреса и анализируя какой хвост дописывать в новую секцию... мрак какойто... Так вот как правильно писать? Я еще не успел с этим разобраться. Но чтото похоже что правильно так как легче, с секции H->G->F->....->B->A. Уточните плиз, бо крыша уже едет. И главное, ни где про это не нашел описания... Да, с этим разобрался... Кстати, в том бинарике что герерирует hex2000.exe точка входа где находится _c_int00, если сравнить с map файлом, то это она и будет, перепроверил на нескольких файлах... Что все таки намекает на то что генерит то что нужно ;)
  5. На этот вопрос похоже нашел решение Сделал make_bin.bat. Но не знаю правильно ли - нет возможности проверить результат в реале на железе... rem C:\ti\hex2000.exe -boot -i -spi8 -spibrr=6 -pllcr=9 C:\ti\myprojects_v4\qwerty\RAM\qwerty.out echo " ====== MAKE BINARY FORMAT ==> *.bin ======" hex2000.exe -boot -b -can8 -pllcr=10 -divsel=2 ../Debug/28335_Boot1st_OTP2CANRAM__git.out Выдало: d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>make_bin.bat d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>echo " ====== MAKE BINARY FORMAT ==> *.bin ======" " ====== MAKE BINARY FORMAT ==> *.bin ======" d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>hex2000.exe -boot -b -can8 -pllcr=10 -divsel=2 ../Debug/28335_Boot1 st_OTP2CANRAM__git.out Translating to Binary format... "../Debug/28335_Boot1st_OTP2CANRAM__git.out" ==> .InitBoot (BOOT LOAD) "../Debug/28335_Boot1st_OTP2CANRAM__git.out" ==> .text (BOOT LOAD) "../Debug/28335_Boot1st_OTP2CANRAM__git.out" ==> .cinit (BOOT LOAD) "../Debug/28335_Boot1st_OTP2CANRAM__git.out" ==> ramfuncs (BOOT LOAD) d:\work\28335_Boot1st_OTP2CANRAM__git\Operations> Ну и выходной файл с именем 28335_Boot1st_OTP2CANRAM__git.b00, походу нужно просто переименовать в .bin чтоб не было путаниц в будущем
  6. Дошел до этапа, когда судя по всему, данные с первого уровня правильно копируются в RAM и от туда, уже "планируемым" загрузчиком второго уровня, потом копируются в DSP FLASH. Но я вот чего еще не могу понять, запутался окончательно... По какому адресу нужно по завершению записи в флэш прыгнуть так, чтоб потом программа в флеше с него нормально стартанула? тоесть, именно тот бинарный поток, что еще секунду назад летел по CAN-интерфейсу... Вот мой кусочек кода if( SectStartAdr<0x338000/*0x338000-0x33FF7F*/) g_Write_Stage=WR_SECTOR_B; else if( SectStartAdr<0x330000/*0x330000-0x337FFF*/) g_Write_Stage=WR_SECTOR_C; else if( SectStartAdr<0x32FFFF/*0x328000-0x32FFFF*/) g_Write_Stage=WR_SECTOR_D; else if( SectStartAdr<0x31FFFF/*0x320000-0x327FFF*/) g_Write_Stage=WR_SECTOR_E; else if( SectStartAdr<0x317FFF/*0x318000-0x31FFFF*/) g_Write_Stage=WR_SECTOR_F; else if( SectStartAdr<0x30FFFF/*0x310000-0x317FFF*/) g_Write_Stage=WR_SECTOR_G; else if( SectStartAdr<0x307FFF/*0x308000-0x30FFFF*/) g_Write_Stage=WR_FINISH; if ( WR_FINISH != g_Write_Stage ) { if ( u16_ErrCode==STATUS_SUCCESS ) { // `Size` bytes write to Flash if ( Size < 4*1024 ) { u32_FlashWrSize = Size;//u32_FS; u16_ErrCode = Flash_Program ( (Uint16*)SectStartAdr, (Uint16*)DataIn, u32_FlashWrSize, &FlashStatus ); } if ( u16_ErrCode==STATUS_SUCCESS ) { g_Write_Stage = WR_FINISH; } else { return u16_ErrCode; //STATUS_FAIL_PROGRAM; } } } Так вот, как я понял: Флэш секция-А начинается с 0x338000, а почему то я встречаю часто что бут делают с 0x3F7FF6 Вот, даже в исходниках от TI //--------------------------------------------------------------------------- // Fixed boot entry points: #define FLASH_ENTRY_POINT 0x3F7FF6 #define OTP_ENTRY_POINT 0x3D7800 //#define RAM_ENTRY_POINT 0x000000 #define RAM_ENTRY_POINT 0x00F000 #define PASSWORD_LOCATION 0x3F7FF8 Возможно это и правильно, но чтото я заблудился... кстати у вас doom13 тоже самое в коде __inline void GotoStartFLASH() { asm(" LB 0x3F7FF6"); } http://www.ti.com/lit/an/spra958l/spra958l.pdf тоже об этом говорят на стр:32 только сказано что для моего проца это должен быть адрес 0x3F7FFE так как у меня TMS320F28335. 0x3F7FFE это Jump-to-Flash, НО! У меня то OTP бут-пины буду всегда...(как и когда с него прыгать в влэш, это уже другой вопрос) И ведь, 0x3F7FFE это судя по карте, это зарезервированное и неиспользуемое адресное пространство. Так почему бы не прыгать сразу в начало флэша 0x338000 ? я для проверки сделал бут в 0x338000 и мои тестовые данные там лежат, но это лишь подтверждение что записано правильно, а вот будет ли загрузка таким обпазом работать, не знаю. У меня пока нет возможности загрузить реальные данные для реального теста, лишь могу мелкими кусочками даные симмулировать данные которые приходят по CAN... Так что мне нужно максимально правильно все реализовать до этапа финального бута с флэша, к моменту когда будет железо, а это через 2 дня... Ну и второй вопрос: На сколько я понимаю, для того чтоб мне слали то что я должен буду своим бутлоадером обновить, то это должен быть бинарик в формате *.bin. Который я должн буду предоставить, чтоб мне его отправили по CAN. Как в хекс знаю, но это ж не то... Так вот, а как правильно его с *.out сконвертировать в *.bin?
  7. предложение про флаг не понял (точнее то что понял не подходит, у меня же в флеш ни чего не пишется в промежутке) что вы имеете ввиду?
  8. да, в моём случае конкретное задание, заюзав OTP, а дальше не принципиально. От варинта хранения части в флеше я намернно отказался, так как это менее надёжно. Угу, выходит что можно указать любой ID. да, подходит. в 1м просто реализую ожидание, и если не будет скажем 5сек стрима, то джамп по адресам флэша, классический подход. ))) А уж коль первый принят по CAN вероятно второй обязан также прилететь и быть принятым. собственно такой логикой руководствуюсь.
  9. doom13, Ваш код пригодился, спасибо! Высмотрел там самую главную константу, которая разрешила одну мою проблему, долго не мог понять почему у меня работатет на передачу а на прием не работает... Думал что посылая в ext. режиме ID=1 это равносильно что и в стандартном (не знал просто что они не совместимы). тоесть в ext это на на самом деле 0x80000001 вместо 0x01. Так что ваш код помог. :) Но вот у меня какой вопрос появился, я уже сделал драфт версию загрузчика 1го уровня и 2го, но еще не прошивал в OTP, на днях планирую... Меня вот что сильно беспокоит, я не нашел явного ответа в документации от TI, у них сказано что должен быть CAN ID=0x01 но не сказано, а обязательно ли? Ведь на сколько я понимаю режим работы CAN задается инициализацией, а там то можно любой адрес поставить, ровно как и кол-во байт в мессаджах (кстати в ихнем примере =2 байта). Так вот могу ли я задать в OTPшной части произвольный адрес, и будет ли оно с ним работать? Это щас главная делема. Так как например главная проблема что у меня не работает CAN-USB который может корректно работать с CAN полноценно. А тот что есть он умеет только в ext режиме, а это ведь адресс 0x80000001 вместо 0x01. Я решил сделать классически, уже написал драфт версии... Тоесть: 1й загрузчик просто принимает 2й и ложит его в память, а потом делается на него джамп, а вот 2й уже занимается приемом флэшовой прошивки и записью стрима в флэш. Таким образом остается путь для маневра с точки зрения модификации 2го уровня...
  10. Многие чипы имеют свой айди, нужно внимательно их документации смотреть, а некоторые не парятся, особенно китайцы.
  11. ...поразглядывал внимательно даташиты, вроде самому сделать не сложно. Хотя и всё равно не откажусь от готовой ;) Но вот такой вопрос мучает - не нашел ответа ни в одном даташите на вот такой вопрос - первый пин на стороне TOP или BOTTOM ?
  12. Когдато я ломал голову как под BF532/533 сделать защиту, единственный вменяемый вариант к которому я пришел - это привязка к ID чипам: проца+памяти+... То есть, перед прошивкой, запускается сервисная прога - которая выдает результирующее ID и его потом останется прошить в прошивку, причем не просто прошить, а на самом деле размазать по коду, чтоб по факту было десятки мест. Программисту нужно будет только позаботиться как принятое результирующее ID удобно вставлять в исходник переб пересборкой. ну это в принципе пустяковый вопрос.
  13. Сегодня я смержил вот ту самую что дает TI - f280x_otp2can_boot_rom (переделанную под мой 28335) + Flash_API и в 2 кБ, чтоб оно влезло в M0,M1 SARAM. Но толку всё равно мало, потому что OTP имеет размер 1к... бесперспективный путь. Не знаю, даст ли мне еще это какую-то пользу. Единственный способ без него это както разместить часть кода в флэщ, а для этого нужно... опять-25... ;) Вот на счет загрузчика второго уровня я уже сегодня тоже думал, видимо без него ни как... видимо прийдется както из серии: - принять 2й загрузчик и поместить в память (он уже должен уметь флеш писать) - пригнуть на него - начать запрос данных прошивки - записывать частями (сегодня интересный эксперемент провел) Об эксперементе: Спеерва в чем проблема - в том что на самом деле не все 32кБ ОЗУ доступны, у L0 кусочек откушен под какотой треш(забыл точно под что), короче ложка дегтя в бочке мёда. А секции в флэш 32кБ. Итак получается что мы не можем по кану принять полную секцию чтоб её всю зажеч. По этому я проверил писать кусками. Оказуется что если сделать ерейз секции, и потом можно порциями например по 1кБ дописывать всю секцию, главное чтоб не пересекались адреса (ну это в принципе очевидно). А это как минимум дает зеленый свет в сторону загрузчика 2го уровня который принимает по КАНу в апмять и оттуда зажигает флэш. Да. я выше уде написал что это сегодня уже проверил, можно по частям. Просто до этого я натыкался что нужно полную секцию писать гдето в документации, или просто не так понял... Про смену конфигурационых пинов это пока подозрения, потому что я пока не знаю как может быть в реале, может в момент оператор вручную долен чтото переставлять сингронно согласовывая действия с удаленной стороной, а может все должно быть автоматизировано, ХЗ, просто я смотрю на это как будто должно быть автоматизировано. Но не знаю точно. Одно точно - чтоб сменить режим загрузки пины буда должны быть изменены. То есть, на текущий момент у меня только частицы этой мазайки. Складывается все целиком только если написать загрузчик 2го уровня. О, мне тоже интересно будет поразбираться с вашим результирующем кодом. Завтра покапаюсь в нем. В случае чего то под 28335 переделать и подправить под себя, не так уж сложно ))
  14. 1) - не получится судя по всему, и вот по чему, я попробовал на днях склеить версию от TI с библиотекой для Flash (2.10), так вот размер получился около 1,5кб, а у OTP лимит в 1кб. Хакать библиотеку и срезать жирок не видится пока перспективным, как минимум на работе скажут - (не проверена = не гарантирует, или есть риск) 2) бить флеш тоже не вариант - размер прошивки которую буду принимать по КАНу больше чем размер ОЗУ, и по этому как минимум целиком принять и (при дельшейшем переключением в режим гдеб можно было записать в флэш) записать в флэш тоже не получится видимо. Щас думаю как можно принять кусочек, каким-то образом сменить бут-пины, бутнуться с поддержкой флэша, записать, потом снова бутнуться в ОТП, принять следущий N+1 кусок и нова перебутнуться.... и так пока все куски не прийму. Но не смотря на такую корявость реализации тут видятся куда больше проблем - во первых нужно в ОЗУ держать по определенным адресам счетчики принятых частей и тд. (допустим даже это реализуемо). То вот другая проблема состоит в том чтоб бутнуться в ту часть где будет писалка в флэш.... пока не вижу как. Так как я не видел возможности бутаться по адресам который захочется моей левой пятке. Буду рад подсказке, перерыл пол дня в пятницу инет, мож не там искал... конечно, делаю, отписался выше, просто это делаю на работе, а у нас запрещено писать с работы, так что не всегда получается отписаться вовремя. разумеется проект комерческий так что есть свои требования и ограничения как со стороны ТЗ также и с ограничания чипа, ну и отсутсвия опыта по бутлоадерам тоже ))
  15. Коллеги, не могу найти в списке стандартных библиотек в Альтиуме библиотеку для DDR3 (лежачая), на сколько я понял мне нужна 204 пиновая. Если есть она там в списке - подскажите плиз, более конкретно. на примере вот такой - http://attend.manufacturer.globalsources.c...DR-3-Socket.htm Ну или же если есть у вас уже готовая - поделитесь плиз. Заранее Спасибо ;)
  16. А если еще вспомнить что они недавно выпустили Tiva где ARM Cortex-M4 и плюшки от DSP с огромным колвом PWM и все это за 3-4 бакса. то уже даже на этом месте они под себя неплохо рынок подмяли в направлении всего что связано с повер-конверторами и моторами...
  17. Отзывы просты. мне их несколько раз подчеркивали. Устройство, рядом с которым коммутируют немалые токи, и сама система от 20 до 50А, и импульсные до 200А, наводит наводки на все коммуникационные переферии, и более того несмотря на всё негативное влияние таки есть. Ну даже не это важно, а важно то что эти доп проверки от меня тоже требуют чтоб они обязательно были реализаванны, и даже в случае, если вдруг их не будет - хуже не станет. :) да, это как запасной вариант с запросом, а точнее скорее всего мной будет реализовано чуть позже, изначально была мысль без запроса просто реагировать на стрим, и запрос только при обнаружении сбоя. Почему так, просто для OTP выделено очень мало памяти, всего 1Кбайт, и если туда влезет реализация с запросами и остальным то так и быть. Сегодня проверил - Flash_Erase() в дебаг режиме более 3сек ...долго. А вот Flash_Program() вроде быстро, но не удалось заметить на сколько быстро. гдето 100...200мсек максимум., а может и быстрее. Вот по этому я и хочу найти найти инфу с какой же скоростью API Flash пишет. Думал что раз флэш работает на частоте 30..40МГц в чтении, то хотя бы на 5..10МГц в записи, но это от фонаря прикидки.
  18. Да, я знаю что CAN имеет свой механизм проверки целостности пакета, но это тем не менее особо не помагает, судя по отзывам он часто сбоит при больших ЭМ шумах, так что помехи видимо настолько большие... собственно исходя их тех отзывов мне кажется имеет смысл сделать собственный логический уровень реакции на определенные ошибки, от сюда и такие суждения. Что же касается примеров под другие процики, то имелось ввиду именно под этот проц. как я писал уже выше есть определнная специфика именно этого проца, и именно главная это OTP и выбор бутовых пинов(или както иначе, не нашел еще как), так что не вижу смысла тратить смысла на разбор полётов под другие, тем более что я несколько лет назад уже интересовался так что имею предсавления что там. Что касается бутовых пинов я пока вижу только один путь - сделать обратную связи на эти пины через шифт-регистр, и свозможностью явно задать перед ресетом... но пока такое не эксперементировал ещё. Таким обрахом можно будет менять состояние бутовых пинов. Но чтото мне кажется в этом подходе есть странность и нелогичность. А вот какое время? я не нашел ответа в документации, мне нужно также знать с какой скоростью он по факту пишет.... И мне тоже кажется что лучше делать с ответом, особенно с учетом того, что на время записи нужно отключать прерывания..
  19. TMS320F28335 CAN Bootloader Ранее не было опыта с самописными бутлоадерами(только ознакамливался), поэтому щас столкнувшить с этой задачей и читая даташиты по bootloader-у появились вопросы на которые на данный момент времени не нашел явного ответа. Так что, хочу с вами на эту тему пообщаться, уверен что-то новенькое сможете посоветовать. Итак, Цель: Загрузить прошивку для TMS320F28335 через CAN и сохранить в Flash с дальнейшем прыжком туда. Вот тут, есть описание от Тексаса используя OTP, но оно больше для пояснения. http://www.ti.com/mcu/docs/litabsmultiplef...mp;familyId=916 http://www.ti.com/lit/an/spraaq3/spraaq3.pdf http://www-s.ti.com/sc/techlit/spraaq3.zip (пример использования OTP для SPI, CAN) Документ простой, всего в несколько страниц, и в этом кстати есть некоторая проблема, потому что указаны только основные положения. Как и пологается, на практике всё требуется чуть сложнее или вообще иначе. Для начала, там описано только как принятый поток загрузить в ОЗУ, и на этом всё, а этого явно не достаточно. Как мне видится возможным решить это: 1) Загрузить прошивку используя CAN MSGID1(можно ли другой?) - По частям? С задержками в потоке или без? - Целиком? (ну тогда всё в память не влезет) - Выходит, что лучше сразу писать принятую часть потока в Flash... 2) Для того, что бы сохранить чтото в Flash, нужно подключать уже готовую и специфическую библиотеку с уже реализованными API Flash (http://www.ti.com/tool/sprc539#), последняя версия на данный момент версия 2.10. - Какая скорость записи, нужно понять будет ли ДСП успевать качать данный с CAN потока при условии что спец задержек нету) и одновремено записывать? У интерфейса CAN скорость максимум 2 МБита\сек, в теории должно успевать записываться приянятых несколько байт с потока, а вот на деле? 3) Ну и теперь вопрос - как правильно сделать загрузку? Поправьте меня плиз, если где-то не в ту сторону думаю. На сколько я понимаю то, что я опишу, это весьма традиционный подход, но всё же хочу у уточнить... 1) - Работает программа и слушает указание на готовность принимать новые данные. 2) - Принять первый пакет, и тут же послать команду ожидания перед посылкой следующего пакета, за это время выключить устройство или перевести в режим ожидания и быть готовым принять весь поток с новой прошивкой. 3) - Нужно ли тут сразу переходить в OTP и делать дальнейшее в нем? Более того для переходя в любой другой режим загрузки, нужно перед ресетом предварительно установить на boot-пинах другую конфигурацию состояния пинов. ? - Как в этом случае люди поступают, внешняя логика или можно какими-то уже заложенными средствами? (я их пока не нашел в описании) 4) - Далее, уже основной поток (это как раз описано в документе для OTP что писал линк выше), согласно документации выше, в начале должен идти адрес точки входа в прошивку (его-то и нужно извлечь и потом на него перепрыгнуть), отдельно сохранить в память (мало ли). 5) - Прием слудующего(-их) пакета(-ов). Проверить, не последний ли это пакет в потоке, с обязательной проверкой контрольной суммы (мало-ли, шумы могут исказить). 6) - Если обраружен сбой - goto 11) 7) - Принятый пакет сохранить в Флэш. 8) - Ожидать следующий пакет или же сделать явный запрос. 9) - goto 5) 10)- По признаку конца потока, посчитать контрольную сумму на целостность прошивки, если все ОК, то перейти по адресу точки входа (пункт 4). 11)- Послать запрос на повторную посылку предудущей команды, и так например повторить 5 раз(или до упора). Выход с сохранением статуса аварийсного сбоя или попытаться запросить снова, через например 10 минут. Если сбой, записать статус и сообщить по CAN об аварийной остановке, так называемый в РЖД-шных устройствах "защитный отказ". В общем после ознакомления выяснил что вопрос TMS320F28335 CAN Bootloader не растрыт толком со стороны Тексаса, но и то что они предоставляют тоже явно помогает. В общем нужна ваша помошь. Кстати, готовых примеров с бутлоадером я тоже не нашел покаместь в инете. Заранее спасибо за все советы.
  20. Ох, тема старая, но всеж таки, что бы расставить точки над "i" справедливости ради. Не вводите в заблуждение. Для MTTP метод отличается от "последовательных приближений", самый простой это P&O(Perturb and Observe) или чуть сложнее но лучше INCCOND. Есть также варииации улучшения каждого из них.
  21. Не ARM конечно, но возможно это вам больше подойдет, выбирайте на вкус http://www.analog.com/ru/processors-dsp/bl...x.html#blackfin Но единственное что - на борту нет АЦП, а так все остальное из переферии есть (только не у каждого чипа) Например bf609 - http://www.analog.com/en/processors-dsp/bl...ts/product.html А вот тут есть АЦП - http://www.analog.com/en/processors-dsp/bl...ts/product.html но нет памяти :) В общем выбирайте... ;) Главный плюс - шустрая числодробилка и дешево.
  22. я использую Git независимо от аврстудии через консоль или же через GitExtensions
  23. Да, да, знаю - эта тема уже давно гремучий баян(2005г) и подняда с анала истории, но вот только щас наткнулся... )) Дима, сегодня разбирал твой AVR код от NikeE и напоролся на __x_z - раньше ни когда не встречал, это было как выстрел в лоб ;) я так и не нашел твою статью на какойто там "Точка опоры", даже сайта не нашел. А так хотелось... Хочу уточнить(это вопрос) - На сколько я понял из всего тут написанного то если в АВРке не использовать этот самый __x_z(и ему подобные модификаторы) то просто будет менее оптимальный код и соответсвенно медленее исполняться. Я всё верно понял?
  24. Во, вот это уще несколько ближе. На стр 115 нашел график степени диградации от кол-ва часов наработки, и как это влияет на смещение напряжения в MOS FET - "Figure 4.15 Supply Voltage (Drain Voltage) Dependency of Degradation"
  25. Я не буду настаивать на истенности именно моей трактовки терминологии, как я уже выше писал, ранее мне с этим не приходилось тесно сталкиваться, а по сему допускаю что где-то неверно выражаюсь, но с мысл думаю вы поняли. А смысл в том, что, если к примеру есть значение наработки на отказ, то это не то что я ищу. Мне нужно знать например как измениться емкость затвора, время открывания-закрывания, падение напряжения коллектор-эммитер и т д через к примеру 5 или 10 лет, то есть те самые величины которые можно просимулировать или попытаться воспроизвести на реальном устройстве. При этом устройство должно быть также рабочим, но лишь с ушудшенными/улучшенными параметрами в целом. А так как это инвертор то это все прямолинейно отразится на эффективности. Да, я прекрасно понимаю что это очень редкие данные, однако надеюсь что кто-то их встречал в силу опытности и большого кол-ва просмотренного материала.