Добре дошли в abs!

Цветарство по програмистски, v. 2.0

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

Самото цвете бе обект на непрекъснат тормоз (както се вижда), но не само от мен, а и от майка ми, която де що види, че гадинката малко от малко е пуснала листенце/филизче над 20 сантиметра височина от дъното на саксията, го минаваше набързо с ножицата. Така де, бунтовете трябва да се потушават в зародиш.
Това лято, обаче, оставих цветето да си расте без ограничения, то се разлисти, разхубави, набъбна, с една дума - красавица :)
Респективно, за Нещото тази година щеше да е необходим значително по-голям кашон. Сменях и квартири, а в новата нямаше къде да закача кранчето.

Последва реализация на една друга идея: да държим цветето на тъмно, и да му светим по 10 часа на денонощие.

1. Първо изследвах как е най-подходящо да се осветява фотосинтезираща гад. НАСА са правили подробни изследвания за това (примерно), като тяхната идея да ползват LED-ове е основно откъм ефективност и ресурси. LED-овете не греят, респективно растението не изпарява много вода така, отдено са с високо КПД.
В този патент пък хората са изследвали, и препоръчват да се ползват червени, оранжеви и сини диоди, в отношение 12:6:1.

2. Накупих си голямо количесто ultra-bright LED-ове. Сметката колко диода ми трябват се оказа учудващо тежка и е удоволствие да си изпържиш мозъка със всичките фотометрични единици: лумени, луксове, кандели, ватове на стерадиан. В крайна сметка на платката разположих 17 червени, 8 жълти и два сини. Целта беше да докарам около 2000 лукса пиково осветление, което се получи (за фотоизмервател ползвах dSLR :D)

3. Задължителният breadboard, по време на прототипирането:
.

4. И вече прехвърлено върху реална платка:


5. От различни графики с измерена яркост на слънцето по денонощие се ориентирах, че светлината по време на изгрев се увеличава над 1000 пъти (по-скоро към 10000). Чрез ШИМ докарах гладко "изгряване" на светилото ми (вижте клипчето долу). В крайна сметка, докарвам контраст 1000:1, като началото на изгрева е малко бъгаво. Освен това, жълтите диоди ги паля 20 минути след червените, сините - час по-късно, уж там да се симулира различния цвят на слънцето по изгрев/залез.

6. Канибализирах една стара лампа:


малко болтчета и пластинки от Meccano:


И така имаме тестов блинк върху моята странна "лампа"
.

7. Отчитането на времето се прави с един часовникарски чип - DS1302 - и кварцов резонатор. Времената на изгрев и залез са коректни за цялата година, и отговарят на истинските изгрев/залез в Сан Антонио, Тексас (ето един целогодишен калкулатор). Тъй като PIC-а малко трудно се оправя с floating point, синуси, косинуси и т.н., времената просто съм ги забил в статичен масив, в делта-компресиран вид.
DS1302 поддържа времето даже и след изгасване на тока, като поддържането на CMOS-а в тея случаи принципно се прави с батерия, но аз избрах просто да ръгна един голям електролитен кондензатор, който DS1302-то да пълни при наличие на ток:


Учудващо, оказва се, че с 4700µF държи точно време повече от денонощие.

8. Сложих коледната звезда на относително тъмничко място, "лампата" на 30 сантиметра отгоре й (за да имаме достатъчно разпръскване на снопа светлина - тези диоди са доста тесен лъч). Ръгаме в контакта и си имаме целодневно зарево в стаята :)

.
.

Ето го и на клипче: Youtube.

Цялото нещо харчи около ват. Диодите не греят въобще (тествано с пръстомер).

Това вече върви около месец и половина. Коледната звезда все още не почервенява.
Ако растенията можеха да се самоубиват, това отдавна да си е направило харакири :)

Някои неща, които научих:

• Цял embedded проект на C. За този проект не написах нито ред асемблер, всичко на C, ползвайки Hi-tech компилатора. Вече не мога да кажа за какво е отишъл всеки отделен байт от паметта, но след като паметта стига - проблем няма¹.
• Комуникация с външен хардуер, в случая DS1302-ката. Може да се каже, че за пръв път съм написал собствен драйвер. Нищо особено, но доста неща, свързани с комуникацията между чипове, ми се изясниха.
• Всичко, свързано с осветлението: луксове, лумени, кандели и имат ли те почва у нас.
• Постоянна памет (EEPROM) в такива проекти. Благодарение на нея реализирах 0-бутонен потребителски интерфейс. Исках уредът да има два режима - стандартен и тестов, като в последния да мига със всичките диоди, малко като коледни лампички. Това, обаче, би изисквало или DIP switch, или някакъв бутон на платката. Е, има и по-хитър начин да предадем нашето желание на уреда, боравейки с ключа On/Off:

1. Уредът се включва (On)
2. Веднага се изключва обратно (Off)
3. Включва се наново. Ако времето между 1) и 2) е под секунда, влизаме в тестов режим, иначе - в нормален. Тук ни върши работа постоянната памет. Първата работа на софтуера, при пускане, е да вдигне един флаг (в EEPROM-а), а секунда по-късно (ако все още не са ни изключили), флагът се сваля обратно. При следващото пускане можем да видим какво е състоянието на флага, и така да определим в кой режим да работим.

• Компилаторът е там, за да се ползва. Преди бях голям фен на пълненето на сорс-файловете със симпатични масивчета от магически числа, хитроумно пресметнати отвънка с някакво скриптче. Hardcoding на макс. Постепенно се преориентирах към вкарване на повече от работата вътре в C/C++ кода, когато е възможно, тъй като компилаторът все пак може да сметне доста неща сам. И вместо магически числа - код, макроси или подобни, които стигат до същите магически числа. Например: DS1302-ката се нуждае от ток, за да си помни датата и часа. При първоначално пускане, или след преместване между платките, тя е "неинициализирана" и си мисли, че е първи Януари, 2000г. Е, бих могъл просто да си направя отделен билд за тези случаи, и да въведа в C кода текущата дата и час, и след като ги налея веднъж в DS1302, да си продължа, разчитайки на нея. Е, вместо хардкоднати дата/час, тези неща могат да се вземат от "променливите" __DATE__ и __TIME__, които компилаторът любезно ни предоставя.
• MPLabX под Linux. Не е най-великото IDE на земята, но върши работа.

---
¹ Това мислене, разбира се, е много, много, *много* грешно. Като нищо утре ще пропиша на C#

Публикувано в категория Hardware -- Jan 30 03:53, 1 коментар -- View in English

Познай рендера

Покрай курса по 3Д графика, изпитвам рядкото щастие/проклятие да пиша цял проект наново от нулата. Познато ли ви е? Много програмисти, в даден момент от живота си, са искали да зарежат бозата, с която се мъчат в момента, и да пренапишат начисто цялото проклето нещо, този път "както трябва". Някои даже го и правят. Макар че, според признатите гурута на софтуерния мениджмънт, това е най-голямата стратегическа грешка, която можеш да направиш в един голям проект.

Е, за малки проекти със сигурност не е така, и този път учебния рейтрейсър се получи осезаемо по-добре. Днеска рекох даже да сверя резултатите от глобално осветление с path tracing спрямо V-Ray. Сцената е взета от SmallPT.




Едното е с V-Ray, другото е с учебния рейтрейсър. Можете ли да познаете кое кое е?

Покрай smallpt попаднах и на нещо интересно, което ме накара да се замисля, колко яка сфера е графичното програмиране.

Да речем, пишеш файлови системи, и си бъгнал нещо. Системата замира с kernel panic, следва reset и се надяваш да си оправиш данните, да не се налага пълен реформат на тестовия дял. А, и все още имаш да фиксваш бъг.

Или, пишеш web софтуер, и си бъгнал нещо. 3 месеца по-късно успяват да намерят експлойт заради бъга ти, сайтът ти е станал розов и мигащ, затрити са десетки часове въведени данни, за които няма бекъп. А, и все още имаш да фиксваш бъг.

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



Яко, а? И даже можеш да го публикуваш така. Както си е с бъговете.

Какво друго: тия дни довършвам AGG 0.3.0, надявам се до месец да пусна нова версия. След това подхващам ucbench, на който планирам да вкарам OpenCL поддръжка (и явно ще има доста пипане по сайта).

Публикувано в категория Програмиране -- Jan 7 02:20, 0 коментара -- View in English

AGG и GPL

Както се оказа, на нечия умна глава й дошла идеята да си присвои кода на AGG-то, да му турне copy-protection код и да го продава по $30 парчето. GPL е за загубеняците, които си нямат друга работа. Дами и господа, представям ви: SoftOrbits's Html Web Gallery Creator.

За пример: Галерийка с моята програма, и с "техния" продукт.

Фирмата е изключително потайна, не пише никакви контакти и детайли къде се помещават и оперират. С помощта на един добър човек вече пратих Cease and Desist писмо на руснака, сега чакаме развитие.

Публикувано в категория Open source -- Jan 7 01:05, 0 коментара -- View in English

C

Или, както беше казала една умна глава преди доста години: Assembly language programming is an extravagant waste of human talent and should be avoided whenever possible.

