Има го в сайта това
https://raw.githubusercontent.com/Elive/usb-bootable-elive/master/tree/usr/bin/usb-bootable-elive
от пръв поглед - трябва диска да е с дялове, и гледам и "uu=" участва,

Без да се задълбочавам, изглежда boot имаш. т.е зареждаш ядроо със скрипта. От там на татъка се изпълнява скрипта, който чете параметрите от командната линия предадена при зареждане на ядрото.
От рода на root=/dev/ xxx.   Но как точно е реализирано, само скрипта знае. Повечето дистрибуции монтират на ред всичко възможно за монтиране и търсят определено име/директория, и файл с точно дадено име, който да монтират. Ако те не го намерят, продължават, и на края предават управлението на рот файловата система на ядрото, което се случва при теб. Съобщенето че скуаш файловата система липсва, говори именно за това.
Не бъркай първоначалното зареждане на ядрото, с това, което ядрато после трябва да зареди и монтира, обикновенно проблема е, че имаш/нямаш дялове на флашката, а скрипта очаква обратното, и тези параметри, които са при ботване, става така, че командната линия е грешна.
Биоса може да гледа на флашката по два начина - като хард диск или като флопи,
в зависимост как е форматирана. Ако тя има дялове - хард диск, ако няма - флопи. Представи си, че скрипта търси усб хард диск, а ти имаш "флопи". Отделно, имената и директорийте трябва да са точно както очаква скрипта, може и да има някакъв друг конфигурационен файл, то варианти безброй. Виж в сайта на дистрото, определено твоя проблем са имали и други.

Здравейте

купих си една CNC машина и като пристигна се опитах да я включа.
Свалих диска и го дадох за стенд. Казаха ми че диска е здрав, но необяснимо просто спира и за час, час и нещо не зарежда, след което продължава и после пак и пак...
Имам параметри и инсталационни файлове за машината. Трябва ми помощ за линукс.
Диска е IDE.

Доколкото разбирам, машината ти работи ма спира. В такъв случай първо си направи копие на диска. Машината ти подържа много лог файлове, трябва да ги прочетеш и видиш защо е така. Може да се договориш с италянците да им ги пратиш да ги видят. Ако се навият. Час спиране прилича на прегряване. Виж шпиндела и двигатели, трансформатори. Машината може да спира от много неща, най невероятно  е да е от диска.
-Дали спира на едно и също място.
Има ли светодиоди и показват ли някакъв проблем - би трябвало в ръководството да има.
Обаче, с тоя софтуер ще береш ядове ако го затриеш и затова първо копие.

Примерно с кwrite
 отваряш, с кодиране докато не го прочетеш правилно, и след това го записваш с каквото искаш кодиране.

Не знам, дали си объркал нещо или не, защото почти нищо не ти се разбира от написаното. Казах ти кой е най- лесният и тестван от мен многократно начин за инсталиране на Skype. Ти, ако искаш го инсталирай и от пакети за Arch.

На Убунту 13.10 имам минималното от хранилищата за да тръгне LXDE и другото е компилирано от git. Намам QT4, QT5 е, и тн. На Убунту 13.04 имам скайп и там си върви. Ако го копирам в 13.10  и му дам къде са библиотеките, чрез  LD_LIBRARY_PATH пак върви. Но това значи, че трябва да пазя и 13.04 и да е монтиран. Както съм дал в командата ldd skype, започнах да качвам библиотеки , обаче това са нещо огромно заради един скайп, а някои вече ги имам компилирани и ще стане мазало. 
По начина, който даваш, при мен не става, но повредата си е в моя телевизор. Благодаря ти за информацията.

По подразбиране, multiarch поддръжката в Убунту е разрешена.
Просто, разрешаваш или добавяш Partners хранилищата и изпълняваш в терминал :
sudo apt-get update
sudo apt-get install skype
Това е.

