Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Linux начинающему
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Linux
Страницы: 1, 2, 3
berkl
Цитата(Tarbal @ Aug 27 2013, 16:16) *
---



Все верно. Однако зачастую при компиляции на стадии ./configure появляются сообщения об ошибках. Мол отсутствует пакет. В большинстве случаев это стандартная библиотека.
В таком случае надо поступить следующим образом:
допустим отсутствует библиотека bison.
apt-cache search bison

изучите список программ и установите то, что подходит при помощи команды
sudo apt-get install имя_из_списка_предыдущей_команды

По мере поступления проблем спрашивайте.


Спасибо за поддержку beer.gif

Да, есть Readme, либа встала, была только маленькая заминка, надо было доставить autogen в убунту.
Есть там готовые примеры, которые предлагают откомпилировать из коммандной строки. Попробовал - получилось.

Но вот из Эклипса компильнуть не получается. Линкер не видит библиотечные функции,
хотя в modbus.h они присутствуют. Почему не видит ? Собственно тестовый проектик:


Код
#include <modbus/modbus-rtu.h>
#include <modbus/modbus.h>

#include "unit-test.h"

int main(void)
{
modbus_t *mb;
  uint16_t tab_reg[32];

  mb = modbus_new_tcp("127.0.0.1", 1502);
  modbus_connect(mb);

  /* Read 5 registers from the address 0 */
  modbus_read_registers(mb, 0, 5, tab_reg);

  modbus_close(mb);
  modbus_free(mb);

  while(1);
}


Ошибки:
"undefined reference to `modbus_new_tcp' "
" undefined reference to `modbus_connect' "
" undefined reference to `modbus_read_registers' "
"undefined reference to `modbus_close' "
"undefined reference to `modbus_free' "



С уважением.
mdmitry
Цитата(berkl @ Aug 28 2013, 13:47) *
Но вот из Эклипса компильнуть не получается. Линкер не видит библиотечные функции,
хотя в modbus.h они присутствуют. Почему не видит ? Собственно тестовый проектик:


Скорее всего Вы не указали в Eclipse пути к библиотекам, не входящим в тулчейн. По работе с Eclipse есть отдельный разрел в форуме.
IMHO, лучше использовать makefile и при работе с Eclipse. Можно выбрать соответстующий вид проекта и собирать как в Eclipse, так и из командной строки. У Вас, судя по всему, уже есть необходимый makefile из примера.
Canis Dirus
Цитата(berkl @ Aug 27 2013, 17:56) *
Непонятно также что значит Stable release is libmodbus v3.0.4 (2013-05-08) и Development release is libmodbus v3.1.0 (2012-06-22), вот здесь http://libmodbus.org/download/. Мне та какой релиз надо ?

Да, кстати:
Код
╭─alexey@warrawoona  ~  
╰─$ apt-cache search modbus
collectd-core - statistics collection and monitoring daemon (core system)
libmodbus-dev - development files for the Modbus protocol library
libmodbus5 - library for the Modbus protocol
python-pymodbus - full Modbus protocol implementation


Это debian unstable, в убунте эта библиотека тоже никуда не делась
berkl
Цитата(mdmitry @ Aug 28 2013, 15:12) *
Скорее всего Вы не указали в Eclipse пути к библиотекам, не входящим в тулчейн. По работе с Eclipse есть отдельный разрел в форуме.
IMHO, лучше использовать makefile и при работе с Eclipse. Можно выбрать соответстующий вид проекта и собирать как в Eclipse, так и из командной строки. У Вас, судя по всему, уже есть необходимый makefile из примера.


Путь к библиотеке есть, на скриншоте видно gcc обращается к libmodbus.so по прописанному пути, но не находит в ней нужных для компиляции функций 05.gif . В makefile соваться неумелыми ручками пока не охота, пускай Эклипс с ним возится. Пока...
berkl
Допускаю, что не компилируется в Эклипсе из-за того что ему не дал необходимые опции компилятора и компоновщика.

Взял команду "gcc ....." из библиотечного примера и переделал под себя. Компилируется.
Вот собственно команда:

gcc mb_test.c -o mbtest `pkg-config --libs --cflags libmodbus`

Здесь видно, что компилятор берет информацию о местонахождении библиотеки libmodbus и её заголовочных файлов из libmodbus.pc файла, он в папке /usr/local/lib. Также в .pc файле мы найдем дополнительные опции компилятора и компоновщика.

вот содержимое моего .pc файла:

prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: modbus
Description: Modbus library
Version: 3.0.4
Libs: -L${libdir} -lmodbus
Cflags: -I${includedir}/modbus

