mantech

А что мне до его имени, к LVDS я подключаю почти любую матрицу и тащусь А к этому что я подключу?? Очередной сериализатор-конвертер чего-то во что-то?? Зачем мне это? ЗЫ. Да были матрицы с 5 каналами, но во всех процах, где я видел LVDS можно было выбирать режим, сейчас уже все устаканилось, есть одноканальные до 1024х768 и 2х канальные, они взаимозаменяемы в своей группе и работают на "ура"... А чего ждать-то? Берете ситару, имх или вибрид, там все уже есть Ибо такие частоты в М-серии не задумывались, это простые камешки с низким потреблением...

Вообщем, лучшеб сделали стандартный 18битный LVDS...

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

Стандартные мониторы?? Так и захотелось посмотреть, как этот сверхбыстрый камень будет отрисовывать стандартное разрешение, хотябы 720p

Просвятите, это зачем вообще?? Это какое-то удаленное управление или просто лень писать гуй для локального пульта управления?

Значит электроника для него не призвание, про себя скажу - с 14 лет однозначно решил, что пойду на электронику и программирование, и пофиг, что сложно, все равно в жизни без этого себя не вижу. Да было сложно, после вуза платили копейки, потом нашел нормальную работу, и затем свое дело. И всегда специфика была связана с проектированием и программированием МК.

Может делать как в некоторых западных вузах, группы для одаренных, прошедших собеседование и показавших на деле, что они хотят изучать профильные предметы, и группу для всех остальных, без которых придется закрывать вуз... Ну и конечно, возможность переходить в "одаренную" группу для тех, кто в последствии осознал, что эти знания дадут путь к успеху...

Почему я это написал, просто от того, как объясняет препод, очень многое зависит. Пример из своей учебы, был у нас препод, который на своих лекциях, по предмету "микропроцессорная техника" начинал просто зачитывать даташиты, перечислять регистры и т.п. - итог посещаемость 25-30%, включая тех, кто играл в крестики-нолики. Причем, сам по себе этот препод был очень хорошо "шарящим" в предмете. И другой, гораздо менее интересный предмет - ЭМС - препод, который преподавал, постоянно приводил примеры своей практики, "из жизни", с юмором и т.д. - итог посещаемость 80-85%, кол-во пятерок в 3 раза выше, хоть и неинтересный предмет. Из всего этого, я тогда вынес одно - преподавать - это талант, которым я, к сожалению, не обладаю, но так здорово учится у талантливого препода.

На этот вопрос студент должен ответить, когда выбирал специальность связаную с микропроцессорной техникой. Ибо все это надо! Т.к. на "голом" процессоре, действительно, можно только моргать светодиодом, а если что-то посложнее - тут только изучать аппаратные особенности. Другое дело, там нет никаких сверхсложностей, если препод умеет наглядно объяснять и сам понимает суть вопроса... Согласен, разве, что с вождением не стал бы сравнивать, там больше на автоматизме, а вот с любой другой специальностью, требующей минимума творческого подхода -да. И нужно желание и терпение, сразу не получается, если плюнет, не попробует снова - значит неправильно выбрал специальность. По мне - на такие специальности должны проводиться собеседования, чтоб понять, есть потенциал или просто хочет получить корочки... Да с удовольствием бы смотрели, НО где их купить, причем штучно, не от 100, вменяемые цены, примеры программ, SDK, отладочные платы, программаторы и т.п. все это лишние затраты и сложности... А теперь еще представте, что надо делать сложную программу, сжатые сроки... Вот и выбираем то, что проще в освоении.

Хм, мигать светодиодом нужно начинать с авр, армы уже либо для продвинутых, либо на следующий семестр обучения... Ну и асм тоже лучше изучать с авр, с армами все-таки упор нужно делать на си, асм преподавать факультативно, чтоб имели представление и отличия в командах для 8 и 32битных систем. В таком случае инициализация портов не станет проблемой, другое дело, что там есть еще кэш память и клоки, которые тоже нужно запускать, в отличии от авр...