Вероятно нещо съм объркал, щото търсех абсолютния минимум за LXDE да тръгне. Скайпа ми е skype-4.2.0.11.tar.bz2, не е в убунто хранилищата. Дава без добавяне с
LD_LIBRARY_PATH на допълнителни библиотеки,
ldd skype
   linux-gate.so.1 =>  (0xf7753000)
   libasound.so.2 => not found
   libXv.so.1 => not found
   libXss.so.1 => not found
   librt.so.1 => /lib32/librt.so.1 (0xf58c0000)
   libdl.so.2 => /lib32/libdl.so.2 (0xf58bb000)
   libX11.so.6 => not found
   libXext.so.6 => not found
   libQtDBus.so.4 => not found
   libQtWebKit.so.4 => not found
   libQtXml.so.4 => not found
   libQtGui.so.4 => not found
   libQtNetwork.so.4 => not found
   libQtCore.so.4 => not found
   libpthread.so.0 => /lib32/libpthread.so.0 (0xf589e000)
   libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf57b5000)
   libm.so.6 => /lib32/libm.so.6 (0xf5771000)
   libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf5754000)
   libc.so.6 => /lib32/libc.so.6 (0xf55a3000)
   /lib/ld-linux.so.2 (0xf7754000)
Благодаря за инфото,начи си е ок , при мен е фала- ще я карам така, щото работи, а 14.04 ще търся от хранилищата.

Начи новите дистра си ги инсталирам от работещо  старо, отварям конзола и debootstrap върху празен монтиран дял, после chroot там и го доисталирам. Така ми е най-мързеливо, обаче скайпа сега не тръгна. на х64 съм. и сопкаст плеъра и други 32 битови дивотии .
Начи реших проблема с копи -пейст на 32 битовите библиотеки, и после стартирам каквото ми трябва със скрипт
#!/bin/bash
export LD_LIBRARY_PATH=/x/i386-linux-gnu/
/x/skype-4.2.0.11/skype
Понеже имам доста сериозен софтуер качен, не ми се ще да го тъпча с  32 битови библиотеки де, ако са много.
Та въпроса ми е-
как и какво точно се качва за скайп и сие. В смисъл, нещо , което е пробвано и работи,  нямам възможност да експериментирам щото ако скапя софтуера, ще ми отиде поне седмица за възстановяване.
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.10
DISTRIB_CODENAME=saucy
DISTRIB_DESCRIPTION="Ubuntu 13.10"
x86_64 GNU/Linux


 

Rpi
За правене  на софтуера на Rpi  с buildroot тук давам командите,
използвам в случая готов toolchain  на  Sourcery Code
единствено за да спестим време, че компилирането му е доста време.
Избрани са пърл , ssh, които ще трябват после , и други полезни неща, които са по избор.
 
изтегляне и конфигурация

git clone git://git.buildroot.net/buildroot
cd buildroot/
make rpi_defconfig
make menuconfig

Toolchain  --->
 Toolchain type (Buildroot toolchain)  --->External toolchain
 Toolchain (Sourcery CodeBench ARM 2013.05) 
 

• Purge unwanted locales

  (C en_US bg) Locales to keep
 

• Register toolchain within Eclipse Buildroot plug-in

System configuration  --->
 /dev management (Static using device table)  --->
 /dev management (Dynamic using udev)
(****) Root password
 Baudrate to use (38400)

*цялата файлова система вградена в  ядрото, в zImage е всичко, зарежда се в рам и там работи. За бързина и пазене флаша.
 Filesystem images  --->
 

• cpio the root filesystem (for use as an initial RAM filesystem)
• initial RAM filesystem linked into linux kernel

Package Selection for the target  --->
 Hardware handling  --->
 

• lshw
• usbutils

Interpreter languages and scripting  --->

• perl

Networking applications  --->
 

• openssh
• udpcast

  udpcast tools selection  --->
 

• sender
• receiver

Text editors and viewers  --->
 

• nano

< Save >  < Exit >

make

фарматираме си флаша в 1 дял, фат32,
в директория buildroot/output/images/rpi-firmware  е фърмуера,
копираме го на флаша, нямаме директории, всичко там в главната.
Копираме и  buildroot/output/images/zImage пак там.
И това е. Включваме и гледаме къде ше се появи / аз гледам в рутера dhcp клиентите./. Номера е, че ядрото е конфигурирано да конфигурира връзката, а не скриптовете. Ако не искаме това
make linux-menuconfig
При мен zImage е 25-30 Мегабайта, /голяма част от това са драйверите, може да ги махнем или сложим на флаша и да се монтират после при нужда .../
влиза се с
ssh  root@ip.adr.x.x     
при  мен точно
ssh root@192.168.2.107

--------------


Сега, след като е инсталирана базовата система, и имаме достъп през
ssh, трябва да направим развойната среда. Който му трябва де, да компилира и тества приложения.

