Здравейте колеги,

Търся схема на програматор/дебъгер за СС1110/СС1111/СС2510/СС2511 микроконтролери.
Някой от вас попадал ли е на такова нещо из нета ?

Благодаря Ви предварително.

И аз търся някакво такова животно, но единственото което откривам е това:

Ей го!

Вероятно и това да свърши работа, но не може да няма и друго. А трябва да съм убеден, че ще ми свърши работа с IAR за 8051.

search ti.com

Yanek, благодаря ти за линка.

Реших си проблема с дебъгер/програматор-а, но веднага след него следва нов проблем: От къде да се намери работеща нелимитирана версия на "IAR Embedded Workbench for 8051 v. 7.50A" (може и малко по-стара) или на Keil MicroVision за 8051 ?

Сподели малко повече за това как реши проблема с програматор/дебъгера. И ако намериш нещо повечко за развоя Аз до сега ползвах Nordic но започнаха много да вдигат цените и съм малко притеснен - а това ми изглежда добре и ще опитам да поработя с нещо такова.

Относно дебъгера - имах нужда от още един комплект за развой. Доставиха ми го.
Впечатленията от тези чипове са ми много добри. Цената им мисля че е повече от приемлива, а и размера на устройствата може да е много малък, защото това е Процесор+Радио в един чип, като около радиото няма много компоненти (има само БАЛУН към антената). Всичко друго е интегрирано в чипа. Размера на платката с процесора и радиочастта е 1.5х2см. Освен това за разлика от субгигахерцовите трансмитери на Нордик които четох на времето - това радио позолява пакетна обработка на радиофреймовете на хардуерно ниво без участието на процесора. Това включва откриване начало на фрейм, филтриране по мрежаID, филтриране по адрес на получателя, проверка по CRC, корекция на грешноприети битове FEC (Forward Error Corection) и много други глезотии.
Моля разберете ме правилно - не съм рекламно лице на Тексасци, нито на Чипкон. Просто на пазара аз лично не открих по-добро решение от тяхното за субгигахерцовият обхват. Ако някой е попадал на нещо по-добро - нека сподели.

Сега се боря с една 30 дневна версиа на компилатора на IAR и търся нещо кракнато/отключено.
Не се чувствам щастлив с кода който компилатора ми генерира (въпреки пълната опримизация която задавам), но пък - "пълно щастие няма" ...

Обикновено emule и rapidshare-то вършат работа за снябдяване с лекувани среди. Версия 7.40 също ще ти върши работа. SimpliciTI наистина е направен добре и работи стабилно с малък брой крайни устройства. А една от глезотийките, които нямам търпение да пробвам е хардуерния AES, че с тази параноя процесора се изгърбва докато кодира 50 байта.

За да не стане недоразумение: тествам SimpliciTI на платформа с CC2430 и MSP - китчетата на тексасци. AES не съм добавял към техния протокол, а е към моя разработка на по-паметлив контролер с радио на Xemics.

Yanek,
Нямам опит с AES криптирането на СС1110, но от това, което прочетох - минималната дължина на криптиран пакет мисля че беше кратен на 8 байта (по спомени). Протокола който разработвам в момента трябва да поддържа фреймове с променлива дължина, като по възможност да няма DUMMY байтове за допълване до 8 байта (Заради криптировката). Та поради тази причина се отказах от AES хардуерната криптировка, а разработих свой алгоритъм за това.

Можеш ли да ми изпратиш някакви линкове от къде мога да дръпна тези "работещи" компилатори ?
Благодаря ти предварително.

E-mail-a mi e :
emilvtc@hotmail.com

AES кодирането си е обикновено Rijndael кодиране със 128 битов блок (съответно и ключ) в режим CBC (Cipher Block Chaining). Демек кодираш първите 16 байта като преди това си ги XOR-нал с инициализиращия вектор (при АЕS обикновено са нули) след което полученото XOR-ваш с втория блок байтове за кодиране. Полученото отново кодираш и XOR-ваш със следвашия блок и т.н. докато ти свършат блоковете. Ако последния блок излиза по-малко от 16 байта го допълваш с числа равни на липсващия брой байтове. Ако байтовете ти излизат точно без остатък добавяш още един блок с 16 байта 0x10. Разкодирането става по обратен ред. Разкодиране 1-ви блок, XOR на неразкодирания 1-ви с втори, разкодиране втори, XOR неразкодирания втори с 3-ти, разкодиране 3-ти и т.н. Значи цялата хамалогия с изключващото "или" е за да игнорираме страха от кодиране по идентичен начин на съобщение с еднакви байтове.

