То май и при Зимбабвиан е нещо такова - някои компоненти са с лимитиран достъп, според правата на приложението. Сигурно и Андролога, и той така. Има резон, да не могат разни случайни програми да ти набират и правят поразии .... и с това идват и проблемите от намалената гъвкавост и спънките.

той браузъра е малко особен, половината ми работи не вървят на него (е, на андроидния браузър май е по-голям процента). отделно е активен само ... докато е на екрана. тва е от "предимството" на ОС-а за да работели стабилно тасковете.

тъй че open_tcp_port -> listen няма да върви (май). признавам, че не съм прочел и страница на тема "програмиране на IPhone". вероятно и работата с UART-a ще си има особености. особено в контекста на 3D бутоните в новата генерация с холо-дисплеи.

не знам какво е толкова маниашкото, че всичко е залитнало по тази мода. за мен е напълно устоим.

Е като всяка мода и тая е неустоима за млади хора, тепърва градящи самочувствие;
събират им пари от несигурността, която всеки изпитва по пътя докато разбере кой е и къде
е (някои така и не го разбират ).

така си е .... голяма простотия - преди време и при мене искаха да мерят нещо с ифона, но освен през микрофона/слушалките не стигнахме до друг интерфейс. така и си остана. в гуглето има разни идеи с обикновен модем на ниска скорост, но е далеч от нормално решение

http://ardrone.parrot.com/parrot-ar-drone/usa/
http://ardrone.parrot.com/parrot-ar-dro ... developers
незнам това дали е сертифицирано от Стиви през вифи-то, но най вероятно е... хвърчилката си създава само вифи мрежа, а ти се закачаш към нея. има развоен пакет, може и да е полза.

Наскоро се сдобих и аз най-накрая с андроид телефон поради простата причнина, че оператора ми вече не предлага обикновенни прости телефони. Та има едно приложение за него, дето го прави на web сървър и през WiFi мрежата човек има достъп до самия телефон. Та това нещо може да се ползва да се хвърлят данни във файл в самия телефон и после като се свърши да се пусне едно приложение, което да прави там с тях каквото ще прави . Ама с Андроида май няма проблеми да се ползва и блутута.

Това пък кога се е появило в дата-шита ?! В старите шитове, които съм чел подробно го няма тоа, нито се спомянава FCTL. Сега виждам, добавено е октомври 2009, ама не съм го отразил досега. ... Бах маа му. Явно трябва да се следи творчеството им по-отблизо....



Може ли малко по-подробмо за това ? Debug Port Unlock ли имаш предвид ? Ако е това, не е според мястото на производство, ами класа на контролера ( DustDevil, Tempest, SandStrom, Fury.... ) ... ?

А, и честита Нова Година на всички

малко офтопик относно Debug Port Unlock...

Все се каня да го пробвам по-сериозно, ама все няма време мамка му та ако някой има смляна информация ще ми спести терзанията

Става въпрос, че горната процедура е свързана със защита... Не съм чел обстойно, но доколкото знам идеята е, че след ресет софтуерът бързо трябва да смени JTAG пиновете на GPIO-та и така да предпази от изчитане на фърмуера....

Убаво, ама аз доколкото познавам моя емулатор е в състояние да спре версии до Ц1 включително *преди* първата инструкция.... Ебем ти и защитата тогава
Сега от Ц3 нагоре имах ядове щото вече ресета държи и ТАП контролера, т.е. емулатора нищо не може да прави с чипа докато е в ресет. И нормално се пуска ресета и се спира като междувременно проца може да изпълни няколко (или повече) инструкции. Пак има шанс според мен да се спре преди да е стигнало до заключването, ама да кажем че имаме добра защита срещу еФтини емулатори. Пък даже и моя може да не се конектне толкова бързо, знам ли... Въпросът е, че в случай че защитата бачка, дали ще бачка и от отключването? В смисъл до Ц1 както казах нямам съмнения, но Ц3-ките под ресет нищо не бачка, даже ID не може да се изчете. Така че леко ме съмнява дали тая Unlock процедурка ще бачка при тях.

Някой да знае нещо по темата ?
Не че имам нужда от защита.... ама поне да знам има ли я и на каква цена


edit: то имало и флаш регистър (BOOTCFG) който забранява перманентно JTAG-a. Трябвало да се четат чаршафите Остана да видим дали отключването бачка за новите ревизии...

Да, това имам предвид. А и за класа си прав. Както те са писали в DS:
"The CLASS field value identifies the internal design from which all mask
sets are generated for all microcontrollers in a particular product line.
The CLASS field value is changed for new product lines, for changes in
fab process (for example, a remap or shrink),..."
На практика това са "различни маски", обаче ако са само маските ОК. Но очевидно е че става въпрос за функционални различия. В такъв случай аз лично бих предпочел да ги обединят в една серия микроконтролери (или под-серия), но да се разглеждат като различни. Защото в противен случай се оставя нас горките потребители да се съобразяваме с всяка една разлика. Както и да е, като съм се хванал на хорото им, няма къде да ходя - трябва да го играя.