Опцията
 

• Register toolchain within Eclipse Buildroot plug-in

създава един файл в  $HOME/.buildroot-eclipse.toolchains
В Eclipse, инсталираме  buidroot плагините.
https://github.com/mbats/eclipse-buildroot-bundle/wiki
правим си проекта и го компилираме.
В
http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
е обяснено как да влезем директно от Еклипса в RPI, и там с копи пейст да прехвърлим изпълнимия файл и да го стартираме.
Просто разчоплете менюто Windows->Show View->Other...-> Remote System ...
Отварянето на  /dev/ttyAMA0 иска няколко модификации
http://www.raspberry-projects.com/pi/pi-operating-systems/raspbian/io-pins-raspbian/uart-pins

Поддръжка на сериалният порт, UART1 в  buldroot имаме готова на
QT,QT5,
Python  external python modules  --->python-serial
 На Perl трябва допълнителен модул,
http://search.cpan.org/~cook/Device-SerialPort-1.002/SerialPort.pm
а класиката си е програма на Си.
На Питон има и скрипт с който може да се програмира STM32 чипа
http://www.raspberrypi.org/phpBB3/viewtopic.php?t=49574&p=386435
 

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

Raspberry Pi

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

Raspberry Pi имат много интересна и според мен доста комерсиална стратегия,  евтина платка, и после други разходи.
Отсега поставяме условие,  никакви клавиатури, мишки, монитори, разни бързи и големи флаш карти. Освен това, тежки дистра, които и отгоре на това монтират в четене-запис флаша, и го скапват бързо.
Флаш картата трябва да е от скапана, по скапана,  бавна, и по възможност, ненужна за друго. Примерно 128М максимум, нещо втора употреба.
Такава карта е напълно достатъчна, да ботнеме за 10 секунди, да си свършим работата и изключим Pi -то. Монтирането е само за четене, в един FAT32 дял.
За нас особено е важно записа да става без разни имаге програми или
dd bs=1M if=/distro.img of=/dev/xxxx (целия диск, не дял)
блок сайзе,  bs=ххх може да го няма, 4 М дават за по бързо
но така записваме имидж файл, което значи, че с развалени участъци от  флаша просто има проблеми. Дали картите имат някакви смарт функции, и разни скорости, от това бягаме като дявол от тамян.
Просто копи-пейст е достатъчно практичен начин, и спираме до тук.
Преди да борим с платката, трябва да я захраним, и то с добро захранване,
иначе ще има проблеми.
От компютъра примерно, с усб кабелчето си е мижаво захранване,   
от линка долу, или от само блок, като окъсим зелен-черен, или от куплонгите.
 http://ydoma.info/kompjuter-remont-bloka-pitanija-kompjutera.html
се подава на
http://elinux.org/File:GPIOs.png
4 -то +5в и 6-то – маса.
http://elinux.org/RPi_Low-level_peripherals#Power_pins
впрочем има много важно и нужно  инфо в
http://elinux.org/Main_Page

Изключват ли тия ограничения десетките големи дистра?
http://elinux.org/RPi_Distributions
ами не, просто може да боднем един усб флаш, който да ползваме когато потрабва, но флаш картата е ботлоудер.
Както е в
http://www.berryterminal.com/doku.php/berryboot
Евентуално, защото 128М (по примерното задание) са абсолютно достатъчни за да си направим наше дистро с билдрот
има доста
https://github.com/albertd/buildroot-rpi
https://github.com/gamaral/rpi-buildroot
https://github.com/cellux/rpi-buildroot
и кой знае още колко,
 но самият
http://buildroot.uclibc.org/
поддържа Rpi  и то доста добре за нашият случай.
- изтегламе примерно 2013.08-rc2, щото е от няколко дни, или от git ако няма нещо свежо и четем
http://git.buildroot.net/buildroot/tree/board/raspberrypi/readme.txt

make rpi_defconfig
make menuconfig

make menuconfig трябва да викнем и без да пипаме нищо, но по добре е да променим някои неща, щото компилирането е дълго, а ако пипаме тулчейна, ще трябва отново всичко.
http://cellux.github.io/articles/diy-linux-with-buildroot-part-1/
в случая повечето неща в линка са вече в rpi_defconfig, ние просто може да изберем С++ поддръжка, локалите, ipv6 WCHAR така че после да не прекомпилираме всичко.
резултата /пoлзвам щела на busybox /
http://elinux.org/RPi_Low-level_peripherals#Bash_shell_script.2C_using_sysfs.2C_part_of_the_raspbian_operating_system

