Архив на категория: Софтуер

Принтер/скенер/копир Dell 1815dn и Линукс

Вашият отговор

Наскоро се сдобих с въпросното устройство – принтер, скенер и копир Dell 1815dn. Добра машинка, намираща се на прилична цена от доставчиците на употребявана техника.

За да заработи под Линукс принтера (в моя случай Убунту 12.04), сваляте архив с драйвери от тук. Единственият файл, който ви интересува в този архив, е cdroot/Linux/noarch/at_opt/share/ppd/mfp1815ps.ppd. Трябва да го посочите при добавянето на нов принтер, след като автоматичното търсене на драйвер се окаже неуспешно.

За сканиране по мрежата, решението е тук. Работи без никакви проблеми.

linux boards

Linux GPIO programmer for AVRDUDE

1 отговор

Hello!

Here you’ll find a tutorial and example of how to connect an AVR microcontroller to the GPIO pins of an embedded Linux system and use avrdude with the linuxgpio programmer type to program it.

Embedded Linux systems are small computers running Linux. Usually they will have quite a bit of available GPIO (General purpose input output) pins which you can toggle between 1/0 using /sys/class/gpio interface provided by the Linux kernel. Although small Linux computers are very capable, frequently they work in cooperation with even smaller computers like the 8 bit AVR microcontrollers. That can be quite handy if you need to handle some hard realtime task for example.

Traditionally to upload new firmware to these little helpers you would use a bootloader and connect them to a spare UART for example. This presents a chicken and egg problem of programming the bootloader in the first place. Also you may want to use every bit of flash available on the micro and not spare any for a bootloader, or not have a spare UART and so on. That’s where the linuxgpio programmer described here come into play. You can connect the AVR ISP programming interface to any four spare GPIO pins (usually there are plenty) of your Linux board and program it using avrdude. This can also be of interest to you if you already have an embedded Linux board (like the popular RaspberryPi, OlinuXino and the like) and want to get started programming AVRs, but don’t have a dedicated ISP programmer.

This solution have existed as a patch for avrdude 5.10 for more than two years. Luckily embedded Linux systems got much more popular now and Richard Nauber ported the patches to the current SVN version (a task I’ve been meaning to do for quite a while). This prompted me to bring the patch up to standard and with the help and feedback of the awesome people on the avrdude-dev mailing list it’s included in the official avrdude SVN. No more patches, yay! Until a new version of avrdude is released and finds its way into distributions here’s a quick description how to build and use it yourself. I’m assuming you’re doing this on a Linux system with a complete C development environment – gcc, autotools, etc. If you get some errors try to figure out which package is missing and install it using your distributions package manager.

First, checkout a fresh copy of avrdude SVN trunk:

$svn co svn://svn.savannah.nongnu.org/avrdude/trunk

Bootstrap autotools:

$cd trunk/avrdude
$ ./bootstrap

The linuxgpio programmer is not enabled by default, because it’s usually only useful for embedded Linux systems. You have to pass an additional option to configure to enable it:

$./configure --enable-linuxgpio=yes

If you’re doing a cross-compile as opposed to a native build you may want to pass some additional options like:

$./configure --host=arm-angstrom-linux-gnueabi --enable-linuxgpio=yes

Finally:

$make

If all went well you should have the avrdude executable and avrdude.conf files in the current directory. If you want to do things the proper way you can try to prepare a package for your favourite distribution (in which case you may find it easier to sart from an available source package). I won’t bother with this for now and just copy the two files mentioned above to my board using scp.

Now, time for some hard(ware) work! You need to connect your Linux system’s GPIO pins to the AVR and also supply power to it. It’s recommended that you take some measures to keep the magic smoke in. Make sure both systems use the same or compatible voltage levels i.e. 3.3V vs 5V. It’s also a good idea to put some resistors in series to limit the maximum current. A more robust approach would be to put a 3-state buffer in between, you can find a description of such a setup here.