Докато по-миналата седмица се занимавах с SimNow, ucbench и програмиране на асемблер за x86, този уикенд (донякъде като трибют към наскоро починалия майстор - R.I.P., Денис Ричи :\) минах на език от по-високо ниво за архитектура от по-ниско: а именно, C за PIC. Горноспоменатия цитат на Питър Нортън¹ е просто тоооолкова верен, за съжаление: старият проект на PIC е готов донякъде, но съм го замразил поради намекнатото в мисълта разхищение, което натрапчиво мисля как да избегна. Та, за да тествам Hi-tech C правилно, значи нов проект (с по-лесен замисъл), код наново от нулата, нов бредборд и даже малко нов хардуер. Ето видео с първата тестова програмка, която натворих:


Цък (h.264 формат - работи с VLC).

Дали за "големия" проект ще стане с C (тъй като сега дори малката програмка заема 10% от паметта за код и малко над 10% за данни) предстои да видим, но поне има надежда: не знам дали психически щях да устискам да напиша толкова много асемблер :)

Забавен момент докато си купувах хардуера: трябваше ми добър 3.3V регулатор с нисък dropout и след допитване ме насочиха към MCP1703. След купуване на чаркаляците от Комет по някое време обърнах внимание, че май са забравили да ми дадат регулатора в торбичката. После забелязах, че все пак са ми го дали, но просто беше толкова миниатюрно, че да те напуши смях. Аз очаквах нещо такова, а то се оказа такова (виж стрелката)... Иска си RTFM. Трябва да видите как му се запояват крачета на такова нещо - мога занапред да се пробвам да запоя жички на песъчинка, сигурно ще успея след този тренинг...:)


--------
¹ независимо, че хитрата лисица си е написала първите версии на нортън командър без нито ред C :)

Публикувано в категория Програмиране -- Oct 24 03:08, 0 коментара -- View in English

Упътване: AMD SimNow

Бях обещал да напиша упътване за нещото, наречено AMD SimNow™.

SimNow, най-общо, е пълен симулатор на дадено PC, дори несъществуващo такива. Ако по "Компютърни Архитектури" са ви казвали, че процесорите са софтуер (което е вярно), и се тестват (софтуерно) стотици хиляди часове, преди да се появят като реален кристал (което също е вярно), то ето това е една от програмите, които прави тези симулации.
SimNow работи на много ниско ниво, изчислявайки, например, как протича комуникацията с паметта (чиято точна скорост и тайминги също се емулира), какво прескача по хипертранспорта и още много други детайли...
Цената на всичко това е много ниската скорост на емулация - например, с 3200 MHz процесор емулирате уж 2 гигахерцов, но със скорост на емулацията 50-100 MIPS.
Действително, симулацията просто "тече" по-бавно от реално време (противно на DosBox, VMWare и други). Т.е., процесора вътре в емулатора се приема за работещ с фиксирана скорост, и понеже емулирането му с 1:1 скорост е невъзможно, просто времето се "разтяга": вътре в емулатора, "sleep 1s" ще отнеме 10 секунди, ако текущата скорост на емулиране е 200 MIPS. Ако гледате филмче вътре в емулатора, то ще "върви" без "засечки", но много по-бавно. При другите емулатори обикновено е обратно, програмата ще се усети, че процесора е бавен, ще пусне framedrop и т.н.

С горното вероятно ви убедих, че ползването на този емулатор е свързано с мноооого чакане. Затова е добре да се оборудвате с лека и оптимизирана гостуваща OS. Освен това, правенето на виртуален твърд диск не е особено лесно, но затова пък CD .ISO файлове се поддържат много добре и най-лесно е да се насочите към някоя от леките LiveCD linux дистрибуции - аз ползвах Puppy Linux 5.28. Това е една доста добра дистрибуция: не казва нито "гък" за това, че я пускате върху процесор, за който въобще не е чувала, зарежда за приемливо време (десетина минути, нищо работа), но веднъж като зареди, всичко върви прилично. Вероятно ще ви подразни липсата на синхронизация между курсорите в домакинската и гостуващите OS. С настройка на чувствителността на мишката в puppy, общо взето сте готови.
SimNow ви позволява да си "сглобите" каквато машина си пожелаете. Има асортимент от налични хардуерни модули (видеокарти, южни мостове, процесори,...), но навързването им не е лека играчка, за това можете да отворите просто една от готовите конфигурации, които идват с инсталацията. Например, за Bulldozer има само една конфигурация, vp_bd_phase1.bsd.
Има още една пречка, преди да заработи емулацията с вашето Live CD. Boot приоритетите в BIOS указват HDD да са преди CD, и по подразбиране това ще ви доведе до грешка "Invalid (or missing) operating system". За да оправите това, влезте си в BIOS (който... е ... ами, истински) и го оправете. Restart и voilà!