Възможността, да щракаме и четем разни пинове от Rpi ни е абсолютно достатъчна за комуникация и управление на STM32F30xx, без UART, SPI, I2C или друго. И при това обмена ще е достатъчно бавен и сигурен, за да използваме колкото си искаме дълъг кабел, или дори безжично. Благодарение на EXTI на STM32F030, контролер, който реагира  на фронт или ниво на линия с прекъсване, може да реализираме софтуерно протокол и обмен. Например с един пърл скрипт,
   http://elinux.org/RPi_Low-level_peripherals#Perl

Използването на  Arduino подобен софтуер е обаче едно стандарнтно решение
http://www.raspberry-projects.com/pi/programming-in-c/uart-serial-port/using-the-uart
https://github.com/coocox/embeddedpi/tree/master/lib/librpi

За ОС и приоритетите

Обмена с РС явно е последна грижа на такава система / за разлика от ардуйно/. С говорене ще се занимава, само като има време. РС ще чака. И обмена ще е относително бавен, асинхронен. В ST има много нива на приоритет, почти всичко обаче ще оставим за работа с периферията. Ние  имаме супер бързият DMA, разните прекъсвания, обаче, има ли смисъл, да мерим хиляди пъти в секунда напрежението в акумулатора?
 Явно не, но пък тока, ако скочи рязко, трябва да задейства защита или коригира управлението . В мили , че и в микросекуднди. То имаме действия, които трябва да обработим в периоди  от микро секунди до часове, че и дни даже.  STM32F030 e орязана версия на по големите си братя, директният достъп до паметта DMA има само един канал. Така че, ако мерим аналогови величини, доста, и има бързи от тях,най-лесно е да настоим
хардуерно им четене чрез  DMA . Така ние ще имаме всички величини, /без да се занимаваме повече с хардуера,/ в един масив. Ако го дефинираме и като обединение, върху него, ще имаме една структура, с примерно с членове
 M1_ADC. Akumulator_Voltage;
 M1_ADC.Akumulator_Current;

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


По същият начин може да реагираме и на други събития – фронтове или нива на крачета. Специализирания EXTI контролер ще свърши с удоволствие, работата. С прекъсване.
Има сума ти безработни таймери,  които просто плачат да мерят разни периоди, време и др.
Е при това положение, нужна ли ни е ОС?
Ами пак, имаме функции, които искаме да изпълняваме много рядко, един път на 5 минути да кажем – позициониране на слънчев тракер.  По честото изпълнение ще харчи ненужно енергия.
Може естествено да го решим и с таймерите , ама по  елегантно ми се вижда направо да си го боднем в главния цикъл на програмата, но функцията да се вика на всеки N-ти път.

Дефинираме указател към функция от типа void func(void);
job;
 // /бързи
job_slow; //бавни

typedef void (*func)(void);
func   job;
func  job_slow;

прототипи на функции
void f_0 ();
void f_1();
.
записваме  в масив адресите им
const uint32_t f_functions[2] ={
(uint32_t) f_0,(uint32_t) f_1}

void f_slow_0 ();
void f_slow_1();

const uint32_t f_slow_functions[2] ={
(uint32_t) f_0,(uint32_t) f_1};
и ги викаме,
#define MAX_TASKS 2
 uint8_t task =0;
void thread() {

   if (task == MAX_TASKS)
      task = 0;
        else task++;
   job = (void *) f_functions[task];

   (job)();
}

По този елементарен начин може да си викаме безкраен брой функции, като си тече главния цикъл.  Някой всеки път, други всеки MAX_TASKS път. Бавните ще се викат да кажем на MAX_TASKS * ХХХ  цикъла, още по бавните още, и така.
Лошото при една нишка идва от друго. Ако една програма забие, поради да кажем ардуйновото четене на аналогова стойност,
while (HARDWARE_FLAG != VAL);
чакане, за установяване флаг. А този случай може да си чакаме вечно, ако сме сбъркали при инициализацията.
Уотчдог таймера е за това де. Всяка от функциите ще трябва да завърши в определено максимално време. Трябва да и е забранено и е да чисти тоя таймер. Или може вместо while , да ползва if, кой както си желае.