Другото на пощата

Лошото при криптирането и като цяло защитата на информация е, че всеки прочел-недопрочел две статии в интернет и вече мисли че морето до колене
помисли малко преди да пишеш
и не мъти главите на хората с глупости

+1

Не пиша неща, които не зная и не съм пробвал. Не мисля, че съм писал глупости имам и образование и опит за да съм прочел почти 3 статии в интернет. Не зная какво те смущава, но стоя твърдо зад думите си. Ако кодираш с един ключ (да речем с дължина колкото е размера на блока, както е по подразбиране) съобщение от еднакви байтове да кажем най-малко два пъти по-дълго от размера на блока в режим ECB, то най-малко 2 блока от текста ще бъдат кодирани по един и същи начин. Първи байт от първи блок от кодирания текст ще бъде равен на първи байт от втори блок на кодирания текст, втори байт с втори и така до последния байт от блока. Последния блок от кодирания текст заради допълването ще е различен. А е възможно да има и един блок повече, ако байтовете в първоначалното съобщение са били кратни на размера на блока. И ако това не е така явно грешката е четна Този недостатък е избегнат в CBC режима по гореописания начин.

Сега ми идва наум. В по-горния пост НЕ описвам самото Rijndael кодиране, а неговия режим CBC. Там където се среща думата "кодира" се има предвид Rijndael кодиране, а всички тези XOR и другите действия се отнасят за режима. Да не би заблуждението да идва от там?

Пак ти казвам че си чел, но леко недоразбрал
Не ми се заяжда на дребно, кой колко е учил, затова ще ти обърна внимание на един аспект от твоето изложение, който буди моето недоумение :
1. ...си ги XOR-нал с инициализиращия вектор (при АЕS обикновено са нули) кое е нули - инициализиращият вектор ли
Инициализиращият вектор трябва да е непредсказуем
Да инициализира алгоритъма всеки път различно Ако е НУЛИ(боже прости ми ) при един и същи ключ и при едни и същи данни ще имаш един и същи резултат Даже и данните да са ти различни, при нулев IV и един и същи ключ след краен брой засечени съобщения може да ти се декриптират данните(криптоанализа го оставяме за другия семестър)....
та да се върнем на инициализиращият вектор - непредсказуем разбирай случаен, не нули
за целта или ползваш генератор на случайни числа или правиш псевдослучаен такъв.
и за всяка сесия(радиопредаване от единия абонат към другия)IV-то трябва да е различно:!:
Иде реч с един и същи криптографски ключ, даже едни и същи данни всеки път различно да се криптират когато IV-то е различно:!:

сега съгласен ли си или пак държиш на своето, че си имаш образование, чел си повече от три статии по въпроса и акъл не искаш
Повдигнах въпроса не заради образование, книги, режимите ECB , CBC, CTR, CFB, OFB, GCM - те по всичко изглежда са ти ясни, а за трактовката ти по въпроса за реалното приложение на криптиращ алгоритъм с цел защита на данни

Абсолютно съм съгласен, че генерирането на псевдослучайна поредица за IV повишава сигурността. А, ако ще бъдем параноични следва да сменяме и полинома след определено време. Инициализиращия вектор по подразбиране е нула, ако не го промениш след неопределено дълго време пак трябва да си остане нула. Не бива да бъде непредсказуем, защото съобщението ти ще си остане тайна за всички освен за теб. Като казвам че IV обикновено е нула не казвам, че не бива да се променя. Не съм описвал и реално приложение за защита на данните и това е въпрос на избор. Дали ще е твоя начин или генериране на ключ по определена схема или нещо друго зависи силно от конкретния протокол, устройство, приложение. Ето например ти предлагам следното: IV статичен в режим CBC. На всяка сесия (в смисъла на смислово обособен информационен обмен) се генерира случаен (не псевдослучаен) ключ (от сървър или AP) който се кодира с ключ от предварително зададена таблица (или псевдослучайна поредица) и се изпраща на клиента или крайната точка. Кодирането продължава с новия ключ до приключване на сесията. На всичко отгоре на подслушващия ще му се наложи да разпознае и полинома на случайната поредица генерирана заради ограничението на осемте последователни еднакви бита. Не зная генерирането на IV каква полза ще допринесе в случая. Вероятно ще трябва да избереш и полином от по-висока степен за да няма повторение на IV в рамките на едно съобшение. Не че ще натовари много на фона на Rijndael-a. Според мен дори статично IV в режим CBC е напълно достатъчно, дори и да не сменяш често ключовете.

И да - продължавам да твърдя, че прочетох 3 статии