Easyelectronics.ru

Я так и не понял что двигало разработчиками при выборе ethernet. Похоже просто ткнули пальцем в небо и решили.

А если будешь делать ту бороду которую нарисовал - то проще каждому чипу stm32 добавить чип ethernet switch на 6 портов и тогда можно соединять всех со всеми.

Вполне возможно...


Наверно так и сделаю, ибо "приказ есть приказ, знает каждый из нас". Но CAN вообще заинтересовал, сижу изучаю.

Тогда если предложишь своё(например CAN) с четким обоснованием - легко согласятся изменить :)


Это будет дорого, ethernet предназначен для передачи большого количества данных порядка 10-100 мегабит, а у тебя как я понял потока в 10 килобит хватит.

больше похоже, что разработчики такие же "разработчики", каков топикстартер программист микроконтроллеров (не в обиду ему, конечно, но он сам сказал, что ничего в контроллерах не шарит). им сказали сделать сеть - прикинули и решили, сеть это Ethernet, делать будем Ethernet. Потому что разницы между 5 PHY Ethernet на устройстве и 5 CAN - никакой. Ethernet это та же общая шина, только кадр канального уровня другой и коллизии не разрешаются, а сбрасываются

Если хотите 5 эзернетов, ставьте 5 PHY и 5 STM32F107. Хотя так не делают.

Чип Ethernet switch это микросхема или целый блок? Что-то типа такого: http://www.chipfind.ru/datasheet/html/i ... 6996l.html ?


Да они как раз хорошие разработчики, но в области силовой электроники, а с передачей данных столкнулись впервые. Товарищ, который был в теме слинял в Москву на немного другую зп, и дело было повешено на меня :)


Я пока толком в нём не разобрался, чтобы чётко обосновать :)


Это будет жуть кошмарная :( Не думаю, что на это согласятся, ибо цена зашкалит уже явно.

Да, только нужен чип который умеет разруливать петли. Честно говоря я уже не помню как это называется.

Во-первых надо четко прописать что хотите сделать, фактически написать для себя ТЗ. А начать надо с вопросов - при каких условиях надо получить надежную работу? Что такое надежная работа? и т.д. Потому что ТЗ - это 50% работы.
И только потом прикладывать это ТЗ к различным вариантам реализации.

золотые слова

Немного разобрались с сетью и протоколами. Объёмы не критичны, но скорость нужна 50+ МБит, так что юзать будем всё-таки Ethernet100. В ходе дебатов выбрали два приоритетных варианта:
1) Бороду из 100500 проводов - каждый с каждым
2) Схему с общей шиной. Здесь вопрос: как это лучше осуществить и возможно ли резервирование? например, ещё один кабель. При разрыве основного - переключаемся на резервный,например.

Ethernet не подразумевает общей шины, читайте и думайте глубже. Для примера посмотрите как соединяются компьютеры в сеть и что будет если им устроить общую шину.

Угу... Ethernet10 не подходит, а 100 не кушает общую шину. Остаётся либо звезда с маршрутизатором *забрили за ненадёжностью*, или всё та же борода. С маршрутизацией только там сдохнуть можно + моток некислый.
Весь гемор из -за требуемой надёжности - сеть должна работать вплоть дло выгорания последнего устройства.
Есть ещё идеи? :)

А почему вы не смотрите в сторону всякого вайфая? дорого?

(Трёт глазки, пытаясь осмыслить увиденное) Ну да, толстый кабель с вампирчиками, и тонкий с тройничками - нам в своё время приснились. Наверное, клея перенюхали. А производителям приснились стандарты 10base5, 10base2, csma/cd.
ЗЫ: Тот факт, что шину перенесли вовнутрь хаба - за отмазон не считается.

Устройства преднезначены для работы в условиях высокого уровня различных помех, так что вайфай тут никак вообще не подходит.


А можно подробнее? Насколько я понял из нарытой инфы, Ethernet100 не поддерживает общую шину, а Ethernet10 нам мало *надо скорость 50 Мбит*

С удовольствием посмотрю на 100Base-T на коаксиале.

есть у меня подозрение, что STM32 поток в 50мбит просто не будет успевать переваривать

Эзернет всегда был, и поныне остаётся шиной. Ведь не кольцо же он. Тот факт, что сама шина упрятана вовнутрь коммутатора, (чтобы избавиться от коллизионных доменов) ни на что не влияет.

Чую идей кроме пресловутой бороды не будет :( Попытаюсь, правда, всё же на звезду на маршрутизаторе уломать, а то писать прошивку маршрутизатора для центрального устройства - я сдохну.

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

А как? :) Я подумывал о резервировании. Есть возможность поставить дублирующий маршрутизатор?

Кгхм.... а ты не ошибся? мне кажется stm32f107 на такой скорости будет только через DMA лить данные в память и больше ничего не сможет делать, а если учесть что с по 50+ с каждого клиента, т.е. общая скорость 5*50=250Мбит.... что-то здесь не так. Или в архитектуре косяк, или с циферками ошибка.

Уточню :) Если бы у меня сходу была вся инфа - было бы проще, но я её чуть не клещами извлекать вынужден :(

Зачем её писать? Можно чип коммутатора поставить, он сам всё разрулит. Хотя проще купить восьмипортовый длинк за $20, и всё.
Можно взять два коммутатора, и на каждое устройство привесить два интерфейса. Таким образом, каждое будет подключаться к сети двумя кабелями.

Это микросхема или полноценный маршрутизатор? Если можно, ссылочку на нечто подобное.


В смысле два интерфейса? То есть свич на 2 выхода?
Вопрос возникает, как сделать,чтобы сеть висела на первом маршрутизаторе, а при его поломке - перебрасывалась на второй. Я думаю реализовать это, связав маршрутизаторы и при потере отклика от основного - включать резервный... Только пока даже близко не придумал как это сделать :)

Для начала определитесь с терминологией. Зачем вам маршрутизатор??? Какая маршрутизация возможна в одной сети из шести устройств? Маршрутизация бывает только между разными сетями.
Вам нужен был бы простой концентратор, но их уже сто лет не делают, а делают коммутаторы (switch). Вот вам адресок производителя чипов на коммутаторы, смотрите сами. http://www.icplus.com.tw/product.htm
У вас для этого у PHY интерфейса, должен быть выход индикатора линка. Вот где он активен, туда и кидать пакеты, предпочтение отдавать первому. Соединить оба коммутатора можно. Получать пакеты с обоих PHY равноценно, каждый пакет оборудовать ID, повторный пакет с тем же ID игнорировать. Можно в софт добавить периодический пинг, чтобы делать суждение о работоспособности какого-либо интерфейса.