Я же говорю, что начать надо с 8биток, но с перспктивой 32хбитных. У нас в политехе про мк вообще заикнулись вскользь, но это меня не испортило Как-то мне сказали, что вуз не учит самим предметам, как таковое, он должен учить учиться, развить творческий поиск и заинтересовать в предмете, тогда человек сам начнет расширять пределы своего познания... А что может расширить сухое перечитывание регистров проца и лабы по тем темам, которые не проходили на лекциях?? Только отвращение к предмету. Я спросил своего однокурсника, когда защищал диплом, как он относится к курсу микропроцессорной техники, на что получил "прошел и забыл, как кошмарный сон!" И какой из него будет специалист?? Это однозначно за! без знаний железа и логики за мк нечего даже браться... Да, частным, НО для лаб. работ нужно что-то выбирать, и если так, то уж лучше то, что востребовано сегодняшней ситуацией, логично?? А так уж повелось, что доминирующее положение на рынке, ввиду объективных причин, заняли именно risc процессоры, их и нужно изучать углубленно, а cisc изучить только как факультатив. Хорошая архитектура, знаю, но теперь это только теория... А практику, лично я, проходил бы на авр, т.к. считаю его одним из лучших и простых процов 8биток. Теория это хорошо, но когда сделаешь программу и железка замигает лампочками, закрутится мотор и индикторы будут показывать что нужно - вот тогда получаешь удовлетворение, а кто не получает - тот не "настоящий" технарь ;)

Тогда добро пожаловать в каменный век, да, еще не забудте 8051 с УФППЗУ, только хардкор!!

Дак уж чего - давайте с логики начнем, потом счетчики с пзу для посл. выборки команд, 4х битные процессоры и т.д. По моему это дурдом, Эти процы и мк нужны только для ознакомления с принципами программно управляемых устройств, на практике из "живых" пожалуй только авр да еще любители пиков Затем нужно сразу переходить на 32бит армы, изучать их более плотно, с обязательными лабораторными работами на стендах... Надо учить тому, что требует рынок, а так будем учить как всегда, для "корочки" :laughing:

Для справки, в стм флеш шина 128бит и частота 30МГц. Подружитесь с математикой и посчитайте, сколько времени выполняется одна инструкция при этих частотах, и сопоставте со временем между приемом символов... ЗЫ Для обработки моего "неудачного" протокола требуется от 25 до 40 машинных инструкций, вот и прикинте, если интересно, а переубеждать меня не надо, я не зеленый студент, и проектов дофига сделал, причем все работают как надо :rolleyes:

CRC считается по таблице - это недолго, определить ИД и длину еще быстрее, и флеш не такой уж медленный, как кажется, во первых 64 или 128 битный доступ, плюс конвеер, скорость почти не ограничивает, если не делать умопомрачительных ветвлений. И протокол не настолько "тупой", много чего делается до начала передачи (ответы подтверждения, запроса идентификации вновь подключенных устройств и т.д.)

Не буду впадать в тупой спор, просто скажу, что кроме уартов на интах, работает файловая система, сетевой стек, парсер биткода виртуальной задачи, работа с кучей периферии, включая несколько каналов 1wire(кто в теме, тот знает, как этот протокол чувствителен к задержкам)и еще много чего... И самое главное - все работает и "не жужжит". Зависнуть все может только из-за кривости самого программиста. Дак какой тогда выигрыш-то, кроме дополнительных настроек? Я же говорю, что выигрыш есть, если в протоколе байты передаются кратными пакетами, на которые настроен триггер фифо. Ну сколько времени потребуется, если в инте проверить пару байт и записать в память с инкрементом счетчика?? На частоте 160 МГц?? И за это время что можно потерять?? Ничего не терялось никогда.

Хорошо, объясню подругому... Принимаю пакет, фифо настроен на 16 байт, а пакет - 7, т.е. прерывания на прием я не дождусь, а придет оно только, когда приму еще 9 байт, или таймаут, но я должен сразу ответить устройству, что принял от него пакет, а я отвечу только через мсек, а устройство будет "думать", что пакет проглотился и начнет слать новый - не годится. Еще плюс таймер задействовать под каждый уарт... Таймера всегда нужны для более важных задач. Плюс те-же доп. прерывания, зачем?? ЗЫ. Лично мое мнение - фифо использовать хоть как-то удобно только под небольшие пакеты кратной длины, остальное либо прерывания, либо дма.