Теперь поправьте меня если я не прав.
Понятно, что моему эклипсу содержимое файла libmodbus.pc никто не показывал, поэтому путь к библиотеке мы указываем в настройках проекта (Project-> Properies-> Paths and Symbols-> Library Paths-> "/usr/local/lib"), а заголовочный файл указываем в исходнике ( #include <modbus/modbus.h> ). Но остаются дополнительные опции компилятора и линкера, они должны быть тоже прописаны в настройках эклипса. Если я прав, то вопрос: как это сделать в этом, конкретном примере ?
Вопрос может не совсем к этой ветке относится, но заново объяснять проблему в другой ветке будет не правильно, наверное.

Спасибо

Update.

Скомпилировалось. В опциях линкера надо указывать не только путь к либам (-L) но и собственно названия используемых библиотек (-l). Намучился по глупости, но зато поумнел трохи twak.gif

Всем Спасибо !!!
berkl
Цитата(A. Fig Lee @ Aug 27 2013, 16:07) *
Это дело распаковывается, там должен быть файл
README, может быть INSTALL.
Их читать.

Традиционный путь компиляции подобных вещей на Унихах:
$./configure
$make
$sudo make install

configure может иметь опции,
надо запускать
./configure --help
все опции напечатает


Именно это описано в README. А если надо собрать эту же библиотеку, но для использования в приложениях под какой-нибудь ARM ? Как тогда её собирать, устанавливать ?
A. Fig Lee
Цитата(berkl @ Sep 13 2013, 02:36) *
Именно это описано в README. А если надо собрать эту же библиотеку, но для использования в приложениях под какой-нибудь ARM ? Как тогда её собирать, устанавливать ?

А "под какой нибудь АРМ" с налета может не получится.
Надо иметь кросс компайлер (например, CodeSourcery) и компилить
против тех херед файлов и библиотек, которые будут на этой системе.

Не факт что там теже хедеры, например.
Но если чето широкораспостраненное, то если запустить

./configure --help

Напечатает переменные, среди коих
--target
--build
--host
вот они и определяют чего куда где и для кого строить.

Икзампл:

../../../binutils-2.23/configure --target=arm-none-eabi- --prefix=$HOME/bin --enable-interwork --enable-multilib
Tarbal
Цитата(berkl @ Sep 13 2013, 10:36) *
Именно это описано в README. А если надо собрать эту же библиотеку, но для использования в приложениях под какой-нибудь ARM ? Как тогда её собирать, устанавливать ?


Можно воспользоваться сервисом http://www.timesys.com/
Раньше они компилировали бесплатно. Не знаю если они делают это бесплатно до сих пор.

Eсли у вас нету toolchain, где все уже настроено, то будет непросто.

Во первых вам нужно установить кросс компилятор от Code Sourcery http://www.mentor.com/embedded-software/so...s/lite-edition/
Tам будет префикс типа arm-none-linux-gnueabi- ко всем необходимым программам.
У меня они называются вот так:

arm-none-linux-gnueabi-addr2line
arm-none-linux-gnueabi-ar
arm-none-linux-gnueabi-as
arm-none-linux-gnueabi-c++
arm-none-linux-gnueabi-cc
arm-none-linux-gnueabi-c++filt
arm-none-linux-gnueabi-cpp
arm-none-linux-gnueabi-ct-ng.config
arm-none-linux-gnueabi-g++
arm-none-linux-gnueabi-gcc
arm-none-linux-gnueabi-gcc-4.4.4
arm-none-linux-gnueabi-gccbug
arm-none-linux-gnueabi-gcov
arm-none-linux-gnueabi-gdb
arm-none-linux-gnueabi-gprof
arm-none-linux-gnueabi-ld
arm-none-linux-gnueabi-ldd
arm-none-linux-gnueabi-nm
arm-none-linux-gnueabi-objcopy
arm-none-linux-gnueabi-objdump
arm-none-linux-gnueabi-populate
arm-none-linux-gnueabi-ranlib
arm-none-linux-gnueabi-readelf
arm-none-linux-gnueabi-run
arm-none-linux-gnueabi-size
arm-none-linux-gnueabi-strings
arm-none-linux-gnueabi-strip



Во вторых, надо будет установить все необходимые библиотеки под ARM в какую-нибудь директорию.

В третьих создать директорию для установки результатов компиляции
И наконец в четвертых вместо ./configure вы будете вынуждены указать параметры, описывающие все вышеназванные детали. Скрипт configure имеет необходимые ключи для указания вышеперечисленного. Возможно что-то надо указать через environment variables.

Теперь, когда вам известно что надо делать, можно найти детали в интернете.

Спасибо A. Fig Lee напомнил, что еще инклюды надо поставить.
IgorKossak
Для генерации toolchain со всем окружением можно воспользоваться Buildroot. На начальном этапе освоения очень помогает. Есть хорошая документация.
Потом можно подключить полученный тулчейн к Eclipse. Здесь сказано как.
berkl
Цитата(A. Fig Lee @ Sep 13 2013, 15:45) *
А "под какой нибудь АРМ" с налета может не получится.

./configure --help

Напечатает переменные, среди коих
--target
--build
--host
вот они и определяют чего куда где и для кого строить.



Цитата(Tarbal @ Sep 13 2013, 16:12) *
Eсли у вас нету toolchain, где все уже настроено, то будет непросто.

Во первых вам нужно установить кросс компилятор от Code Sourcery

Во вторых, надо будет установить все необходимые библиотеки под ARM в какую-нибудь директорию.

В третьих создать директорию для установки результатов компиляции
И наконец в четвертых вместо ./configure вы будете вынуждены указать параметры, описывающие все вышеназванные детали. Скрипт configure имеет необходимые ключи для указания вышеперечисленного. Возможно что-то надо указать через environment variables.


Toolchain для платы есть, но не от Code Sourcery. Это- fsl-linaro-toolchain , уже стоИт.

1. Запустил "./configure --help", в описании есть ключи:

Цитата
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]


Значит для ключа host мне надо указать имя компилятора. Для теста попробовал в терминале

Цитата
./configure --host=/usr/bin/gcc


В результате получил ошибки:

Цитата
dim@dim-System-Product-Name:~/temp/libmodbus-3.0.4$ ./configure --host=/usr/bin/gcc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for /usr/bin/gcc-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... i686-pc-linux-gnu
checking host system type... Invalid configuration `/usr/bin/gcc': machine `/usr/bin/gcc' not recognized
configure: error: /bin/bash ./config.sub /usr/bin/gcc failed
dim@dim-System-Product-Name:~/temp/libmodbus-3.0.4$


Что её не устраивает ?

2. Что указывать надо для ключа build ?

В приложении то что выдал --help

Update:

Нашел, для ключа host указывается не само имя компилятора а его префикс. Если само имя компилятора указывать, то надо прописывать руками и имя линкёра и всё остальное, а-ля СС=arm-xxxx-gcc, LD=arm-xxxxx-ld.... Открыл MakeFile, созданный скриптом configure по умолчанию.Там нашел
Цитата
host = i686-pc-linux-gnu


попробовал запустить в терминале

Цитата
./configure --host=i686-pc-linux-gnu


Вроде получилось.

Что такое префикс компилятора и как его узнать ?
A. Fig Lee
Не компилятор, а архитектуру машины.
x86, например, arm.
Смотреть надо в arch директории кернела какие архитектуры поддерживаются.
Например, здесь:
http://lxr.free-electrons.com/source/arch/
Tarbal
Цитата(berkl @ Sep 19 2013, 13:42) *
Что такое префикс компилятора и как его узнать ?


На каком процессоре будет бежать программа?
Что говорит
echo $PATH


Про префикс компиллятора.
Он не имеет ничего общего с опцией префикс и указывается при компиляции. Вот такой командой я строю кернел.
make ARCH=arm CROSS_COMPILE=arm-cortexa8-linux-gnueabi- uImage

Указана архитектира ARCH= и префикс для компилятора CROSS_COMPILE=. Это значит, что будет использован компилятор arm-cortexa8-linux-gnueabi-gcc, библиотекарь arm-cortexa8-linux-gnueabi-ar и т.д..
PATH должен содержать местоположение этих компилятора, линкера, библиотекаря и т.д.. Я раньше приводил вам весь список.