For my tests I made a simple straight trough cable connecting the 4 GPIO pins, 3.3V power and GND from a RaspberryPi to the ISP connector of a Freeduino board, equipped with an Atmega168. Note that this make the Atmega168 work a bit out of spec, because at 3.3V its max frequency is 12MHz and not 16MHz but it worked fine for me. Also note the Freeduino is not connected or powered by anything else, as it normally runs on 5V, only 3.3V is being supplied through the ISP connector. It happened so that I used the pins for the hardware SPI interface of the RPi, but this need not be so, they were just the most convenient to wire with 3.3v and GND on the sides.

The picture in the beginning shows my test setup with the Freeduino connected to the RaspberryPi. Next to it, showing some other Linux boards which can be used instead – OlinuXino maxi and a Bifferboard (where it all started).

Jump to your Linux board, wherever you copied avrdude and avrdude.conf and open the latter with a text editor. By default the entry of the linuxgpio programmer is commented out, because there is no way to know how you wired things up in your setup. Uncomment it and replace the question marks with the GPIO pins to match your wiring scheme. Note that in the first version of this patch the GPIO numbers were off by one (i.e. you had to put 13 in the config file if you meant GPIO 12). This has been fixed, so now you need to put the correct number. In my case:

programmer
id = "linuxgpio";
desc = "Use the Linux sysfs interface to bitbang GPIO lines";
type = "linuxgpio";
reset = 22;
sck = 10;
mosi = 11;
miso = 9;
;

The moment of truth:

root@raspberrypi:/tmp# ./avrdude -C avrdude.conf -c linuxgpio -p m168 -U flash:w:blink.hex

If you’re lucky you should see something like this:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: „flash“ memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file „blink.hex“
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: writing flash (3526 bytes):

Writing | ################################################## | 100% 1.77s

avrdude: 3526 bytes of flash written
avrdude: verifying flash memory against blink.hex:
avrdude: load data flash data from input file blink.hex:
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: input file blink.hex contains 3526 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.97s

avrdude: verifying …
avrdude: 3526 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

root@raspberrypi:/tmp#

Enjoy!

Евала бе, електронна митница! – втора част

1 отговор

Както знаете от първа част, валидността на SSL сертификата на системата за EORI регистрация на агенция „Митници“ беше изтекла на 18.07.2012. Мога да ви зарадвам, че от няколко дни сертификатът на сървъра е подменен!

След изпращането на писма до и телефонни разговори със служители на агенцията без никакъв ефект, накрая писах и директно до кабинета на г-н Ваньо Танов. Не знам дали моето последно писмо има нещо общо, но малко след това подновеният сертификат беше инсталиран. Естествено, и в този случай наблюдавах типичният при комуникация с държавната администрация ефект „черна дупка“ – демек отговор няма. По-важното е, че има някакъв реален ефект от цялата работа и макар и много бавно нещо се случва. И така, да разгледаме така бленувания нов сертификат:

eori-new-cert.png

Забелязват се няколко интересни неща.

Сертификатът е издаден на 10 август 2012 (компютърът на който направих скрийншота явно е настроен да работи с формат mm/dd/yyyy). Хувабото е, че това е станало няколко дни преди аз да забележа и сигнализирам за проблема. Тоест има вероятност и сами да са го забелязали, или пък някой друг да е сигнализирал преди мен. Лошото е, че подновяването на сертификата се е случило около 20 дни след неговото изтичане. Нормално би било обратното – мерки по подновяването да се вземат още преди да е изтелка валидността на текущия сертификат. Още по-лошото е, че инсталирането на подновеният сертификат на сървъра явно е отнело повече от месец! Причината за това за мен си остава загадка, също както не ми е ясно защо издаването на ЕОРИ номер отнема 5 дни. Резултатът обаче е, че сървърът е работил с невалиден сертификат повече от 50 дни. Сега остава и да си оправят инструкциите за употреба, че да има и някаква полза от валидния сертификат. В момента те съветват просто да се игнорират всякакви предупреждения от браузъра.

Друг любопитен факт е, че подновеният сертификат има идентичен сериен номер със стария. Това ми се струва малко странно и не мога да си обясня причината от „Информационно обслужване“ да не го променят. В момента не се сещам за някакви проблеми със сигурността, които могат да бъдат резултат от това, но не прави добро впечатление. По принцип серийният номер трябва да е уникален за всеки сертификат на даден издател. Така двойката сериен номер/издател е уникален идентификатор за всеки един сертификат. В текущия случай обаче, поради преизползване на серийния номер се получава дублиране.