Тогда объясните алгоритм приема пакета с фифо, где 1й байт ИД, который нужно фильтровать, затем адрес, то-же самое, и длина, по которой определяется буфер, а в конце еще и КС?? Причем длина, как правило, не кратна фифо. Таймауты использовать нельзя! По своей памяти, с флешкой работал странично, т.е. запихиваю 264 байта, через дма, затем жду отмены бизи, потом опять... Если флешка побайтная - то дма не нужен, только для чтения и блоками. Это крайний случай, когда все урты работают в непрерывном потоке, для таких целей используют потоковые коммуникационные процессоры, со встроенной аппаратной распарсировкой пакетов и дма в "автомате". И 130кгц прерываний, для векторного nvic - это немного. Тут все зависит от "кривости" обработчика ;)

Это вообще не о чем. Что такое программирование встраиваемых систем, это во первых системы реального времени, либо управляющие контроллеры ПЛК. Все это базируется в 90% случаев на МК, конечно, если вы не любитель винды, с ее потрясающей стабильностью в режиме 24\7 Знание архитектуры МК это и ваши любимые интерфейсы и протоколы и пр.. Не путайте микроконтроллер с процессором. Сейчас МК - это уже системы на кристалле, где есть все, кроме памяти. Да, сейчас архитектура процессоров уходит на второй план, т.к. программирование ведется на языках высокого уровня, а не на ассемблерах - тут нет ничего плохого, задачи стали сложнее, и инструменты стали удобнее. Опыт работы - это еще не означает полное знание этих протоколов. Я много сделал всего на TCP/IP, но не скажу, что полностью знаю все нюансы, равно, как и тот товарищ, который придет на эту должность, я уверен. Какой смысл, имеет использование гнушных систем, работая в кейле или иаре?

Это только в "тепличных" условиях. В моем случае была поддержка протоколов с пакетами разной длины от 6 до 1000 байт, причем длина указывается в первых байтах, без таймаутов, там же и ИД-пакета, которые нужно парсить "на лету", тут все фифы только вредят, и работа уартов на 115200 не сильно замедляет систему, если конечно, не нагружать прерывания чем-то еще, кроме приема...

Наверно институтская программа "Сколково" У нас вообще год один пик изучали, причем изучили далеко не все :laughing: Сейчас вообще вольгота - все, кому не лень предлагают платы с процами, та же дискавери и т.д. Жаль в то время, когда сам учился такого не было...

Че-то не пойму, или все пытаются использовать стм для ЦОС, с несколькими стримами по 100 мегабайт\сек или используют сразу всю периферию, что каналов дма нехватает или что еще... Вот никогда эти фифо не использовал, муторно с ними, работал с 5 уартами и 2 спи одновременно, по 100мег не передавал, конечно, ибо для таких задач существуют коммуникационные процы или плис. Никаких проблем не испытывал, либо, принимал по прерываниям, либо дма, для больших пакетов. Тут, по моему, искусственно создают бурю в стакане воды...

Ну вот зачем такие голословные утверждения? Пример уарта делал, нужно передавать и принимать пакеты разной длины, делаю первое - в процедуре "инит" анализируется размер пакета на передачу, если пакет большой - запускаю ДМА, маленький, просто задаю глобальный счетчик, запускаю передачу - если ДМА, ждем флаг окончания, если счетчик, по прерыванию уарта уменьшаем и так до нуля, если событие передачи состоялось - генерю софт инт. Прием - запускаю дма и счетчик таймаута, жду событий и генерю софтинт, что сложного? И не надо ждать в циклах и ступорить ось. Все работает по прерываниям в режиме полного автомата.

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

Ну, я думаю, тут вы погорячились. Что за программер для МК, для которого железо в тягость?? Зачем он нужен такой, если уж так неохота подпаять пару микрух и проводков со светодиодами, так пусть лучше программит под виндой, на дотнетах всяких или идет в инетпрограммисты... А коли уж выбрали контроллеры, так и в железе хоть минимально разбирайтесь. МК для этого и нужны, чтоб напрямую управлять железками. ЗЫ. Помню, когда учился в своем политехе, еще только пики16ф84 появились. Так там сваяли на коленке какой-то стенд, с индикатором, кнопками и моторчиком, препод 2 недели распинался про регистры пика, нафига - непонятно, все было в даташите, а вот про управление индикатором, программный ШИМ для моторчика и т.п. - ни слова!! Мне повезло, я уже на этом пике к тому времени микро АТС сделал, а вот у остальных студней(особенно девочек), мозги сразу повзрывались...