Для компиляции в пользовательской моде вещи отличаются. Вот посмотрие документ:
http://landley.net/ols/ols2007/tutorial.txt
berkl
Цитата(Tarbal @ Sep 19 2013, 16:38) *
На каком процессоре будет бежать программа?
Что говорит
echo $PATH


Про префикс компиллятора.
Он не имеет ничего общего с опцией префикс и указывается при компиляции. Вот такой командой я строю кернел.
make ARCH=arm CROSS_COMPILE=arm-cortexa8-linux-gnueabi- uImage

Указана архитектира ARCH= и префикс для компилятора CROSS_COMPILE=. Это значит, что будет использован компилятор arm-cortexa8-linux-gnueabi-gcc, библиотекарь arm-cortexa8-linux-gnueabi-ar и т.д..
PATH должен содержать местоположение этих компилятора, линкера, библиотекаря и т.д.. Я раньше приводил вам весь список.

Для компиляции в пользовательской моде вещи отличаются. Вот посмотрие документ:
http://landley.net/ols/ols2007/tutorial.txt





Бежать хочется на этом http://www.variscite.com/products/system-o...-freescale-imx6

Реакция на echo $PATH:

Цитата
dim@dim-System-Product-Name:~/temp/libmodbus-3.0.4$ echo $PATH
/usr/local/fsl-linaro-toolchain/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
dim@dim-System-Product-Name:~/temp/libmodbus-3.0.4$


Файлы в toolchain:

arm-fsl-linux-gnueabi-addr2line arm-linux-gprof
arm-fsl-linux-gnueabi-ar arm-linux-ld
arm-fsl-linux-gnueabi-as arm-linux-ld.bfd
arm-fsl-linux-gnueabi-c++ arm-linux-ldd
arm-fsl-linux-gnueabi-cc arm-linux-nm
arm-fsl-linux-gnueabi-c++filt arm-linux-objcopy
arm-fsl-linux-gnueabi-cpp arm-linux-objdump
arm-fsl-linux-gnueabi-ct-ng.config arm-linux-populate
arm-fsl-linux-gnueabi-gdbtui arm-none-linux-gnueabi-addr2line
arm-fsl-linux-gnueabi-gprof arm-none-linux-gnueabi-ar
arm-fsl-linux-gnueabi-ld arm-none-linux-gnueabi-as
arm-fsl-linux-gnueabi-ld.bfd arm-none-linux-gnueabi-c++
arm-fsl-linux-gnueabi-ldd arm-none-linux-gnueabi-c++filt

так что префикс получается: arm-fsl-linux-gnueabi

Запустил
./configure --host=arm-fsl-linux-gnueabi

Во всяком случае ошибок нет и MakeFile сгенерился



Tarbal
Цитата(berkl @ Sep 19 2013, 17:11) *
Во всяком случае ошибок нет и MakeFile сгенерился


когда получите бинарник (или даже *.о файлы), то проверьте его командой file.

ls -l /usr/local/fsl-linaro-toolchain/bin
что показывает?

На этот процессор тулчейн который дает Фрискейл называется LTIB.

Он и бутлоадер и кернел и драйверы и рут файловую систему построит, установив предварительно кроскомпилятор. Он и все пакеты в правильной версии скачает

Но если ваш тулчейн работает, то не заморачивайтесь.
berkl
Tarbal, A. Fig Lee

Спасибо за поддержку a14.gif !

Сделал make и затем sudo make install

Вроде бы всё нормально, но вот хотелось бы убедится а под АРМ ли всё таки лежит у меня теперь собранная библиотека ? Как убедиться что собрал либу под нужную платформу ? Железа у меня еще нет
DASM
так хекс редактором откройте, там для писи сигнатуру видно, что то вроде i686 если не туда и не то собрали

и я бы не рекомендовал инсталяционную директорию в корне держать, замучаетесь с этими sudo
Tarbal
Цитата(berkl @ Sep 19 2013, 19:01) *
Вроде бы всё нормально, но вот хотелось бы убедится а под АРМ ли всё таки лежит у меня теперь собранная библиотека ? Как убедиться что собрал либу под нужную платформу ? Железа у меня еще нет


Я написал, но вы видимо за обилием информации пропустили.
Протестируйте при помощи команды file исполняемый файл и/или объектные файлы.

Я надеюсь вы на забыли поставить ключ --prefix. Иначе вы установите на свою инструментальную машину, а не на таргет.



Example:
$ file drivers/built-in.o
drivers/built-in.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
berkl
Цитата(DASM @ Sep 19 2013, 19:30) *
и я бы не рекомендовал инсталяционную директорию в корне держать, замучаетесь с этими sudo


Вы имеете ввиду лучше ставить библиотеки куда-нибудь в свои папки, типа в /home/my_linux_pc/ARM_libs/ а не в /usr/local/lib/?

Цитата(Tarbal @ Sep 19 2013, 19:39) *
Я написал, но вы видимо за обилием информации пропустили.
Протестируйте при помощи команды file исполняемый файл и/или объектные файлы.

Example:
$ file drivers/built-in.o
drivers/built-in.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped


Да, да вы правы, пропустил я. Вот что получилось:

dim@dim-System-Product-Name:/usr/local/lib$ file libmodbus.so.5.0.3
libmodbus.so.5.0.3: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped

Похоже всё правильно у меня cool.gif .

еще пара вопросов.
1.
Цитата
Я надеюсь вы на забыли поставить ключ --prefix. Иначе вы установите на свою инструментальную машину, а не на таргет.

Вероятно я не понял вас.--prefix указывает на нужную мне директорию установки библиотеки. Допустим:
./configure --prefix=/home/my_pc/libs/
Иначе библиотека встанет в директорию по умолчанию, что страшного? Сейчас, пока я учусь, мне главное чтоб чего та заработало....
А библиотека, она всегда стоИт на инструментальной машине. Где средства разработки установлены, там же и библиотеки должны быть, причем тут таргет ?

2.Вот вы писали в прошлом посте:
Цитата
make ARCH=arm CROSS_COMPILE=arm-cortexa8-linux-gnueabi- uImage