Тук ще вметна, че трябва да се разграничат понятията „подновяване“ и „преиздаване“ на сертификат. При подновяването само се удължава периодът на валидност, но се запазва съществуващата двойка ключове. При преиздаването се генерира изцяло нова двойка ключове. И при двата варианта обаче винаги се променя серийният номер. Ето мой превод на част от дефиницията на термина „подновяване на сертификат“ от rfc4949:

За един X.509 сертификат с публичен ключ този термин означава, че периодът на валидност се удължава (и, разбира се, присвоява се и нов сериен номер) …

Ако имате идея каква е причината за практиката на StampIT да не се променят серийните номера, или пък до какви желани или нежелани ефекти може да доведе това ще се радвам да споделите в коментарите.

Евала бе, електронна митница!

4 коментара

Посвещение
Посвещавам този материал на ИнжИнера, ревностен читател на този блог (вероятно единственият – здрасти, Пепи!). Неговите неколкократни подканяния спомогнаха да възстановя по-бързо сайта след дългото прекъсване.

Предистория
Миналата година си купих комплект за електрически велосипед. От Конрад/Щайнбергер тогава ме излъгаха (и предполагам все още лъжат), че контролера има функцията регенеративно спиране. От мерак да видя има ли все пак полза от тази функция си поръчах нов контролер, който я поддържа. Разбире се, произведен от братският китайски народ, стуващ към $60.

Проблемът
Телефонът ми звънна. Непознат номер. Отсреща женски глас произнесе думите, които никой интернет пазаруващ не иска да чуе – „Вашата пратка беше спряна на митницата!“. До момента бях успявал да избегна тази клопка. Основно пазарувайки от ЕС, или ползвайки за доставка на извънобщностни пратки Български пощи. За който не знае – „пощата“ по някаква причина има една суперсила, с която не разполага никоя друга куриерска компания – може да ви представлява пред митницата. И то без никакви разправии от ваша страна, просто като си вземате пратката плащате и Х лева мито/ДДС директно в пощенската станция. Този път обаче китайците бяха пратили контролера с FedEx.

Решението
Тъй като, макар и не от личен опит, съм запознат с безумието наречено „освобождаване на пратка от митницата“ дори и не си помислих да се захвана с това. Достатъчно е човек да прочете класиката в жанра или кое да е от продълженията (1, 2, 3), за да разбере, че тази работа не е за простосмъртни.

Със служителката на FedEx се разбрахме да им изпратя нотариално заверено пълномощно, за да могат те да ме представляват. Остана една малка продробност – необходим ми е и EORI номер (друго безумие, този път европейско). Служителката ме усведомява, че те могат да се заемат и с това, но ще струва скромната сума от 30 лв. Иначе самото издаване е безплатно, дори всичко може да стане он-лайн през сайта на митницата – ако имам електронен подпис. Аз имам електронен подпис.

Заблуждението
Предполагам, че попълването на електронната форма в сайта на митниците ще отнеме 4-5 минути. Мислено пресмятам, че ако работя ще спечеля по-малко от 30 лв за 5 минути. Решавам, че вместо да плащам и за тази услуга на FedEx, ще свърша работата сам. При това седейки удобно пред компютъра си! Благославям „електронното правителство“ и предвкусвам как със спестените пари се черпим бира с приятелите.

Реалността
Отварям така нареченият „ПОРТАЛ ЗА ЕОРИ РЕГИСТРАЦИЯ“ и ме посреща предупредително съобщение, че сертификатът на сървъра е невалиден. Първо си мисля, че тъй като съм с нова машина, още не съм добавил сертификатите на българските удостоверители в браузъра. Оказва се обаче, че не е така. Всъщност причината за предупреждението е, че сертификатът на сървъра е изтекъл преди около месец.

eori_cert.png

Стискам очи, надявайки се, че наистина от другата страна е сървърът на Агенция митници, и игнорирам предупреждението. За което, между другото, много прилежно съм инструктиран в трета стъпка от „Ръководството за потребителя за регистрация на еори номер по електронен път„. Къде ли другаде съм виждал това? А, да, Пощенска банка.