Следва недобре документираният момент, как да вържете вашата виртуална машина с реалния свят. SimNow не поддържа Copy/Paste между гост и домакин, няма споделени папки, така че най-лесният вариант е да си закачите виртуалната машина към LAN. Виртуализирането на мрежата под SimNow е направено гъвкаво, но (поне за начало) - сложно. Откъм госта е лесно - той вижда Е1000 мрежова карта. Откъм домакина, SimNow очаква да се върже към сървърен процес, наречен "медиатор". Него трябва да си го стартирате ръчно. Този медиатор е реалната изходна точка на емулирания трафик към света. Т.е., ако гостът иска да ping-не google.com, пакетът първо се праща през E1000 емулацията, после SimNow тунелира пакета към медиатора (който спокойно може да работи и на друга машина) и после пакетът се появява от сървъра, евентуално NAT-нат, или директно, все едно E1000-ката е бриджната за реалната LAN мрежа. Вариантът с бридж e най-лесен, затова ще опиша него. Преди да пуснете SimNow, пуснете програмката "mediator", с аргументи -p <port> (например: "./mediator -p 8888"). Медиаторът ползва libpcap и затова изисква root привилегии. След което, пуснете вашата симулация, и в командния терминал на SimNow (обикновено, това е конзолата, от която сте извикали ./simnow) трябва да укажете как да се свърже с медиатор-сървъра. За целта напишете "setMediatorHost localhost:8892" (тук числото е <port> + 4). След това следват командите "linkConnect down" и "linkConnect auto", с което E1000-ката ще каже на гост OS-а, че е вързан (в случая, все едно нова карта е закачена към вашия LAN). Така комуникацията е уредена и можете да си работите на машината. Малък момент - неизвестно защо, не можех да пингвам госта от домакина, макар и да можех от друга машина в моя LAN. Демек, за да кача файл в госта, първо го upload-вах на файловия сървър вкъщи, след което си го свалях с wget от госта. За щастие, puppy идва както с wget, така и с unzip :)

След цялото това нещо, сигурно се питате - добре де, защо ни е въобще да правим емулация?
В моя случай, това беше единственият начин да проверя, дали ми работи реализацията на ucbench с XOP инструкции — без да си купувам реално Булдозер. Което, всъщност, и нямаше как да направя, преди датата му на пускане! Конфигурацията vp_bd_phase1.bsd поддържа XOP и FMA4, при това с истинската им скорост: когато подкарах ucbench и тествах как се представя новият код, то резултатите бяха около 50% подобрение - което, както се оказа, отговаря точно на това, което се получи и на реалния Булдозер!

Финални думи: емулатора работи само на 64-битови AMD процесори. Пише си го, като изискване, на сайта. В лагера на Интел, положението е същото, но неофициално: те имат подобен емулатор (който пробвах през м. Март), който също симулира още несъществуващи процесори. Само че, ако се направите на нахални и се опитате да го пуснете на AMD процесор, програмката уж тръгва и след малко гърми със Segmentation Fault. Същата програма, пусната на 14 пъти по-слаб Intel процесор (Atom, vs. Thuban), работи без засечки :D. Да живеят междуфирмените удари под кръста :]

Публикувано в категория Технологии -- Oct 24 02:29, 0 коментара -- View in English

Нещата напоследък...

... защото се случиха няколко яки работи.

Организирахме с фирмата първия семинар по фотореалистична графика в България. Такова събитие не се беше случвало никога, така че не знаехме какво да очакваме и организацията беше яко ad hoc. Мисля, че стана добре, но още не сме разгледали feedback формите (хехе) :)

После, леко надградих ucbench, като добавих поддръжка за XOP инструкции. Те се явяват нещо като допълнителна ортогонализация на SSE, и добавят някои способности от стандартните x86 инструкции, които много отдавна трябваше да са влезли в SSE - векторни целочислени хоризонтални събирания, побайтови пермутации, cmov, и — най-важното в случая — векторен вариант на ROR/ROL инструкциите. Централна част в кода на ucbench е SHA-1 алгоритъма, който, от своя страна, прави цели 3 побитови ротации на рунд, които досега в SSE варианта се "емулираха" чрез SHL, SHR и OR. Адски неефективно, отделно пък заемаха по един временен регистър! С добавянето на VPROTD (което прави векторно ROR или ROL според аргумента), производителността се подобри с цели 45-50%.
Интересен е моментът как се тества такъв код без да имаш необходимия процесор (Булдозерите все още не бяха излезли). Сблъсках се с това нещо, наречено AMD SimNow, което, освен, че е ужасно бавно, е и недобре документирано - смятам да напиша един кратък tutorial тази седмица (аз лично прекопах интернет в търсене на такъв - сега поне може да съм от полза някому :)).

Третото готино нещо е, че отново чета курса "3D графика и трасиране на лъчи" във ФМИ. Пак студенти, търчане за проектори, организационни неща - мазохизъм за ценители :)

Публикувано в категория Open source -- Oct 16 23:13, 0 коментара

По-стари статии >>