Или майн праграмата изглежда така
 
#include "this_program_hethers.h"

void main(){

init_hardware();
init_objects();

while(1) {
       same_other_func();
        thread();
   }
}

За протоколите на обмен, между блоковете.
Начи може да не напишем/ включим и ред код  за тях, отново както при хардуера, просто трябва да предвидим такъв. Това трябва да е заглавен файл, който да е максимално машинно независим, отделен.
Той трябва да е един и същ, е като го включим в софтуера за RPI , и за ST. В нашия случай тава кореспондира с USART1. В него трябва да кажем  колко старт-стоп бита са, четност-нечетност, баунд рейт, както и какви данни ще се обменят, 8, 16 бита и т.н. Формата ня обменна,
например
typedef uint8_t byte;
typedef struct {
byte  message_size;
byte  message_number;
byte  pc_id;
byte  message_checksum;
....
} PC_TO_ST_PROTOCOL;

ypedef enum {
EMERGANSY_STOP = 0,
ZERO_POSITION      = 1,
TRACKER_X_POSITON = 2,
TRACKER_Y_POSITON = 3,
ANALOG            =               4,
....
} COMMANDS;

typedef enum {
 TARGET_M1 = 1,
 TARGET_M2 = 2,
 TARGET_M3 = 3,
....
}TARGET_ COMMANDS;

typedef enum {
SET = 1,
RESET = 2,
 READ = 3,
WRITE =4,
....
}TYPE_ COMMANDS;

Така раздробени, в един байт казваме команда, в друг обекта, в трети орерацията, и така може лесто да променяме, добавяме нови неща. Още ако фиксираме на 10 байта съобщението, като имаме твърди индентификатори в него, например 9 ти байт 0х5а, ще повишим надежността.
Остава открит въпроса обаче, какво и как да отговори М1 на RPi, отговора трябва да е от 2 части. В първата да се потвърди получаването на командата, а втората да е самия отговор. Това е заради факта, че някои неща не стават бързо, например отиването в нулева позиция на ос.В отговора трябва да има и на коя команда се отговаря, и обмена да е асинхронен. Идващите в стек, отговорите в стек, но се пращат само при поискване. 1 команда от РС, с 2 отговора.


За SPI M1,2,3,4 същата история.

За хардуера.
Закачам примерни блокови схеми, на евентуална такава система, която да се използва за контрол и управление и съответства на писаното до сега.
Макар да изглежда нещо голямо, че и скъпо, това не е така. Защото
първо , единственият задължителен модул е M1, и второ, както казах преди, очаква се чипчето да е стотинки, а платката ще е нещо такова
 http://vikiwat.com/prehodna-platka-smd-tqfp64.html
Залагайки обаче идеята по начало, ще реши как и да се проектира и хардуера и софтуера на всяка една функция. Rpi-то, макар и икономично, не е чак толкова, че да работи постоянно. То ще е в спящ режим, като очаква или да го викнат – от мрежата или от USAR-а, иле да се случи някакво друго събитие. Например искаме да включим УСБ камера за охрана през нощта, и е станало време. Как се прави това? Ами  примерно инсталирали сме  моушън, и компресирани файлове пращаме през час на адрес. Това е пример за абсолютно независими горно и долно ниво на системата, може обаче да решим
да видим дали е слънчево, в такъв случай кой кого ше пита, не е ясно.
Дали Rpi-о  M1 или обратно, зависи къде и как сме заложили  измерване и сензор. Определено по лесния и точен вариант е някъде по M2,3,4 , та значи трябва някакъв протокол .Залагайки тия неща по начало ще опрости по нататък. Връзката между M1 и M2,3,4 е ширмован  кабел за интернет, плюс, минус, MOSI, MISO, и остават 4 за избор на 4 модула. Ширмован кабел трябва, защото се очаква да е на открито, и светкавиците могат да правят големи бели.


Разликата, между програма за РС и за микроконтролер е, че във втория случай нямаме ОС, директно ни се налага да работим с хардуера. Управлението  е включване/изключване на битове по разни регистри, описани в даташита.
STM32xxx са с огромна периферия, за която не стигат изходни крачета. Почти всичката периферия е изключена при началното стартиране, на нея не се подава и тактова честота. Идеята е да си пуснем сами каквото ни трябва, да не се консумира ненужно ток.
Нашата идея пък е точно обратната – да скрием хардуерните различия, както и функции от ниско ниво  в един слой, който да е преизползваем. Обаче, вманиачаването  също е лошо,
губи се представа какво се прави. Затова ще опиша повърхностно някои неща, отначало, достатъчни да дадат идея какво се случва.
Библиотеките на контролера, които дава производителя,  и по принцип които в ARM широко се ползват , се използват дефинирани структури, съответстващи на хардуерни групи регистри, например за
 GPIO.