Аз ползвам "LM Flash Programmer". Ta в тази програмка, в таб-а "Other Utilities" има точно "Debug Port Unlock", където "естествено" сам трябва да си избереш класа. И в зависимост от класа, процедурата е различна - включва натискането и задържането на reset-а и др.п. не се сещам за всичките. За да видите процедурата, може да действате и с незаключен контролер дори и да е от друг клас - не мисля, че може да му стане нещо, освен да бъде изтрит тотално, защото то точно и това прави. Имайте предвид, че ще се изтрият и non-volatile регистрите, т.е. MAC-a, ако ги ползвате за това де. Освен това доколкото си спомням, понеже ми се беше закучил единия от опитите ми за отключване и се наложи да чета повечко, та някъде из ератите май беше се споменаваше, че процедурата за отключване за единия клас в LM Flash Programer-а била объркана и се казваше нещо от рода: когато ви каже "Натиснете ресет...", не го правете а изключете и включете отново и .... За съжаление не си спомням добре - беше отдавана.

Edit:
За в бъдеще, ще се опитам да отразявам тук, всяка "странност", с която се срещна, стига да не стане много спам. Аз и за това предложих да направим една отделна тема: Stellaris Cortex-M3. Какво мислите по въпроса?

Вий сте мазохисти бре хора! Те се саморазпадат, а вий ще ги изследвате - Учени такива!
Трябва да работите с тях, а не да си губите времето с изследвания и наблюдения!
За това - пийте само Швепс - STM32!
Успешна нова година на всички!

Не съм бе fan , ама какво да правя като не зависи от мен. Понякога друг избира вместо теб
Нали знаеш приказката - да те насядат на пачи яйца

абе ако зависеше от мен само SAM

ама нали работим с мат'риал на клиента

То пък STM32 понеже са едни убави..... И там бъгове да искаш, ама чак такива генерални чудесии май не са надробили де.

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

И Атмел и ST и NXP правят контролери от много години. И бъговете им са преглъщаеми. Ама тия Луминари тоя Стеларис им е дипломната работа :):)

Класовете ясни...

http://www.luminarymicro.com/scratch/classes.html

Добре де, пак относно това...

"Caution – In systems where the microcontroller is frequently powered for less than fiveminutes, power
should be removed fromthemicrocontroller in a controlledmanner to ensure proper operation. Software
should request permission to power down the part using the USDREQ bit in the Flash Control (FCTL)
register and wait to receive an acknowledge from the USDACK bit prior to removing power."

Какво означава това на практика ? Вдигаш бита, чакаш другия да се вдигне също (или да слезе) и тогава гасиш тока, така ли ? Ми ако нямаш контрол кога усера ще слави шалтера - както моя случай ? Какво ще стане ако не се спази тая процедура - също неясно.... И какво значение има колко често се гаси и пуска тока - що пък точно 5 минути е толкова специално време ??? Айде, моля ви се, подксжете нещоо

fan, навремето чух добри отзиви за тях, когато бяха още Луминару, в часност Димитър от щатите беше работил с тях и ги похвали. Ми можеш ли да знаеш колко точно ше засмърди едно лайно, преди да го разровиш... Пък, възможно е и ранните ревизии да са били по-читави от сегашните. Както ще да е, като си се хванал на хорото...

С тези, с които аз работих на времето нямах абсолютно никакви грижи, ама знаеш ли какво значи абсолютно никакви - кръгла нула . Аз тогава (2008 г. и началото на 2009 г.) ползвах lm3s2948 и lm3s2651.

Разбира се, че можеш Има една стара поговорка: колкото повече риташ едно лайно, толкова повече засмърдява

Още през 2008г. споделих впечатленията си от Гуминари, че са пълен кинеф. Сравнявах ги на база новите тогава PIC32, а PIC32 не са кой знае какво, и въпреки това са по-добри от Гуминари-то. От около 2 месеца се занимавам с STM32 ( платформа Primer2, хареса ми кутийката, та затова реших да побъзикам и процесора ), и те не са нещо особено, и като цена и като периферия съвместими с Microchip, като поддръжка ми изглежда зле. Вградения дебъг ( на Primer2 де ) ограничен до 32Кб, взех един външен на Raisonanse, и той ограничен до 32kB, ако искам неограничен беше къде 700 евро. Другия вариант е да си купиш някоя GNU или Eclipse среда ( избор богат ), което хич не ми се нрави, поради Eclipse, третия вариант е да се почне люта битка с някой безплатен tool chain и поне 20% от времето да си го губиш със средата. В крайна сметка отново надделяха предимствата на Microchip в маркетинга, почти безплатния развой и поддръжката Другото в което се заглеждам са DSP-та на TI, има доста хляб в тях. Според мен TI вече осъзнават, че покупката на Гуминари е камък на шията и най-вероятно ще се отърват от тях.