Интересный материал, но тексты, написанные таким способом практическки невозможно читать, т.к. глаз "спотыкается" на каждом третьем слове. В ЛС не пишу потому, что хочу, чтобы и другие авторы статей Хабра задумались над иными приемами выделения ключевых слов в тексте. Заранее спасибо.
Пожалуйста, хорошо, что сейчас можно вот так просто взять и написать непосредственно разработчикам. Будете в офисе Congatec Deggendorf — заходите в отдел R&D, буду рад познакомиться лично.
Баг с локом не страшный, но неприятный, и проблема именно в его внезапности. Можно обновить glibc на непатченый и пару суток с ним работать без сбоев, а потом очередной вызов чего-нибудь из pthreads внезапно упадет и приехали. Я пробовал запустить Debian i386 через debootstrap, работает, но необходимость постоянно проверять, не пришел ли новый glibc с каждым обновлением — она напрягает, так что Yocto наше все в данный момент.
Еще одна хотелка, если можно: выложите Quark_EDK2 куда-нибудь на GitHub, чтобы можно было прозрачно его форкнуть, поправить и выслать пулл-реквест. А то, к примеру, все танцы вокруг spi-flash-tools и sysimage можно было бы пропустить, достаточно лишь правильно написать файл QuarkPlatformPkg/QuarkPlatformPkg.fdf. Я уже начал это делать для 4 части моей статьи, потому что разработка DXE-драйверов подразумевает постоянную пересборку образа UEFI, а проходить каждый раз через не самый простой процесс его сборки для Galileo, даже при наличии скрипта — то еще удовольствие.
Принимаю предложение немного похоливарить, тем более от разработчика.
1. Почему Yocto, а не что-то другое — это понятно. Во-первых, над Yocto у Intel больше контроля, согласовывать добавление/изменение/удаление каких-то пакетов ни с кем не нужно. А еще потому, что в Quark X1000 имеется баг обработки префикса lock, из-за которого практически все современные дистрибутивы Linux не могут нормально работать на нем из-за постоянных сегфолтов.
2. К сожалению, создается впечатление, что Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО. Или не хочет, тут уж я не могу сказать. Понятно, что основные деньги зарабатываются продажей железа, но разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная. Куда не ткнись по поводу поддержки ПО для Atom/Quark — везде затык. За один только EMGD иногда хочется убивать, а оно там все такое. Простой пример из недавнего: интерфейс MIPI CSI2 на Atom E38xx, которые так старательно рекламируют в Embedded-среде: «наш SoC его поддерживает, все работает, можете подключать свои камеры и сразу видеть результат.» Не указано только, что драйвер atomisp2 есть только для Yocto и Timesys Fedora 20, работает только с 32-битным ядром Linux 3.10 и поддерживает работу с ровно двумя камерами на 5 МП, которые, по невероятному стечению обстоятельств, и установлены на тестовой плате для CSI, а ее, в свою очередь, можно подключить только к CRB для Baytrail. В итоге я потратил неделю на то, чтобы заставить камеру работать через этот интерфейс хоть как-то, при том, что на iMX6 этот же интерфейс работает на любом современном Linux'е из коробки.
3. Почему Quark SoC имеет всего 16 линий GPIO на данный момент? Именно вследсвие этого пришлось ставить I2C port expander и делать всю совместимость с Arduino через него. Было бы достаточно GPIO — обошлись бы level shifter'ами.
4. Почему в Quark используется архитектура i586+, при всем том, что примерно 95% софта сейчас собираются для i686? В итоге потерялось едиственное преимущество x86 (кроме отлаженных драйверов для Linux) — обратная совместимость с уже собранным ПО. А если все равно нужно все пересобирать, то можно пересобрать и для ARM или MIPS.
5. Зачем понадобилось вообще выпускать Quark в качестве отдельного SoC, какова его ниша в данный момент? Производительность меньше чем у RaspberryPi за 30$, x86 «не настоящий», интерфейсов для IoT любой Atom предоставляет больше, рекорды энергопотребления он тоже не бьет. Я понимаю, когда такое урезанное ядро используется как synthesable IP core внутри какого-нибудь Atom для поддержки TXE, но зачем его в таком виде на рынок выводить, кособокого и без GPU, да еще и рекламировать его как дверь в мир IoT, при том, что I2C (в виде SMBus) и SPI есть на любом CPU и SoC производства Intel последних 5 лет? А еще можно поставить на плату копеечный МК на Cortex-M и получить все то же самое, только дешевле и с лучшей поддержкой со стороны ПО.
Получилось немного сумбурно, прошу меня извинить, тоже редко пишу по-русски.
Хочу сказать огромное спасибо за открытый код UEFI для Galileo (как раз пишу цикл статей про него в данный момент: раз, два, три, четвертая часть на подходе), очень жду открытия UEFI для Minnowboard MAX, обещали в сентябре, но вмешались "unforseen changes". Спасибо также за первый на моей памяти JTAG TAP для x86 без NDA и за $20 вместо $5000, теперь можно писать и отлаживать baremetal OS, не заключая контрактов.
Удачи вам, всей IOTG и другим ребятам из ED. Ровно одно пожелание для всех вас от простого инженера: обратите внимание на поддержку своих продуктов со стороны ПО, желательно еще до их выхода. А то ведь Galileo уже почти год как выпущен, а репозиторий для opkg появился только сейчас, аппаратные интерфейсы на SoC есть — драйверов для них нет, и так далее. А то получается продуктивнее просто сказать, что на наших платах нет поддержки CSI2, CAN и HSUART, чем приводить их Proof-of-Concept-драйверы от Intel в пригодное для клиентов состояние. За любой сдвиг в этом направлении — охапку лучей добра вам заранее.
Собираю я тут небольшие утилиты на Qt, из которой используется только Core, GUI и Widgets. А еще я собираю UEFI-прошивки, UEFI-приложения и прочие вещи на основе UDK2014. Без студии все это вместе занимает примерно 2 Gb, поэтому 5-6Gb оверхеда — совершенно неприемлемо. Если у вас огромные диски — я за вас рад.
Очень важно. Представьте себе, скажем, ультрабук с 32GB SSD (да хоть Surface Pro), на котором хотелось бы иметь сборочную платформу, но не получается ровно потому, что полноценная VS2013 Pro туда просто не влезает.
Самое интересное, что эта возможность была в VS2010, даже отдельная редакция Visual C++ Express была, занимавшая что-то около гигабайта, но затем менеджмент решил, что пришла пора больших SSD и что каждому разработчику на C/C++ нужно дать в нагрузку еще и C#, и VB.NET, и SQL Server CE, и кучу всего остального, спасибо огромное, господа.
Замечательно. Вот только галочка Visual Studio core скачивает устанавливает ровно 221 пакет, которые занимают чуть меньше 9 гигабайт. Хорошая попытка, MS, но нет.
Один вопрос по поводу новой студии: опять нет выбора того, что устанавливать, а что не надо, и ради сборки проектов на C++ нужно ставить 10 гигабайт всяких эмуляторов Windows Phone и средств разработки для Web, которые не будут использоваться никогда?
В данный момент использую VS2013 Express for Windows Desktop ровно потому, что с ней ставится не так много хлама, как с полноценными версиями.
Если Вы можете себе представить грамотного толкового разработчика, способного сделать схему и отладить ее либо написать/портировать программу, но при этом не способного внятно и толково объяснить суть своей работы, основные принципы, положенные в основу и методы их реализации, причем обяснить как в виде выступления, так и в виде печатного выступления, то Ваша фантазия явно превосходит мою.
Мало что бывает фантастичнее, чем реальная жизнь. Если в вашем примере предположить, что толковый разработчик говорит и думает на испанском, а объяснить ему нужно немецким заказчикам за 60, которые плохо понимают по английски, причем желательно еще вчера и по телефону — получится ситуация, которую я иногда наблюдаю у себя в отделе. И ничего, справляемся.
Он может привести документацию в соответствие к некоторым требованиям по оформлению, но если Вы, как разработчик, невнятно описали логику работу узла устройства, он ничего не сможет сделать.
Логика работы узла описывается не словами, а чертежами и кодом, которые не нуждаются в переводе. Вся остальная документация, application notes, datasheets и прочее такое готовится инженерами совместно с отделом тестирования и отделом QA, и твое конкретно умение писать полезно, но решающим фактором не является. Не умеешь — поясни тому, кто умеет, вместе у вас все получится.
Моя основная мысль — не отрицая важности умения писать и взаимодействовать с людьми, нельзя требовать эти умения от инженера, иначе вам нужен уже не просто инженер, а мастер на все руки, за совсем другие деньги.
В серьезной дискуссии принято обсуждать сами идеи, а не носителей этих идей, будь они авторитетными или нет, так что будь он хоть новым Буддой — если он говорит очевидные вещи, он говорит именно их.
Новоиспеченные инженеры не умеют читать и писать потому, что на них есть спрос даже в таком виде. Не будет спроса — быстро научатся. Другой вопрос, что очень много инженерной работы требует в первую очередь хорошего знания предметной области, а затем уже социальных навыков и умения хорошо писать. На одного «писателя» приходится 10 разработчиков, которые и делают основную часть работы, а для «писать» нанимается технический писатель, который и доводит всю документацию до ума.
Я не пытаюсь умалить важность умения грамотно сделать презентацию или хорошо выступить перед аудиторией, но это все — скорее вишенка на торте, чем основные навыки инженера. В первую очередь, нужно уметь задачи решать в своей области, и у многих новоиспеченных инженеров проблемы как раз с этим.
На мой взгляд, инженерному образованию в России не хватает в первую очередь практики, обязательной для всех. Немецкие технические ВУЗы отправляются всех своих студентов на целый семестр практики, которую студенты проходят в реальных фирмах, занимаясь реальными задачами. Прямо сейчас в нашем отделе R&D работают 5 студентов: один портирует coreboot и SeaBIOS на наши платы, другой пишет библиотеку для взаимодействия с board features на C# и демо-программу для нее, третий занимается подбором подходящего чипа SuperIO для новых моделей процессоров без поддержки шины LPC, четвертый и пятый разрабатывают пост-кодер для USB Debug Port. Работают они наравне со всеми (за исключением количества часов в неделю), выступают на совещаниях, делают презентации, но в первую очередь — работают над своими проектами. И успех их, как инженеров, зависит именно от качества работы, а не от умения писать или делать презентации.
И оригинал — муть без капли нового смысла, «чтобы быть хорошим инженером, нужно уметь читать, писать и общаться с другими», но перевод — просто запредельный, и сверху еще сдобрен примечаниями переводчика. Ализар ушел на GT, но дело его живет.
BaS:Ep2 даже в 1998 mode слишком простой, ровно потому, что плазмид Peeping Tom с обоими улучшениями — OP. Активировать невидимость, дождаться противника, дать по голове ключом, смыть, повторить. Так проходится буквально вся игра, поэтому мне приходилось самому себе создавать challenge, чтобы играть было интереснее.
Добавлю как разработчик UEFI — аппаратной поддержки PIC для x86 очень не хватает. Для x64 такой код может быть сгенерирован компилятором, а для x86 его приходится либо писать на ассемблере, когда нельзя сделать его исполняемым на месте, либо вычислять реальный базовый адрес и патчить relocation table.
Мне наоборот кажется, что CD-эмулятор более универсален: грузит какие-угодно образы как при legacy-, так и при EFI-загрузке (описанная в после флешка — только legacy, для EFI придется ставить grub-efi и переделывать конфиг), внутрь можно поставить диск или SSD хоть на терабайт, и самое главное — в ODD-mode устройство получается read-only и никакие злобные вирусы ваше загрузочное устройство внезапно не отформатируют. Про удобство обновления образов выше уже написали. Недостаток эмулятора в том, что флешек разных много, а контролеры для эмуляторов делает, ЕМНИП, только iODD (Zalman продает их продукты под своим брендом на европейском рынке), поэтому если у вас неудачные BIOS/USB-контролер/карма — с эмулятора вы не загрузите ничего, а флешки можно перебирать, пока рабочая не найдется. Это не большая проблема для людей, не работающих с CRB, ES и прочими полуготовыми продуктами, но я с ней сталкиваюсь довольно часто, поэтому 100% заменой флешек эмулятор для меня пока не стал.
Мой вариант — Zalman ZM-VE300. Никакой возьни с загрузчиками, конфигурациями и всем остальным, просто кладете образ в папку _ISO на первом разделе и все. Плюс на другие разделы диска можно установить полноценный Linux с теми программами, которые нужны именно вам.
Полноценный вполне, трассировка, register watch, edit and continue и все остальное на месте.
Для отладки Atom и Core нужно устройство ITP, вроде такого:
Стоят такие штуки около 3 тысячи долларов, и требуют наличия разъема XDP на отладочной плате (т.е. нужна CRB, а не обычная плата, еще 600 долларов) и лицензионного Intel JTAG Debugger (еще 2000). В итоге получается сумма, неподъемная даже для очень заинтереснованных энтузиастов, а тут почти то же самое, но за копейки.
Можно обойтись и без нее, но я пока не настолько знаком с GDB, чтобы отлаживать прошивку прямо в нем. Добавлю также, что аппаратая отладка UEFI — новая тема для меня, т.к. покупать дорогущую Debug probe для каждого семейства процессоров фирме не улыбается, поэтому весь наш production-код отлаживается по старинке — через отладочные сообщения и макросы вроде ASSERT_EFI_ERROR. Этих средств достаточно для отладки PEI и DXE-драйверов, для которых имеются исходники, ядро SEC уже и так отлажено до нас, а всякие BLOB'ы пусть отлаживают их авторы. Также можно использовать Intel UDK Debugger Tool (UDT), но он требует наличия драйвера DebugAgent в прошивке, или его аналог от вендоров платформы, например, AMI DebugRX для Aptio, но решение Intel бесплатно, а отладочные средства AMI — удовольствие недешевое.
Сборы отменили зря, это да.
Если получалось жить в Саксонии на 500 евро — здорово, у меня в Баварии тоже получалось, но на «кутить» денег не оставалось, т.к. 350 евро уходило на жилье, и это не пентхаус, а студенческая общага с комнатой 14 кв.м.
Спасибо. Уже подался, вот сюда.
Когда допишу цикл статей про отладку UEFI-драйверов на Galileo, надо будет написать про Congatec, а то тема вычислительных модулей как-то очень слабо освещена на Хабре и вообще в рунете, а я с из разработчиками в одном кабинете сижу.
Насколько я знаю, ограничений по возрасту нет. По образованию — для поступления в любой немецкий университет или институт (я не знаю, как перевести Technische Hochschule на русский так, чтобы было понятно. Разница между Uni и TH в том, что в Uni готовят научные кадры, а в TH — производственные. University of Applied Sciences или Institute of Technology — ближайшие термины в английском) нужен так называемый Abitur, т.е. документ об окончании немецкой гимназии или его аналог. В таком качестве принимаются российские аттестаты о полном среднем образовании, дополненные либо дипломом о высшем образовании, либо академической справкой, в которой не менее 4 семестров. Подлинность иностранных аттестата и диплома обычно нужно предварительно подтвердить отправкой их в отдел BAMF (министерство по миграционной политике) той федеральной земли, в которой находится университет, но некоторые университеты принимают и неподтвержденные BAMF'ом дипломы.
Проверить свой диплом или аттестат можно через систему Anabin, статус вашего учебного заведения должен быть H+, в крайнем случае H+-.
Подавать документы нужно заранее, за 2-4 месяца до начала семестра (в германии это начало марта и начало октября), если на вашу специальность маленький конкурс — никаких проблем с поступлением быть не должно. Сразу предупреждаю, что немцы считают, что готовится к экзамену нужно за 3-4 недели, а не за 1 день, поэтому не удивляйтесь, что сессия у вас будет длиной в пару недель с экзаменами почти каждый день. Если что — я предупреждал.
И я такого студента не представляю, если честно, сам работал в либоратории Embedded Systems в качестве SHK, получая 440 евро в месяц за 10 рабочих часов в неделю. Многие местные на бакалавриате получают BAföG и не парятся, кто-то идет в Tutor'ы и Korrektor'ы, большая часть людей в магистратуре либо работает как Werkstudent, либо обучается по удлинненным программам (Teilzeitmaster, занятия с 18 часов), а днем работают на основной работе.
Если у вас нет своего жилья в городе, в котором находится университет, то 500 евро нужны в семестр, а в месяц, и это самый минимум. на который жить еще можно, но уже не очень весело.
Баг с локом не страшный, но неприятный, и проблема именно в его внезапности. Можно обновить glibc на непатченый и пару суток с ним работать без сбоев, а потом очередной вызов чего-нибудь из pthreads внезапно упадет и приехали. Я пробовал запустить Debian i386 через debootstrap, работает, но необходимость постоянно проверять, не пришел ли новый glibc с каждым обновлением — она напрягает, так что Yocto наше все в данный момент.
Еще одна хотелка, если можно: выложите Quark_EDK2 куда-нибудь на GitHub, чтобы можно было прозрачно его форкнуть, поправить и выслать пулл-реквест. А то, к примеру, все танцы вокруг spi-flash-tools и sysimage можно было бы пропустить, достаточно лишь правильно написать файл QuarkPlatformPkg/QuarkPlatformPkg.fdf. Я уже начал это делать для 4 части моей статьи, потому что разработка DXE-драйверов подразумевает постоянную пересборку образа UEFI, а проходить каждый раз через не самый простой процесс его сборки для Galileo, даже при наличии скрипта — то еще удовольствие.
1. Почему Yocto, а не что-то другое — это понятно. Во-первых, над Yocto у Intel больше контроля, согласовывать добавление/изменение/удаление каких-то пакетов ни с кем не нужно. А еще потому, что в Quark X1000 имеется баг обработки префикса lock, из-за которого практически все современные дистрибутивы Linux не могут нормально работать на нем из-за постоянных сегфолтов.
2. К сожалению, создается впечатление, что Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО. Или не хочет, тут уж я не могу сказать. Понятно, что основные деньги зарабатываются продажей железа, но разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная. Куда не ткнись по поводу поддержки ПО для Atom/Quark — везде затык. За один только EMGD иногда хочется убивать, а оно там все такое. Простой пример из недавнего: интерфейс MIPI CSI2 на Atom E38xx, которые так старательно рекламируют в Embedded-среде: «наш SoC его поддерживает, все работает, можете подключать свои камеры и сразу видеть результат.» Не указано только, что драйвер atomisp2 есть только для Yocto и Timesys Fedora 20, работает только с 32-битным ядром Linux 3.10 и поддерживает работу с ровно двумя камерами на 5 МП, которые, по невероятному стечению обстоятельств, и установлены на тестовой плате для CSI, а ее, в свою очередь, можно подключить только к CRB для Baytrail. В итоге я потратил неделю на то, чтобы заставить камеру работать через этот интерфейс хоть как-то, при том, что на iMX6 этот же интерфейс работает на любом современном Linux'е из коробки.
3. Почему Quark SoC имеет всего 16 линий GPIO на данный момент? Именно вследсвие этого пришлось ставить I2C port expander и делать всю совместимость с Arduino через него. Было бы достаточно GPIO — обошлись бы level shifter'ами.
4. Почему в Quark используется архитектура i586+, при всем том, что примерно 95% софта сейчас собираются для i686? В итоге потерялось едиственное преимущество x86 (кроме отлаженных драйверов для Linux) — обратная совместимость с уже собранным ПО. А если все равно нужно все пересобирать, то можно пересобрать и для ARM или MIPS.
5. Зачем понадобилось вообще выпускать Quark в качестве отдельного SoC, какова его ниша в данный момент? Производительность меньше чем у RaspberryPi за 30$, x86 «не настоящий», интерфейсов для IoT любой Atom предоставляет больше, рекорды энергопотребления он тоже не бьет. Я понимаю, когда такое урезанное ядро используется как synthesable IP core внутри какого-нибудь Atom для поддержки TXE, но зачем его в таком виде на рынок выводить, кособокого и без GPU, да еще и рекламировать его как дверь в мир IoT, при том, что I2C (в виде SMBus) и SPI есть на любом CPU и SoC производства Intel последних 5 лет? А еще можно поставить на плату копеечный МК на Cortex-M и получить все то же самое, только дешевле и с лучшей поддержкой со стороны ПО.
Получилось немного сумбурно, прошу меня извинить, тоже редко пишу по-русски.
Хочу сказать огромное спасибо за открытый код UEFI для Galileo (как раз пишу цикл статей про него в данный момент: раз, два, три, четвертая часть на подходе), очень жду открытия UEFI для Minnowboard MAX, обещали в сентябре, но вмешались "unforseen changes". Спасибо также за первый на моей памяти JTAG TAP для x86 без NDA и за $20 вместо $5000, теперь можно писать и отлаживать baremetal OS, не заключая контрактов.
Удачи вам, всей IOTG и другим ребятам из ED. Ровно одно пожелание для всех вас от простого инженера: обратите внимание на поддержку своих продуктов со стороны ПО, желательно еще до их выхода. А то ведь Galileo уже почти год как выпущен, а репозиторий для opkg появился только сейчас, аппаратные интерфейсы на SoC есть — драйверов для них нет, и так далее. А то получается продуктивнее просто сказать, что на наших платах нет поддержки CSI2, CAN и HSUART, чем приводить их Proof-of-Concept-драйверы от Intel в пригодное для клиентов состояние. За любой сдвиг в этом направлении — охапку лучей добра вам заранее.
Самое интересное, что эта возможность была в VS2010, даже отдельная редакция Visual C++ Express была, занимавшая что-то около гигабайта, но затем менеджмент решил, что пришла пора больших SSD и что каждому разработчику на C/C++ нужно дать в нагрузку еще и C#, и VB.NET, и SQL Server CE, и кучу всего остального, спасибо огромное, господа.
В данный момент использую VS2013 Express for Windows Desktop ровно потому, что с ней ставится не так много хлама, как с полноценными версиями.
Мало что бывает фантастичнее, чем реальная жизнь. Если в вашем примере предположить, что толковый разработчик говорит и думает на испанском, а объяснить ему нужно немецким заказчикам за 60, которые плохо понимают по английски, причем желательно еще вчера и по телефону — получится ситуация, которую я иногда наблюдаю у себя в отделе. И ничего, справляемся.
Логика работы узла описывается не словами, а чертежами и кодом, которые не нуждаются в переводе. Вся остальная документация, application notes, datasheets и прочее такое готовится инженерами совместно с отделом тестирования и отделом QA, и твое конкретно умение писать полезно, но решающим фактором не является. Не умеешь — поясни тому, кто умеет, вместе у вас все получится.
Моя основная мысль — не отрицая важности умения писать и взаимодействовать с людьми, нельзя требовать эти умения от инженера, иначе вам нужен уже не просто инженер, а мастер на все руки, за совсем другие деньги.
Новоиспеченные инженеры не умеют читать и писать потому, что на них есть спрос даже в таком виде. Не будет спроса — быстро научатся. Другой вопрос, что очень много инженерной работы требует в первую очередь хорошего знания предметной области, а затем уже социальных навыков и умения хорошо писать. На одного «писателя» приходится 10 разработчиков, которые и делают основную часть работы, а для «писать» нанимается технический писатель, который и доводит всю документацию до ума.
Я не пытаюсь умалить важность умения грамотно сделать презентацию или хорошо выступить перед аудиторией, но это все — скорее вишенка на торте, чем основные навыки инженера. В первую очередь, нужно уметь задачи решать в своей области, и у многих новоиспеченных инженеров проблемы как раз с этим.
На мой взгляд, инженерному образованию в России не хватает в первую очередь практики, обязательной для всех. Немецкие технические ВУЗы отправляются всех своих студентов на целый семестр практики, которую студенты проходят в реальных фирмах, занимаясь реальными задачами. Прямо сейчас в нашем отделе R&D работают 5 студентов: один портирует coreboot и SeaBIOS на наши платы, другой пишет библиотеку для взаимодействия с board features на C# и демо-программу для нее, третий занимается подбором подходящего чипа SuperIO для новых моделей процессоров без поддержки шины LPC, четвертый и пятый разрабатывают пост-кодер для USB Debug Port. Работают они наравне со всеми (за исключением количества часов в неделю), выступают на совещаниях, делают презентации, но в первую очередь — работают над своими проектами. И успех их, как инженеров, зависит именно от качества работы, а не от умения писать или делать презентации.
Для отладки Atom и Core нужно устройство ITP, вроде такого:
Стоят такие штуки около 3 тысячи долларов, и требуют наличия разъема XDP на отладочной плате (т.е. нужна CRB, а не обычная плата, еще 600 долларов) и лицензионного Intel JTAG Debugger (еще 2000). В итоге получается сумма, неподъемная даже для очень заинтереснованных энтузиастов, а тут почти то же самое, но за копейки.
Если получалось жить в Саксонии на 500 евро — здорово, у меня в Баварии тоже получалось, но на «кутить» денег не оставалось, т.к. 350 евро уходило на жилье, и это не пентхаус, а студенческая общага с комнатой 14 кв.м.
Когда допишу цикл статей про отладку UEFI-драйверов на Galileo, надо будет написать про Congatec, а то тема вычислительных модулей как-то очень слабо освещена на Хабре и вообще в рунете, а я с из разработчиками в одном кабинете сижу.
Проверить свой диплом или аттестат можно через систему Anabin, статус вашего учебного заведения должен быть H+, в крайнем случае H+-.
Подавать документы нужно заранее, за 2-4 месяца до начала семестра (в германии это начало марта и начало октября), если на вашу специальность маленький конкурс — никаких проблем с поступлением быть не должно. Сразу предупреждаю, что немцы считают, что готовится к экзамену нужно за 3-4 недели, а не за 1 день, поэтому не удивляйтесь, что сессия у вас будет длиной в пару недель с экзаменами почти каждый день. Если что — я предупреждал.
Если у вас нет своего жилья в городе, в котором находится университет, то 500 евро нужны в семестр, а в месяц, и это самый минимум. на который жить еще можно, но уже не очень весело.