Вземаме една такава
GPIO_InitTypeDef GPIO_InitStructure;

и почваме да я попълваме. Пин 1.
GPIO_InitStructure.GPIO_Pin   = GPIO_Pin_1;

честота на тактиране - най-високата
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

като изход
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;

пуш -пул, и двата транзистора на изхода са включени 
PIO_InitStructure.GPIO_OType = GPIO_OType_PP;

включен е вградения резистор към маса /40к/
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_DOWN;

След като сме си я попълнили структурата, я даваме /чрез адрес/
на фунцията GPIO_Init. До този момент ние никакво действие върху хардуера не сме направили.
GPIO_Init(GPIOC, &GPIO_InitStructure);

Преди това обаче, ние трябва да пуснем честота на тоя порт, иначе няма да стане.

Има и друг подход, който ползва само дефинираните в заглавните файлове имена, и си работим директно с регистрите
включваме честота на порт С
RCC->AHBENR |= RCC_AHBPeriph_GPIOС;

Ако разровим дата шита, има регистър
AHB peripheral clock enable register (RCC_AHBENR)
Bit 19 IOPCEN: I/O port C clock enable
Set and cleared by software.
0: I/O port C clock disabled
1: I/O port C clock enabled

после в stm32f0xx_rcc.h
#define RCC_AHBPeriph_GPIOC               RCC_AHBENR_GPIOCEN
после
#define  RCC_AHBENR_GPIOCEN                  ((uint32_t)0x00080000)        /*!< GPIOC clock enable */
0x00080000 е 1 в 19 бит и всичко друго нули.
RCC e указател към структура,  AHBENR е регистъра, не пипаме друго, само правим OR  / RCC->AHBENR |= (uint32_t)(19<<1) /
Ако пък искаме да го нулираме тоя бит  инвертираме и AND.
RCC->AHBENR &= ~ RCC_AHBPeriph_GPIOС;
тия изпълнения на си изглеждат странни и мално сложни, но на практика, оптимизатора на gcc -то си ги оправя. Обаче, тия неща се срещат изключително много при инициализация, там бързодействие не трябва, а и не е нужно всеки да я знае, просто трябва да се знае, че този код прави тази инициализация, и е преизползваем.
От там на татък, знанията за хардуера са минимални,  

Как и за какво ще ползваме отделните крачета си е също голяма играчка, защото повечето крачета съчетават различни алтернативни функции.
За интерфейса по SPI, М1 е master, М2,3,4 са slave. Всички те ползват
SPI 1, защото  SPI 2 е опция. Както и USART2 е опция, ще е ползва USART1.
 USART1 => по пин PA14/PA15 или  PA9/PA10,
SPI =>   PA4,5,6,7 програмиране по SWD,  PA13/PA14.
Или почти целия порт А е зает, 0 до 3 може за аналогови сигнали .

За електрониката, софтуера и др.
Процесите за които писах предния пост са сложни, колкото и да не изглеждат така. Например един Стърлинг е въпрос на много сериозни изчисления, експерименти и финанси. Динамика на флуидите, топлообмен, куп формули, налучкване и др. 'Arduino'-то може да облекчи живота ни, да сложим клапи, датчици, и така един Стърлинг да стане Ериксон....
http://en.wikipedia.org/wiki/Ericsson_cycle
какво печелим .. ами това, че 'Arduino'-то може да управлява клапите,
мери налягания и тока да реализираме оптимален цикъл просто с експерименти.
Управление ще ни трябва на всяко ниво – високо, ниско, естествен избор за високото е Линукс, например Raspberry Pi.
http://www.raspberrypi.org/
За управлението на ниско ниво обаче, 'Arduino'-то трябва да е евтино
надлежно, производително, гъвкаво и най-вече такова, че да можем
да си го правим – лепим, да не иска много външни части, да е стандартно, и като се замислим куп други неща.
Заб.
---
Разбира се, Raspberry Pi е примерно спомената, но
моето мнение е, че платки от вида на  Linux + Arduino, комбинацията
всичко във едно,
http://www.pcduino.com/
не вършат работа, по съвсем прозаични причини.
---
Затова аз ще предложа нещо, което реално не е още на пазара
 STM32F030ххх
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN1826
 Това, че го няма, не е проблем, защото то е по малкото налично братче на STM32F05XXX ARM Cortex-M0.
 Интересна му е цената – 32 цента на едро, и ще цъфне на пазара скоро, след септември. Вероятно и за него ще има евтини демо платки, така че си струва да стъпим на него за основа.