treta_stupka.png

След като попълвам формата с моите лични данни идва ред за подписването. Ползва се някакъв Java аплет, който обаче не работи. Казва ми, че нямам електронен подпис/смарт карта. Тук е моментът да спомена, че използвам Линукс базирана операционна система.

Решавам да се обадя на предоставеният телефон за връзка и да се усведомя, очаква ли се въобще да работят нещата с моята операционна система. Както после ще разбера, за мой невероятен късмет, отсреща някой вдигна телефона. Първо споменах на служителката проблема с изтеклия сертификат. Тя каза, че това не е новина за тях, ама да не се притеснявам. Не било толкова важно, „работят по въпроса“. Ако не сте много наясно с техническите въпроси и какво точно означава това, погледнете секцията „Защо толкова шум за един изтекъл сертификат?“ най-долу. Относно поддръжката на операционни системи различни от Windows – не знаят, никока не са пробвали.

Отчаянието
Почти съм се предал. Вече обмислям да сваля бланката с формуляра и да подам заявлението на хартия. Поне имаме митническо бюро в Кърджали, та няма да се наложи да ходя до друг град. Или още по-лошо, да ходя при приятел да търся компютър с Windows. При тази мисъл обаче ми идва нов прилив на ентусиазъм. Няколко часа по-късно и след изчитане на малко документация за Java програмния интерфейс за смарт карти откривам следа. Освен пътят към библиотеката, при инициализация трябва да се укаже и в кой слот да се търси картата. При аплета ползван от митниците няма поле в което да се въведе кой слот да ползва. По подразбиране търси картата в слот 0. Моята смарт карта се вижда в слот 1, а слот 0 е някакъв виртуален. Променям конфигурационният файл /etc/opensc/opensc.conf (в секцията app opensc-pkcs11 pkcs11 добавям plug_and_play = false;) и картата вече се вижда в слот 0.

Успехът
Попълвам за 1374-ти път полетата с моите данни (при всеки опит се губят) и този път подписването сработва! Но, радостта не продължава дълго. Забелязвам, че точно този път съм пропуснал да попълня полето с датата на раждане. По подразбиране то е попълнено автоматично с текущата дата. Веднъж изпратени, данните в заявката не могат да бъдат променяни, докато не бъдат „обработени от оператор“.

План Б
Срокът за издаване на ЕОРИ номер е 5 работни дни (защо е такъв е напълно необяснимо за мен, но да кажем, че е тема на друг материал). Представям си, как на петия ден ми казват – грешна ти е датата на раждане, и после чакам още 5 дни. Решавам да се обадя пак на предоставения телефон и да попитам възможно ли е по някакъв начин да коригирам данните в заявлението. Никой не отговаря. В продължение на 3 работни дни, звъня по няколко пъти на ден, и никой не отговаря.

Решавам да отида до местното митническо бюро. Описах ситуацията на служителя, а той ми отговори с реторичния въпрос: „И аз какво очаквате да направя?“. Отговорих му, че очаквам да ми съдейства да отстряня грешката с датата. Последваха известни поучения, за какво въобще се опитвам да ги ползвам тези електронни услуги, и един вид сам съм си виновен. Виж, ако бях подал на хартия, до сега да са ми я свършили работата. В крайна сметка един от служителите се задейства и проверява в електронната система получените заявления за ЕОРИ. Резултатът – при тях няма получено по електронен път никакво заявление от мен. Нито с правилна, нито с грешна дата. Питам, в такъв случай, мога ли да подам при тях хартиено – не може! Какво щяло да стане, ако извъднъж получат и електронното и се дублират. Те нищо не могат да направят по въпроса, отпращат ме да се разбера със „София“. Дават ми телефонния номер, на който звъня от 3 дни.

План В
Издирвам от сайта някакъв адрес за електронна поща. Не вярвам, че въобще някой ще ми отговори, ама все пак се пробвам. Ненадейно ми отговарят и дори говорим по телефона. Служителката ми казва, че това със датата не било проблем и се ангажира да провери защо заявката не пристига в Кърджали. Аз се оплаквам и на нея за изтеклия сертификат – и тя знае, че е изтекъл. Но, казва ми, „то подновяването не става със щракване на пръсти“ и споменава нещо за началника. Тя винаги съветва хората да не се и опитват да ползват електронните услуги, защото „с тях само проблеми“.