А зачем мэйку с командной строке указывать архитектуру и префикс компилятора? Мне казалось что требуемый компилятор, линкер и пр., всё указано в Makefile. А объектник создается ровно для той архитектуры, под которую собственно кросскомпилятор и сделан, так что не вижу смысла её (архитектуру) указывать в ком. строке. Поправьте меня, плз
Tarbal
Цитата(berkl @ Sep 20 2013, 09:25) *
1.
Вероятно я не понял вас.--prefix указывает на нужную мне директорию установки библиотеки. Допустим:
./configure --prefix=/home/my_pc/libs/
Иначе библиотека встанет в директорию по умолчанию, что страшного? Сейчас, пока я учусь, мне главное чтоб чего та заработало....
А библиотека, она всегда стоИт на инструментальной машине. Где средства разработки установлены, там же и библиотеки должны быть, причем тут таргет ?

2.Вот вы писали в прошлом посте:


А зачем мэйку с командной строке указывать архитектуру и префикс компилятора? Мне казалось что требуемый компилятор, линкер и пр., всё указано в Makefile. А объектник создается ровно для той архитектуры, под которую собственно кросскомпилятор и сделан, так что не вижу смысла её (архитектуру) указывать в ком. строке. Поправьте меня, плз

1. Если на компьютере на котором вы компилируете установлены те же исполняемые файлы или библиотеки, то они будут заменены на вновь скомпилированные. Если вы замените исполняемый файл для 386 на исполняемый файл для ARM, то вы не сможете его запустить на 386 машине. Поэтому дефолт сразу отпадает. То, на что указал DASM, если вы сделаете директорию установке внутри вашей домашней директории, то sudo писать не обязательно. Оно действительно пройдет, однако я не уверен, что не обязательно.

2. Мой пример для компиляции кернела и драйверов. Если вы компилируете апликации/библиотеки, то он вам не нужен.
Извините за усложнение вопроса не относящейся к предмету информацией.

Если вы покажете содержимое директории о котором я вас просил, то я скажу все префиксы, которые вы можете использовать для host= и заодно вы лучше поймете как оно устроено.
Victor®
Встаюлю свои 5 коп.
В Линуксе практически 0.
Есть у меня нетбук на Атоме.
Не для работы - интернет, скайп, почта, музыка, видео...
Вообщем - командировочный вариант.

Винду снес по причине жутких тормозов.
Ставил Mint, Ubunty, OpenSUSE.
На последнем (с XFCE) и остановился.
С Минтом и Убунту были проблемы с WiFI и звуком.
Малой кровью не решились. OpenSUSE с четверть пинка все работает (и очень шустро).
berkl
Tarbal, приветствую вас,

Спасибо за уточнения про --prefix


Цитата
Если вы покажете содержимое директории о котором я вас просил, то я скажу все префиксы, которые вы можете использовать для host= и заодно вы лучше поймете как оно устроено.


В приложение вставил файл с заголовками файлов в папке /usr/local/fsl-linaro-toolchain/bin. Гляньте, плз.

Пока пойду разбираться с написанием CMakeLists.txt для проекта с внешней библиотекой.

Еще раз спасибо.



Tarbal
Цитата(berkl @ Sep 23 2013, 11:02) *
Tarbal, приветствую вас,

Спасибо за уточнения про --prefix




В приложение вставил файл с заголовками файлов в папке /usr/local/fsl-linaro-toolchain/bin. Гляньте, плз.

Пока пойду разбираться с написанием CMakeLists.txt для проекта с внешней библиотекой.

Еще раз спасибо.



Значит у вас есть исполняемые файлы с префиксом arm-fsl-linux-gnueabi-
И создано два комплекта линков на них с префиксами arm-linux- arm-none-linux-gnueabi-.

По всей видимости все три префикса будут работать для вас:
arm-fsl-linux-gnueabi-
arm-linux-
arm-none-linux-gnueabi-

Я полагаю, что бывают (или сначала думали, что бывают) три разные случая, для которых нужны разные компиляторы (и остальной набор). Но в данном случае для всех трех случаев используют один и тот же компилятор.
berkl
Ещё вопросики:

1. Хочется попробовать создать проектик на базе gcc, где будет генериться лог файл, на основе каких-нибудь данных, приходящих например, с УАРТа, а сам лог файл сохранять на USB флешку. Погуглил, чё та кисло как-то, не о том всё (учат как в консоли файлы создавать и пр....) .

2. Вот допустим, есть у меня АЦП, с SPI. По идее я могу у себя в проекте сделать исходник ADC_driver.c и описать в нем все функции обращения к АЦП (настройка режимов, чтение результатов АЦП, чтение статусов и тд...), постредством драйвера SPI, уже присутствующего в моём Линуксе. Но что-то мне подсказывает, что в Линуксе так делать не кашерно.
А уж не надо ли по-честному писать линуксовый драйвер для моей ацпушки, пересобирать дистрибутив, чтоб в нем был этот драйвер? Или всё таки достаточно включить сишный исходник драйвера АЦП в мой целевой проект и всё... ?

3. Вопрос по терминологии, вероятно дурацкий. До знакомства с Линуксом, я думал что понятие "файловая система" описывает как организовано хранение данных на носителе (FAT32, extFAT.....). В линуксе есть еще "корневая файловая система" - это набор папок, входящих в любой дистрибутив линукса. Есть такая фраза: - "Файловая система монтируется к ядру". Что это значит "монтируется"? Что в данном контексте значит "файловая система"?
А флешку когда в комп вставляешь, она ведь тоже "монтируется"? Это что значит? Монтируется тоже к ядру?

Спасибо!
Tarbal
Цитата(berkl @ Oct 3 2013, 12:40) *
Ещё вопросики:

1. Хочется попробовать создать проектик на базе gcc, где будет генериться лог файл, на основе каких-нибудь данных, приходящих например, с УАРТа, а сам лог файл сохранять на USB флешку. Погуглил, чё та кисло как-то, не о том всё (учат как в консоли файлы создавать и пр....) .

2. Вот допустим, есть у меня АЦП, с SPI. По идее я могу у себя в проекте сделать исходник ADC_driver.c и описать в нем все функции обращения к АЦП (настройка режимов, чтение результатов АЦП, чтение статусов и тд...), постредством драйвера SPI, уже присутствующего в моём Линуксе. Но что-то мне подсказывает, что в Линуксе так делать не кашерно.
А уж не надо ли по-честному писать линуксовый драйвер для моей ацпушки, пересобирать дистрибутив, чтоб в нем был этот драйвер? Или всё таки достаточно включить сишный исходник драйвера АЦП в мой целевой проект и всё... ?