Линукс, макар и мощна среда, не е пригодена за управление на процеси в реално време. 10 милисекунди даже не са гарантирано време дори и с мощен процесор.  Не само това, просто е разхищение на ресурси, да се ползва за щракане на пинове.
За STM32F030 микросекундата е много време, благодарение на богатата вградена периферия. Реално за това време може да измери аналогова величина, да я запише в рама, и да промени управлението.
 ----
За да усетим нуждата от две нива на управление, ето един проект, който се занимава с хелиостати. Хелиостатите просто казано са насочваеми огледала, евтини и прости методи / на пръв поглед/, за събиране на слънчева енергия.
http://cerebralmeltdown.com/Sun_Tracking_and_Heliostats/
На пръв поглед е лесно, но нека вземем случай, облачно време, накъде и как трябва да бъдат насочени? Един от методите на насочване е чрез изчисление. Но, трябва ни - реалното време, местоположение и други неща, които може да вземем от Интернет.
Програмата трябва да изчисли насочването на всеки един от тях, поотделно, да вземе локално време позицията на слънцето за точно това място, позицията на огледалото, на мишената, и вероятно други неща. А грешката е много опасна, спокойно може да запалим плевнята на съседа, така че нещата стават сложни...

Естествено е, преди да решим как точно ще  вържем 'системата', се оглеждаме какво 'open xxx'  може да ползваме.
'Arduino'  за STM32xxx има много, поне 4-5 написани ,  засега ги прескачам, ще спомена един проект на CoCox, Embedded Pi.
http://www.coocox.org/epi.html
/CoIDЕ може да се ползва през Wine, изтегля се директно, не през CoCenter /
Целта на този проект е да върже Пи-то с ардуйно периферията, както и самостоятелно да работи с тая периферия. Или задача, сравнително близка, с тая разлика, че  целта ни е  да го няма  Embedded Pi -то.
 
Raspberry Pi  e  изгодна за такъв проект ако е без монитор, клавиатура, а е с отдалечен достъп, и заради консумацията, не само заради парите.
http://hertaville.com/2012/09/27/raspbian-raspberry-pi/

Във връзка с темата "Алтернативно електрическо захранване в нашия дом/офис/вила"започната от laskov ще се опитам да събера някои неща, най- вече проекти с отворен код и хардуер. Защото има много такива. Ма не само линкове, а по - подробно описание и ще гледам да имат връзка, например еднакъв контролер.
Започвам с Tumanako и по точно инвертора, за които стана дума в 
http://sourceforge.net/apps/mediawiki/tumanako/index.php?title=Inverter
   
Защо точно тоя проект споменавам?
Ами проблемите са доста близки, например акумулатори, трябва да се зареждат, но най- вече заради разработеното на много високо ниво управление на ас ел.двигател, и което за нас е най-интересно, обръщането на двигатела в генератор, и от там, зареждане на батериите.... Сега се вижда връзкато май - с най-обикновено двигател задвижван от вятър, да си зареждаме акумулаторите...
 В този проект се използва контрол на много сериозно ниво
http://sourceforge.net/apps/mediawiki/tumanako/index.php?title=Control_Methods