Развръзката
Наближава последният 5-ти работен ден от срока за идаване на номера. Напомням по елелктронната поща на служителката, с която говорих, че на следващият ден изтича срока за издаване на номера. В последният 5-ти работен ден получавам писмо от служителката съдържащо така лелеяният номер (който, между другото е просто ЕГН-то ми BGB отпред и ZZZ2 след него). Също ме усведомява, че относто проблемите със сертификата „колегите са предприели действия по преиздаването на сертификата“. Това се случва на 21.08.2012. Сертификатът е изтекъл на 18.07.2012 и не е подновен и до ден днешен – 04.09.2012. Писмото завършва с „Надявам се вече всичко да е наред!“

Изпращам прочуствен отговор, че не всичко е наред. Обяснявам, че след като има проблем с електронните услуги, той трябва да бъде отстранен, а не да съветват хората да не ги ползват. Питам в какъв срок ще бъде подновен сертификатът. Съобщавам и за още дребни проблеми като валидацията на мейл адресите и, че часовника на сървъра е грешен и показва повече от 2 часа в бъдещето. На долната картинка може да видите, че заявлението ми е регистрирано като прието в 15:30, а все още е 12:51.

eori-date-time.png

Пращам последно писмо, за да кажа, че съм се объркал и проблем с валидацията на адресите най-вероятно няма. Също ги поздравявам, че поне са сверили часовника. Явно вече съм в СПАМ филтъра, защото никой не ми отговаря на писмата.

Защо толкова шум за един изтекъл сертификат?
Предназначението на сертификатът е да сте сигурни кой стои „отсреща“. Тоест дали наистина сте се свързали със сървъра на агенция митници, или някой, който само се представя за него. В момента е изключително лесно да се реализира спуфинг измама. Всеки, който има достъп до интернет трасето някъде по пътя между вас и агенция митници може да го направи. Обикновено, при подобни измами целта е да се прилъже потребителят, че е посетил сайт, който той ползва и да въведе своите име/парола за достъп. Това могат да бъде сайтове за уеб базирана електронна поща, интернет магазини и т.н. Ако потребителят не осъзнае, че всъщност не се е свързал с истинкия сайт и въведе своите данни те вече са в ръцене на измамника. Сега злосторникът ще има достъп до електронната поща/профила на жертвата.

Възможностите за измама чрез имперсониране на системата за електронни заявления за EORI са много по-сериозни. Тук се ползва предоставен от сървъра Java applet за полагане на електронния подпис върху заявлението (според мен лоша идея, но това също е друга тема). Поради тази особенност измамникът съвсем лесно може да постигне следните две неща:

1. Пълен достъп до локалните файлове на компютъра на жертвата. Да, всички документи и информация които се намират на твърдия диск на вашия компютър. Ако трябва да сме съвсем точни, тези до които има достъп текущия потребител.

2. Да положи електронния подпис на жертвата върху произволен документ, без тя дори да подозира за това.

Смятам, че тези рискове са доста сериозни, а поведението на агенция „Митници“ – меко казано безотговорно. Въпреки неколкократните ми запитвания по електронната поща така и не получих отговор на въпросите кой е отговорен за това и в какъв срок ще бъде подновен сертификатът. Май няма и да получа.

Междувременно, „За да си нямате проблеми, подайте си заявлението на хартия …“.

Вижте продължението в Евала бе, електронна митница! – втора част.

Прекомпилиране на Ардуино bootloader

2 коментара

В тази статия се описва как да се заобиколи проблем при прекомпилиране на bootloader-а на Ардуино при използване на gcc версии 4.х. Също така има кратко описание какво е bootloader и защо бихте искали да го промените и компилирате наново. Ако желаете превод на български, моля оставете коментар.

Some time ago I needed to recompile the Arduino bootloader for the ATmega8 MCU. Unfortunately I run into one problem – the generated executable code was too big. I write this to share the workaround I’ve found. If you don’t know what I’m talking about, but are curious to learn scroll down for a quick explanation.