3. Вопрос по терминологии, вероятно дурацкий. До знакомства с Линуксом, я думал что понятие "файловая система" описывает как организовано хранение данных на носителе (FAT32, extFAT.....). В линуксе есть еще "корневая файловая система" - это набор папок, входящих в любой дистрибутив линукса. Есть такая фраза: - "Файловая система монтируется к ядру". Что это значит "монтируется"? Что в данном контексте значит "файловая система"?
А флешку когда в комп вставляешь, она ведь тоже "монтируется"? Это что значит? Монтируется тоже к ядру?

Спасибо!


1. Это язык C. Смотрите как создавать файлы. Есть куча примеров в интернете.
Ключевые слова для поиска fopen и более низкоуровневую open.
http://unixhelp.ed.ac.uk/CGI/man-cgi?open+2

2. Дело в том, что в Линуксе драйверами называются более элементарные вещи чем вы полагаете. В вашем драйвере будет сотрудничать несколько Линуксовских драйверов. Один из них существующий SPI, Другой -- драйвер вашего конкретного АЦП, который будет как бы более высокоуровневым. Он будет обращаться к SPI драйверу для доступа к рессурсам вашего железа. Есть множество примером в кернеле и если вы уточните детали, то можно будет найти какой-нибудь драйвер для наглядного пособия.


3. Корневая файловая система это обычная файловая система. В ней особенного только то, что в нужных местах лежат нужные файлы, но это уже не имеет никакого отношения к понятию файловая система. Кернел при старте монтирует ее, потом запускает скрипты (и берет конфигурацию) из мест, которые он знает (в большенстве систем /etc/inittab ключевой файл. В Убунту иначе).
То, что флешка монтируется это плаг анд плей. Это не всегда работает, но всегда можно использовать команду mount смонтировать любой диск (блоковое устройство) к система (а не к кернелу).



Полагаю если вы хотите обсудить какой-то проект, лучше созать отдельную тему. Тем кто будет искать ответы будет легче их найти.
alx2
Цитата(berkl @ Oct 3 2013, 13:40) *
1. Хочется попробовать создать проектик на базе gcc, где будет генериться лог файл, на основе каких-нибудь данных, приходящих например, с УАРТа, а сам лог файл сохранять на USB флешку.

А где вопрос? sm.gif
man syslog
man syslogd
man syslog.conf
Tarbal
Цитата(alx2 @ Oct 7 2013, 12:17) *
А где вопрос? sm.gif
man syslog
man syslogd
man syslog.conf


Кстати да.
Если вас устраивает текстовый лог, то воспользуйтесь сислогом. В программе на С есть функция записать строку в сислог, а в конфигурации сислога укажите файл куда писать эти специфические сообщения. Довольно просто и стандартно. Можно параллельно еще на удаленный компьютер посылать сообщения и там сислогом их записывать. Можно даже и не писать программу, а из скрипта посылать сообщения в сислог.

"Все уже украдено до нас" (С)
berkl
Озадачился работой таймеров в Линуксе. Погуглил, понял следующее. У компа есть микросхема таймера, при переполнении которого генерятся прерывания. Частота прерываний у линукса приблизительно 1кГц , то есть каждую миллисекунду. В промежутках между обработчиками прерываний, процессор выполняет задачи процесса, который ему подсунул в данный момент планировщик Линукса.

В обработчике прерывания, кроме всего прочего проверяются состояния созданных таймеров. Если обработчик увидит, что период того или иного таймера истек, то процессу, в котором был создан этот таймер будет послан сигнал (signal). Процесс, узнает о том что ему послан сигнал только когда дойдет очередь его выполнять. Если всё так то вопрос. Допустим, я создал таймер, который должен генерить сигнал каждые 50мс. Я могу быть уверенным, что этот сигнал будет послан процессу ровно через 50 мс (неточность системного тика и время выполнения самого обработчика опустим). Но как оценить когда мой процесс узнает что сигнал ему послан и начнется выполнение функции, привязанной к этому сигналу ?


Может я чё та не правильно понял, поправьте если что плз.


Спасибо.

Upd: Вот тут http://otvet.mail.ru/question/86575120 товарищ утверждает что квант времени выделяемый на каждый процесс в Линуксе = 1/300с Это 3.3мс! То есть если у меня в Линуксе крутятся последовательно 10 процессов то я дождусь начала выполнения функции, связанной с выставленным сигналом через 50+(10*3.3) = 83мс, вместо 50 !?

Upd2: проверил таймер с периодом 50мс. Всё четко отрабатывает. Значит я чего то не понимаю, как оно устроено. Либо товарищ ошибся с квантом времени процесса
Tarbal
Цитата(berkl @ Oct 17 2013, 09:35) *
Озадачился работой таймеров в Линуксе. Погуглил, понял следующее. У компа есть микросхема таймера, при переполнении которого генерятся прерывания. Частота прерываний у линукса приблизительно 1кГц , то есть каждую миллисекунду. В промежутках между обработчиками прерываний, процессор выполняет задачи процесса, который ему подсунул в данный момент планировщик Линукса.

В обработчике прерывания, кроме всего прочего проверяются состояния созданных таймеров. Если обработчик увидит, что период того или иного таймера истек, то процессу, в котором был создан этот таймер будет послан сигнал (signal). Процесс, узнает о том что ему послан сигнал только когда дойдет очередь его выполнять. Если всё так то вопрос. Допустим, я создал таймер, который должен генерить сигнал каждые 50мс. Я могу быть уверенным, что этот сигнал будет послан процессу ровно через 50 мс (неточность системного тика и время выполнения самого обработчика опустим). Но как оценить когда мой процесс узнает что сигнал ему послан и начнется выполнение функции, привязанной к этому сигналу ?


Может я чё та не правильно понял, поправьте если что плз.


Спасибо.

Upd: Вот тут http://otvet.mail.ru/question/86575120 товарищ утверждает что квант времени выделяемый на каждый процесс в Линуксе = 1/300с Это 3.3мс! То есть если у меня в Линуксе крутятся последовательно 10 процессов то я дождусь начала выполнения функции, связанной с выставленным сигналом через 50+(10*3.3) = 83мс, вместо 50 !?

Upd2: проверил таймер с периодом 50мс. Всё четко отрабатывает. Значит я чего то не понимаю, как оно устроено. Либо товарищ ошибся с квантом времени процесса


В Линуксе столько разных концепций времени. Насколько я знаю базовой единицей являются jiffies. Оно в каждой конкретной системе калибруется на время. Есть системная константа, показывающая сколько jiffies в миллисекунде. Сдается мне что нет определенного периода вызова прерывания системного таймера. Так что может быть и 1 мС и 5мС и 10мС.