Естествено е някой да – абе FOC не е за тоя случай, сложно, и за големи и скъпи проекти. Open-BLDC проекта / който е в тясна връзка с горният/ ползва такъв софтуер за съвсем  дребни моторчета.
http://open-bldc.org/wiki/Open-BLDC
http://open-bldc.org/wiki/File:Open-BLDC-V0_3-heatsink_top.jpg
разни ххх-коптерчета.
и той ползва stm32fxxx чип.
В нашият случай обаче, факта, че всеки ел.двигател е и генератор, ни говори, че нашият генератор ще трябва да е е асинхронен монофазен, трифазен, нещо съвсем евтино, достъпно и здраво.
 Асинхронният двигател изглежда е най-лесен за управление, подавайки му честота по малка от тази на въртенито му, той е генератор. Увеличавайки тока, увеличаваме и реакцията, и т.н... Единствено ще ни трябва информация дали се върти и с колко, да кажем един хол датчик, нещо, което може да вземем от всеки развален ветилатор за компютъра.. 
 Разбира се, абсолютно мързеливия начин е, да имаме силен вятър и директно да си вържем мотора с перките в мрежата, не ни трябва нищо друго. Ако вятъра движи  мотора,  той ще връща етергия, генератор. Същемременно, ще потдържа постоянни обороти на мотора / с малко приплъзване/.
 До тук добре, ама неприятноносттите идват със сметките.
Да кажем намерили сме мотор, обаче
- пише 220 Волта
-пише 2400 об/мин
 2400 оборота в минута са 40 оборота в секунда. Ясно е, че такава скорост е твърде висока за нас, особенно пък без редуктор/ремъчни шайби.Още по зле е положението за VAWT
http://en.wikipedia.org/wiki/Vertical_axis_wind_turbine
за които laskov спомена да пишем.
За наша радост обаче, хората по горе споменаха и за V/Hz control /верно не с хубави думи/. Или факта, че напрежението към честотата е константа, което би значело, че при 4 нерца, 4 оборота в секунда, ние може да получим 1/10 от напрежение 220 волта, или 22 волта.
Още по добре е, ако нашият двигател да е бавнооборотен.
Вторият проблем е тока. Един 2 киловатов мотор е за към 10А ток, или ние ще трябва да го ползваме в примера за 220 ватов генератор максимум
За да не задълбочаваме нещата - вероятно нито е нужно или интересно, спирам със следната диаграма
http://en.wikipedia.org/wiki/File:Couple_glissement_MAs.svg
тя е важна и интесна с това, че ни дава идея как да управлявяме мотора. В точка нула, ние сме точно във фаза и скорост с въртенето на мотора.
Ако мотора изостане ще получи усилие да ускори, ако избърза, обратно, ще генерира ток.Виждаме тясните граници при което силите са най големи, затова е хубаво да следим честотата му, но не е задължително. FOC и Direct torque control използват това и захващат мотора здраво и във фаза, нас това не ни е нужно.

Разбира се, може да модифицираме мотора - закачим магнити на ротора,Brushless AC /
http://www.youtube.com/watch?v=CrWg_3SRvGY
да пренавием и статора, и така да получим Brushless DC, или да си направим
генератора.
http://www.youtube.com/watch?v=ue1qPgUCm5k

Интересната част, за вертикалната ос турбини обаче почва от тук.
http://www.youtube.com/watch?v=tsZZyGeCXTs

Още по интересно би било и без лагери,
http://www.youtube.com/watch?v=PHVZz71rmbQ
=================

Сега, каква да е турбината, перките?  Начи има различни видове, ето тук е дадено описание.
http://www.enecsis.ru/presentation.htm
Заб. "турбина Болотова"обаче от един тип турбини, водещи началото си от водните турбини на Тесла доколкото мога да преценя.
http://www.youtube.com/watch?v=lVtEpACUVh0
http://www.youtube.com/watch?v=8CGPDhfcmUQ&feature=related
По принцип, външни неподвижни въздуховоди подобряват много характеристиката на турбините и и дават незбележим външен вид / за комшийте например/ както и безопастност от директен контакт.
http://www.youtube.com/watch?v=7TspdI4Sd1o
http://www.youtube.com/watch?v=Nsno1LW4N-o&feature=fvwrel

турбината може даже и да е нещо много красиво
http://www.youtube.com/watch?v=BD9ZcdXSwKE

..............................
Разбира се, освен с генератори и слънчеви клетки има и други начини за преобразуване на енергии, ето итересни и с реално използване,
http://nepropadu.ru/blog/guestroom/4590.html

Относно Стърлинга, трябва да се спомене теоретично много високото кпд, огромното им разнообразие, ето примерно два много малко познати вида, тервоаукустичния
http://www.aster-thermoacoustics.com/?cat=3
и с течен флуид
http://home.germany.net/101-276996/animation.htm
огромна тема, и всичко е 'open'....
http://www.youtube.com/watch?v=smelhbLBBJk