Basically when trying to compile the bootloader it doesn’t fit in the 1KB designated space. The error spewed out is something like:

address 0x203e of ATmegaBOOT.elf section .text is not within region text.

The problem turns out to be a bug in more recent versions of avr-gcc. The binary in the Arduino distribution was compiled using the 3.x branch which isn’t affected and I was using a newer 4.x version. One way to handle this would be to install the complete 3.x toolchain but that doesn’t look like much fun.

Reading the bug description more closely showed that the problem is inlining functions more that once even though the -Os option is passed to the compiler to optimize for minimum size. Curiously for some other architectures even inlining a function twice can be smaller that not inlining, but for the AVR this is not the case. So until the gcc gurus figure out how to get this problem solved properly I have found a temporary workaround. At least with the Arduino bootloader adding -finline-limit=1 to the gcc parameters seems to do the trick. The code is again less that 1KB and happily fits in the bootloader section.

So, what the hell is a bootloader and why would I want to recompile it? I’m glad you asked :)!

The ATmega8 is a small computer – everything needed on a single chip. To make it useful, as with any computer, we need to put some program in it. More precisely on the internal flash memory. One way to do this would be using a special cable or adapter called a programmer. If we don’t have such cable or we want the user of the device to be able to change the software in the field there is another way. We can use any of the built-in peripherals to get the program, the most popular choice being the USART module aka ‘the serial port’. But there’s one catch – in order to do this we need to write a very small program that reads the data from our peripheral of choice and writes it to the flash memory. This small program is called a bootloader. When I say small in the case above this meant less than 1KB of the total 8KB of flash in the ATmega8.

If you have acquired an Arduino or Arduino like board it most probably already has the bootloader programmed into the chip. Thanks to its help you can just plug in the USB cable in your PC, and have your sketch uploaded to the board. The USB cable actually connects to a USB/UART converter chip, or more precisely the FT232RL, so from the viewpoint of the ATmega we are talking through a serial connection. One of the very important parameters of a serial link is its speed usually measured in bits/second. When we configure the serial link speed in the AtMega MCU we use the frequency of the CPU, or the CPU clock as a base, Usually this clock signal is run through a divider, so the „UART clock“ (i.e. the UART speed) is set as a fraction of the CPU clock. So if we change the CPU clock, but want to keep the same speed, we need to change the divider used. Since this divider is specified in the bootloader source code a recompile of the bootloader is needed.

By default the Arduino has a 16MHz external crystal (the shiny metal box that has written 16.000 on top) and that’s the frequency it runs at. In my case I wanted to run it at 4MHz or even at 1MHz instead. Why would anyone want to do this? Why run a CPU that is perfectly capable of running at 16MHz at only 1? The reason is power consumption. The lower the frequency the lower the voltage supply that is required. And the lower the voltage – the lower the power. For example certain parts of the ATMega family that have a V suffix, like the ATmega88V can work from as low as 1.8V if the CPU frequency is kept under 4MHz.

When a device is going to be battery powered it is important to make the batteries last as long as possible. One thing that helps to accomplish this goal is to run the CPU at the lowest frequency that satisfies the application’s need for computing power. Taken to the extreme this means 0Hz, or completely stopping the CPU. And this is exactly what should be done if the CPU isn’t needed for the moment – put in in power-down mode.

I got a little carried away here, but ways to minimize the power consumption is such an interesting topic. Do you have any power saving tips to share?

svn: Cannot replace a directory from within

Yesterday I was trying to do a merge in a svn repository using a command like:


rado@ubuntu-laptop:~/svn-wc/$svn merge svn://somehost.net:3690/some/very/long/path svn://somehost.net:3690/some/other/very/long/path

just to get the really strange error – „svn: Cannot replace a directory from within“.

After reading through mailing lists messages, bug reports and anything else I could find about this error there was no enlightenment.

In the end the cause turned out to be a simple typo in one of my very/long/paths.

I shouldn’t trust error messages too much!

Всяко хлапе знае за Линукс

2 коментара