Я полагаю, что Линукс не настолько deterministic, что можно гарантировать время, через которое процесс начнет работу. Можно, например, запустить задачу с реал тайм приоритетом, что пока она активна никто не получит рессурса процессора.

Полагаю вам следует создавать процессы с реал-тайм приоритетом

http://stackoverflow.com/questions/8887531...iority-in-linux

http://www.cyberciti.biz/faq/howto-set-rea...iority-process/

http://www.linuxjournal.com/magazine/real-...ernel-scheduler
vshemm
Прежде чем рассматривать таймеры, надо сделать несколько определений.

Шедулер (планировщик) - это та часть ядра, которая отвечает за манипулирование списками тредов (нитей) в зависимости от их приоритета, политик планирования и пр.
Свитчер - сущность, которая переключает контексты тредов, грубо говоря прозрачно для пользователя запускает один тред вместо другого (на данном цпу).

Так вот, выполнение шедулера/свитчера может происходить по многим причинам, как-то: окончание кванта времени треда, засыпание треда в ядре, возникновение некоторых событий, которое ждет тред, фаза луны (при определенной политике планирования) и пр. Тики системного таймера - один из источников таких событий, но не единственный. Более того, его вообще может не быть (tickless system, в линуксе CONFIG_NO_HZ*).

Как я понял, вы используете юзермодные POSIX таймеры (timer_create() etc) с доставкой сигнала по таймауту. При этом происходит примерно следующее: заводится ядерный таймер (не обязательно хардварный), по таймауту которого происходит прерывание. Обработчик этого прерывания посылает сигнал процессу, т.е. выбирает нужную нить и "будит" ее, после чего с ней разбирается шедулер в следующей точке решедулинга (например, при выходе из прерывания). Далее, нить в зависимости от текущего состояния, политики планирования, приоритета и пр. может пойти на выполнение - это решает планировщик. Ну и само переключение потом делает свитчер, тоже в определенный момент, не обязательно сразу.

В вашем примере 50мс выдерживались потому, что не было сильной загрузки, т.е. большинство тредов спали, вот ваш обработчик сразу и выполнился. Попробуйте запустить while (1); с высоким приоритетом (а лучше с RT-приоритетом <100) - времена поплывут.

Другие моменты, которые могут влиять на джиттер, связаны с доставкой сигналов:
1. POSIX требует, чтобы сигналы от таймеров и прочих io completion не терялись, поэтому используются так называемые realtime signals. Это означает, что сигналы складываются в хитрую приоретизированную очередь и доставляются в порядке приоритета (а внутри одного приоритета - в FIFO порядке).
2. Сигналы могут быть заблокированы.
3. Сигналы посылаются процессу, а выбор конкретной нити, которая их будет исполнять (единица планирования - нить) весьма нетривиален (хотя можно послать сигнал конкретной нити...).
4. Если выбранная нить мигрировала на другой CPU, отличный от того где выполняется прерывание от таймера, - пошлется IPI тому CPU на решедулинг, со всеми вытекающими.
И это только то, что я с ходу вспомнил.

Поэтому все стандарты (да и здравый смысл) говорят, что таймеры гарантируют исполнение обработчиков через время _не меньшее_ таймаута. Более строгой гарантии (верхней границы) вам никто не даст.

И еще, при гуглении не читайте всякие ответы-мейл-ру. Википедия тоже не очень достоверна. Stack Exchange получше, но проигрывает статьям на lkml и официальной документации. А самый надежный источник - исходные коды + комментарии в них + common sense sm.gif
berkl
Спасибо за ссылочки, поглядаю.

Цитата(Tarbal @ Oct 17 2013, 21:30) *
Сдается мне что нет определенного периода вызова прерывания системного таймера. Так что может быть и 1 мС и 5мС и 10мС.

Я полагаю, что Линукс не настолько deterministic, что можно гарантировать время, через которое процесс начнет работу. Можно, например, запустить задачу с реал тайм приоритетом, что пока она активна никто не получит рессурса процессора.



Вот тут http://rus-linux.net/MyLDP/BOOKS/Moduli-ya...-mod-06-10.html товарищ считает по другому:

Цитата
Ядро следит за течением времени с помощью прерываний системного таймера. Прерывания таймера генерируются аппаратно через постоянные интервалы системным таймером; этот интервал программируется во время загрузки Linux записью соответствующего коэффициента в аппаратный счётчик-делитель. Делается это в соответствии со одной из самых фундаментальных констант ядра — константы периода компиляции (определённой директивой #defined) с именем HZ (tick rate). Значение этой константы, вообще то говоря, является архитектурно-зависимой величиной, определено оно в <linux/param.h>


Цитата
Но для большинства платформ для ядра 2.6 выбраны значения HZ=1000, что соответствует периоду следования системных тиков в 1 миллисекунду


Из сказанного видно, что период сработки системного прерывания (а вместе с ним и обработчика прерывания) жестко детерминирован и доступен для настройки. В контексте обработчика системного прерывания, кроме всего прочего, проверяется и не истекло ли выделенное время (квант) выполнения текущего процесса. Если время процесса истекло то прямо в обработчике прерывания запускается следующий процесс, текущий останавливается. Так что тут тоже всё детерминировано по времени. В чем же тогда недетерминированность Линукса? Я не знаю, но допускаю, что в том что не известно когда будет выполняться процесс у которого возникло какое-то событие. Взять хоть тот же сигнал от таймера в нашем процессе: таймер переполнился, ядро об этом узнает сразу, но процесс узнает об этом только когда подгрузится контекст этого процесса. А когда он подгрузится, фиг знает... В этом мне видится "нереальность времени" Линукса.
Tarbal
Устраню некоторую неопределенность во фразе:
"Сдается мне что нет определенного периода вызова прерывания системного таймера. Так что может быть и 1 мС и 5мС и 10мС."

Если в системе интервал 1 миллисекунда, то он всегда будет равен одной миллисекунде.
Если интервал в системе 10 миллисекунд, то он всегда будет 10 мС. Каким интервал является в каждой конкретной системе заранее сказать невозможно. Он может меняться от системы к системе.

Цитата:
"Но для большинства платформ для ядра 2.6 выбраны значения HZ=1000, что соответствует периоду следования системных тиков в 1 миллисекунду"
подтверждает мои слова.
vshemm
Да забудьте вы про системный тик sm.gif Это всего лишь дополнительный периодический источник событий. Его может вообще не быть. В линуксе такая опция появилась в 2.6.16-17 ядре, т.е. много лет назад. Не говоря про другие системы.

EDIT: вот неплохая отправная точка для гугления http://stackoverflow.com/questions/9775042...in-linux-kernel
berkl

Спасибо за ответы, буду разбераться 05.gif

vshemm
Цитата(berkl @ Oct 17 2013, 22:40) *
...
Вот тут http://rus-linux.net/MyLDP/BOOKS/Moduli-ya...-mod-06-10.html товарищ считает по другому:
...


Этот товарищ - Олег Цилюрик, на данном (и не только на данном) форуме известен под ником olej. ЕМНИП. Со всеми вытекающими.
berkl
Цитата(vshemm @ Oct 17 2013, 22:13) *
Так вот, выполнение шедулера/свитчера может происходить по многим причинам, как-то: окончание кванта времени треда, засыпание треда в ядре, возникновение некоторых событий, которое ждет тред, фаза луны (при определенной политике планирования) и пр. Тики системного таймера - один из источников таких событий, но не единственный. Более того, его вообще может не быть (tickless system, в линуксе CONFIG_NO_HZ*).


Про tickless system я до конца не понял, но кажется так: допустим, планировщик решил, что ближайшие n секунд не запланировано к исполнению ни одного процесса значит надо усыпить процессор. Это не значит что системные прерывания (с частотой HZ) перестают генерится. Нет, они генерятся и проц просыпается всякий раз когда это происходит. Но почти сразу засыпает снова, определив что пока заняться нечем. Решил проверить как оно. Накидал примерчик с одним posix таймером, который истекает каждую секунду:

Код
#include <signal.h>
#include <time.h>

#define INTERVAL 1000000
void main(void)
{
  tmr_init_();

  while(1);
}

void alarm_wakeup (void)
{
   struct itimerval tout_val;

tout_val.it_interval.tv_sec = 0;
  tout_val.it_interval.tv_usec = 0;
   tout_val.it_value.tv_sec = 0;
   tout_val.it_value.tv_usec = INTERVAL;

   setitimer(ITIMER_REAL, &tout_val,0);

}

void tmr_init_(void)
{
      struct itimerval tout_val;

  tout_val.it_interval.tv_sec = 0;
  tout_val.it_interval.tv_usec = 0;
  tout_val.it_value.tv_sec = 0;  
  tout_val.it_value.tv_usec = INTERVAL;
  setitimer(ITIMER_REAL, &tout_val,0);

signal(SIGALRM,alarm_wakeup);
}


выполнил dim@dim-System-Product-Name:~$ top

Процессор не засыпает когда крутится эта программка, мешает уснуть while(1); наверное . Более того процесс создает нагрузку 100 и более(!) процентов! Как сделать так чтобы процессор спал, а не выполнял постоянно while(1); , впустую грея воздух ?


Цитата(vshemm @ Oct 17 2013, 22:13) *
Как я понял, вы используете юзермодные POSIX таймеры (timer_create() etc) с доставкой сигнала по таймауту. При этом происходит примерно следующее: заводится ядерный таймер (не обязательно хардварный), по таймауту которого происходит прерывание. Обработчик этого прерывания посылает сигнал процессу, т.е. выбирает нужную нить и "будит" ее, после чего с ней разбирается шедулер в следующей точке решедулинга (например, при выходе из прерывания). Далее, нить в зависимости от текущего состояния, политики планирования, приоритета и пр. может пойти на выполнение - это решает планировщик. Ну и само переключение потом делает свитчер, тоже в определенный момент, не обязательно сразу.


Отчасти не соглашусь. Хардварный таймер наверное вообще завести нельзя. Все, чем располагает ядро - это внешний сигнал прерывания который приходит он куда-то с предопределенной периодичностью (HZ). Откуда именно можно узнать набрав:

dim@dim-System-Product-Name:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
В моем случае это tsc - Time Stamp Counter.

Доступных источников периодических прерываний может быть несколько, у меня их 3:
dim@dim-System-Product-Name:~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

Говорить " ...таймер (не обязательно хардварный), по таймауту которого происходит прерывание..." наверное неправильно. Прерывание (которое действительно прерывает, приостанавливает работу центрально процессора) присуще только хардварному таймеру, с его хардварным приоритетом и адресом в таблице векторов. Мне думается, когда истекает линуксовый таймер, ядро выставляет сигнал, флаг (вобщем какую та переменную) которая информирует процесс (или нить) об этом событии. Но назвать это прерыванием нельзя.
Остальное сказанное мне понятно и я согласен.

Спасибо.
Tarbal
Чтобы процессор заснул, надо сделать соответствующий системный вызов. Типа попросить занятый семафор. Их много. Вам подойдет sleep:
Для скриптов
http://en.wikipedia.org/wiki/Sleep_(Unix)
Для С
http://linux.die.net/man/3/sleep

Хардверный таймер завести можно. Однако таймеры ОС работают от одного и того же системного таймера, который инициализирован при старте кернела.
berkl
Цитата(Tarbal @ Oct 21 2013, 18:16) *
Хардверный таймер завести можно. Однако таймеры ОС работают от одного и того же системного таймера, который инициализирован при старте кернела.


Согласен, таймеры ОС работают от одного системного таймера. Но системный таймер это ведь программный таймер, нет ?

Цитата
An incrementing counter representing system «uptime» in ticks - or the number of timer interrupts since boot.


А раз так, то как аппаратный таймер может тактоваться от программного ? Аппаратному таймеру нужен перепад напряжение на счётном входе....

Думается, хардвар заканчивается на обработчике прерывания do_timer(), железных таймеров нет. В do_timer() происходит jiffies++; ну а другие таймеры уже дальше на базе этого рабьотают
Tarbal
Цитата(berkl @ Oct 21 2013, 20:17) *
Согласен, таймеры ОС работают от одного системного таймера. Но системный таймер это ведь программный таймер, нет ?



А раз так, то как аппаратный таймер может тактоваться от программного ? Аппаратному таймеру нужен перепад напряжение на счётном входе....

Думается, хардвар заканчивается на обработчике прерывания do_timer(), железных таймеров нет. В do_timer() происходит jiffies++; ну а другие таймеры уже дальше на базе этого рабьотают


Как програмный таймер может измерять время? Кто-то должен инициировать прерывание через равные промежутки времени. Этим и занимается хардверный таймер.
Возникла путаница с терминологией. В процессоре (SOC) стоит несколько хардверных таймеров, которые можно использовать если надо. Я о них говорил. Один из них занят системой для измерения времени и все системные времена опираются на него.
berkl
Цитата(Tarbal @ Oct 21 2013, 21:23) *
Возникла путаница с терминологией.


Да, с терминологией путаница.

Цитата(Tarbal @ Oct 21 2013, 21:23) *
Как програмный таймер может измерять время? Кто-то должен инициировать прерывание через равные промежутки времени. Этим и занимается хардверный таймер.


То есть системный таймер (он же хардверный) это микросхема. ОК. А счётчик считающий jiffies как называется ?

Цитата(Tarbal @ Oct 21 2013, 21:23) *
В процессоре (SOC) стоит несколько хардверных таймеров, которые можно использовать если надо. Я о них говорил. Один из них занят системой для измерения времени и все системные времена опираются на него.


А если не SoC а обычный пентиум (я веду рассуждение в контексте этого случая)?
Tarbal
Цитата(berkl @ Oct 21 2013, 22:04) *
То есть системный таймер (он же хардверный) это микросхема. ОК. А счётчик считающий jiffies как называется ?

Есть один системный хардвер таймер и все временнЫе службы и системы измерения времени Linux равняются на него него. Думаю и jiffies тоже.

Цитата(berkl @ Oct 21 2013, 22:04) *
А если не SoC а обычный пентиум (я веду рассуждение в контексте этого случая)?


Раньше в PC ставили чип таймера 8053 или его производные. В SOC все внутри. Ставят штук 10 таймеров, в каждом capture/compare/PWM.
mov
Сразу прошу извинения у сообщества за избитый вопрос .

Какой из Linux-ов рекомендуете поставить начинающему для работы с САПР(электроника) , программирования МК , работы в сети ?

Мнения в сети можно читать годами , а толку никакого.

Устойчивость работы для начала ,наверное, очень важна.

xor.kruger
Debian. Мое мнение, что если для работы с железом, с учетом стабильности дистрибутива и для новичка лучше просто нету.
Самые большие репозитории - это тоже Debian.
Ну а по стабильности, конкурентов ну просто нет!
Tarbal
Цитата(xor.kruger @ Oct 22 2013, 11:43) *
Debian. Мое мнение, что если для работы с железом, с учетом стабильности дистрибутива и для новичка лучше просто нету.
Самые большие репозитории - это тоже Debian.
Ну а по стабильности, конкурентов ну просто нет!


Зато на Убунту больше информации в интернете.
И тот же Дебиан внутри.
A. Fig Lee
Цитата(Tarbal @ Oct 22 2013, 14:43) *
Зато на Убунту больше информации в интернете.
И тот же Дебиан внутри.

+ 1
mdmitry
Если нужна хорошая совместимость с разными программами (MATLAB, xilinx ise, altera quartus и т.д.), то стоит присмотреться к дистрибутивам на основе Red Hat Enterprise Linux (RHEL), CentOs, scientific linux, scientific linux cyrillic edition. На scientific linux cyrillic edition у меня ISE встала без проблем, при установке на Debian потребовались танцы при подключении программатора. Хотя сейчас производители стали и Ubuntu в качестве системы указывать в списке поддерживаемых.
DASM
Для работы с САПР советую ставить Виндовс wink.gif А на деле оказался в печальной ситуации с двумя компами, ибо ни виртуалка, ни мультибут — не панацея. Ставьте Убунту 13, поддержка нормальная, а секс от установки всяких квартусов заменит вам курс молодого бойца. Хотя тот же Матлаб встал без запинки.
xor.kruger
Цитата(mdmitry @ Oct 22 2013, 22:46) *
Если нужна хорошая совместимость с разными программами (MATLAB, xilinx ise, altera quartus и т.д.), то стоит присмотреться к дистрибутивам на основе Red Hat Enterprise Linux (RHEL), CentOs, scientific linux, scientific linux cyrillic edition. На scientific linux cyrillic edition у меня ISE встала без проблем, при установке на Debian потребовались танцы при подключении программатора. Хотя сейчас производители стали и Ubuntu в качестве системы указывать в списке поддерживаемых.

Работаю в Debian c Xilinx ISE и иже с ними уже более 4 лет. Все отлично. Да, иногда приходится плясать с бубном, но это не из-за дистрибутива, а из-за индусских кодописателей и их скриптов, которые заточены под определенный дистр.
Цитата
Зато на Убунту больше информации в интернете.

Мне кажется информацию нужно черпать с официальных источников.

ЗЫ: Вот все кричат Ubuntu, Ubuntu, а какие реальные преимущества, например, перед тем же Debian ?
sasamy
Если нужен Red Hat подобный дистрибутив (например для Cadence или ISE) - сейчас есть бесплатная альтернатива ентерпрайзного уровня
http://ru.wikipedia.org/wiki/Oracle_Linux

а вообще - лучше Ubuntu 10.04 ничего нет sm.gif

Цитата
Ubuntu, а какие реальные преимущества, например, перед тем же Debian ?


PPA, дизайн, быстрый поиск решений проблем, лучшая поддержка чем у дебиана от сторонних компаний - практически все тестируется на Ubuntu.
berkl
Цитата(xor.kruger @ Oct 23 2013, 10:20) *
ЗЫ: Вот все кричат Ubuntu, Ubuntu, а какие реальные преимущества, например, перед тем же Debian ?



Мне повезло, не пришлось решать этот душераздирающий вопрос. Выбранный мною процессорный модуль уже идет с полноценным портом Убунты. Соответственно, всё что написано на инструментальном компе с Убунту, будет работать и на этом МК (после кросскомпиляции сессно)
Micrick
Такая вот закавыка для нуба:
Поставил Ubuntu12.04 на VMware Player. Все хорошо работало. После установки Эклипса из Software Center пропала сеть.
Мазила не может найти сервера и т.д.
На команду:
sudo lshw -c network
терминал отвечает:
Цитата
*-network DISABLED
description: Ethernet interface
product: 79c970 [PCnet32 LANCE]
vendor: Hynix Semiconductor (Hyundai Electronics)
.......................
и т.д.


Правильно понимаю, что, видимо, в этом *-network DISABLED проблема и есть?!
Как все это можно решить?
В принципе, создал уже другую машину- там пока все нормально, но интересует решение, как таковое.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.