Вчера гледах част от предаването „Това го знае всяко хлапе“ по BTV. За моя изненада на участичката зададоха следния въпрос: „Кое животно е знак на операционната система Линукс?“ (може и да не бяха точно тези думи, цитирам по памет). Споменаването на Линукс по телевизията може само да ме радва, защото това означава, че свободният софтуер е все по-популярен. За съжаление обаче организаторите на предаването не си бяха свършили работата както трябва и според мен въпросът е формулиран некоректно.

Линукс е само ядро, един от компонентите на операционна система. Освен ядрото за да имаме функционираща операционна система ни трябват много библиотеки, обвивка, иснтрументи и помощни програми, а вече хората очакват и графична среда. Ричард Столман предлага тази съвкупност от програми да се нарича ГНУ/Линукс, тъй като голяма част тях са разработени от проекта ГНУ. Освен това има много ГНУ/Линукс операционни системи, или различни набори от компоненти, които наричаме дистрибуции.

Често в ежедневната реч много от нас използват просто думата Линукс, но обикновено от контекста се разбира дали става въпрос за ядрото или за някоя от ГНУ/Линукс дистрибуциите. Когато е възможно двусмислие обаче, смятам че винаги трябва да се поясни какво точно се има предвид. Горният случай е точно такъв.

Според мен по-добре би било да се каже „Кое живото е знакът на Линукс?“, за да не се затормозяват хората незапознати с термина ядро. Употребата на пълен член „операционната система Линукс“ е логически неправилно, тъй като нямо точно една Линукс операционна система, а много ГНУ/Линукс дистрибуции. Всичко това може да ви се струва излишно мрънкане, но както се оказа от тези детайли зависи дали отговорът който сте дали ще се приеме за верен.

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

Скъпи сценаристи на предаването, или който там от екипа подготвя въпросите: на така зададеният въпрос има повече от един верен отговор!

Освен Тукс пингвина талисман на Линукс ядрото, и Гийко гущера за които вече споменахме ще се учудите колко още представители на животинския свят ползват ГНУ/Линукс.

Та само във Федора проекта има цяла зоологическа градина, дори някои видове за пръв път са били открити там! Ето и списък, който не претендира за изчерпателност*:

* извадил съм жвотните свързани с дистрибуции от http://chl.be/mascots/

В борбата за сериен порт

5 коментара

Историята по-долу се разви преди доста време, но скоро ми се наложи да си я припомня. Реших, да си запиша нещата тук, пък може и на някой друг да свърши работа.

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

RS232 интерфейсът може да е бавен, с обемист конектор и да работи на малки разстояния, но той има и едно предимство – изклютително прост е. Ако се занимавате с разни малки контролери ще знаете, че той е в порядъци по-удобен, достъпен, евтин и прост за реализация от USB или ETHERNET например.

И така, за да се сдобия с тази незаменима екстра се запътих към близкия магазин за конвертор от USB към сериен порт. Взех си и компютъра, защото за мен е важно чудото да работи под Линукс, а обикновено по опаковките това не го рекламират много. Преди да го купя включих USB конверторът и ядрото веднага го разпозна и се появи нов сериен порт. Купих го.

За съжаление радостта ми беше кратка, защото след като се прибрах установих, че въпросният конвертор не може да си комуникира с никакво серийно устройство – макар, че се разпознава. Може да е бил дефектен моя, но по-сокоро предположението ми е, че има проблеми с драйвера – cypres_m8. След това съм пробвал с други конвертори с чипове на FTDI и Prolific 2303 и при тях нямаше такъв проблем със серийната комуникация. Въпреки това при ситуации в които използвате серийния порт не съвсем по предназначение, а примерно превключвате контролните линии много бързо (bit banging) за да говорите някакъв друг протокол тези конвертори може и да не работят.

В крайна сметка реших да си взема „истински“ RS232 под формата на PCMCIA карта. След търсене с Гугъл попаднах на блога на Данчо, където той беше обявил за продажба точно такава карта поради несъвместимост с неговия компютър. Видяхме се. Пъхнах картата в моя компютър – ядрото я разпозна веднага – взех я.

Прибрах се. Първата ми работа беше да тествам новата придобивка – отново нищо! Никаква комуникация, нито с мобилния ми телефон, нито със стар външен модем, който успях да изровя.

Самата платка получих в картонена кутия, на която имаше йероглифи и единствено се разбираше, че пристига от Хонг Конг. Имаше и диск с драйвери – само за Унидоус. Всички отличителни белези по картата се свеждаха до надпис „BBL PCMCIA RS-232 CARD“. Търсенето за информация по тези ключови думи не даде полезен резултат.

Решен да не се предавам толкова лесно направих следния експеримент. Стартирах minicom и настроих порта на скорост 9600 бита в секунда. Пуснах да се изпраща файл съдържащ единствено буквата „а“. След това закачих изходящата линия (TX) към осцилоскоп и видях следното:

oscilloscope screen

Ура! Картата все пак работи и дори предава данни. Единствената малка подробност е, че ги предава доста по-бързо от колкото се очаква. На картинката по-горе осцилоскопът е настроен на 50 микросекуни за деление по оста Х. Грубо в едно деление се предават 3 бита, значи скоростта е над 62500 бита/секунда – доста над очакваните 9600.

След още малко търсене, проблемът напълно се изясни. Основният компомент осигуряващ серийната връзка e чип от вида UART (Universal Asynchronous Receiver-Transmitter). По-конкретно в моята платка има 16c950. Ядрото го разпознава правилно и драйверът успешно си говори с него. Скоростта обаче се определя чрез делене на тактовата честота получена от външен кварцов резонатор. Оказва се, че няма начин драйверът да разбере каква е честотата на този резонатор. До преди време най-масово се е използвал резонатор с честота 1.8432 MHz, която разделена на 16 дава базова скорост от 115200 бита/сек. Това е записано и в кода на драйвера като стойност по подразбиране.

В момента често се използват резонатори с по-високи честоти за да се постигнат по-големи скорости. Имайки предвид, че при мен получената скорост е около 7-8 пъти по-голяма от очакваната и стандартните стойности дадени в спецификацията на чипа установих, че в моята платка резонаторър най-вероятно е с честота 14.7456MHz, което разделено на 16 дава базова скорост от 921600 бита/сек. За щастие има лесен начин тази скорост да бъде указана с помощта на програмата setserial:


setserial /dev/ttyS0 baud_base 921600

Повтарям теста с осцилоскопа и този път резултатът е доста обнадеждаващ:

oscilloscope screen

Предаването на един бит отнема малко над 2 деления или 100 микросекунди. При зададена скорост от 9600 това е точно колкото се очаква – 1/9600=0,000104167 сек или около 104 микросекунди.

Комуникацията с мобилния телефон, стария външен модем и всичко друго което закача вече работи!

Остана само да добявя едно udev правило, за да не пиша горната команда всеки път когато пъхам картата. Аз си създадох нов файл – /etc/udev/rules.d/10-serial.rules и в него добавих само един ред:

KERNEL=="ttyS0", RUN+="/bin/setserial /dev/ttyS0 baud_base 921600"

Вече всички инструменти са на лице и мога да се заема с работата по проекта за монтаж на вентилатор в банята :).

Линукс курсът приключи

2 коментара

Миналата седмица беше последната лекция от Линукс курса.

В началото дойдоха повече от 25 човека и дори не стигнаха столовете в залата. Към края редовните поситетили останаха 4-5.

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

Надявам се на тези които избраха да слушат какви ги говорим да им е било интересно и да са научили ползени неща. Благодаря им за сериозното отношение и постоянството! Също така специални благодарнисти на Васко за любезното домакинство!

За който се интересува дали и какво ще има за в бъдеще – не мога да кажа, зависи от всички нас. Ще се опитаме да не оставим нещата до тук, но кога и под каква форма ще продължат все още нямам идея.

Може би вие имате?

Мартеници онлайн

Вашият отговор

Независимо дали вече сте изтрезняли след вчерашният празник на виното, или сте още опиянени от любовта ви предлагам да разгледате сайта http://martendom.com. Ако искате да зарадвате приятелите си с красиви и качествени мартенички, а нямате време да обикаляте сергиите със сигурност ще ви е от полза.

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

Аз имам скромен принос в направата на сайта. Разбира се, като почти всеки сайт и този не е завършен, но вече е напълно функционален. Имаше няколко интересни идеи за които не остана време. Живот и здраве – догодина!