Форум РадиоКот

КРАМ, комиксы я не читал и вырос я на украинских сказках........., но это не столь важно.........., самокритику я люблю....., главное чтобы эта критика не переходила черту оскорбления......, ведь все мы люди разные и воспринимаем мир тоже по разному.........., а задал я этот вопрос к тому, что вспомнил я из своей жизни то далекое время когда я учился писать страницив HTML коде............., но потом когда я попробовал прогу которая делает это в графическом виде максимально быстро и просто, где не нужно заморачиваться над тегами то понял насколько легкой может быть жизнь.........., и у меня и возник резонный вопрос: неужто человечество еще до сих пор в отношении МК не придумало ничего подобного.

Добрый день

Подскажите, чем отличается XC9536XL-7PC44C от XC9536XL-10PCG44C или от XC9536XL-10PC44I

FreshMan писал(а):КРАМ, ...неужто человечество еще до сих пор в отношении МК не придумало ничего подобного.

Придумало. И довольно давно.
Только качество кода никчемное.
Запомните простую истину. Чем проще сделать работу, тем она меньше стоит, независимо от результата.
Т.е. эффективность решения с МК будет тем выше, чем более низкий уровень разработки Вы примените.
Даже Си при написании программ для МК (особенно сигнальные приложения) дает значительный оверхед и часто является причиной избыточных затрат на производство.
Затраты при разработке - копейки в пересчете на единицу будущего тиража, а при производстве каждая лишняя пайка повышает цену совершенно линейно.
Кстати. К WEB- программированию это относится в равной мере. Высокоинтеллектуальными приложениями не написать уникальный код. Будет изрядный примитив для своего времени и возможностей.

Yggasser писал(а): Подскажите, чем отличается XC9536XL-7PC44C от XC9536XL-10PCG44C или от XC9536XL-10PC44I

XC9536XL-7PC44C - задержка "контакт-контакт" = 7 нс; корпус PC44, С - температурный диапазон (0..+70 С)
XC9536XL-10PCG44C - задержка "контакт-контакт" = 10 нс; корпус PC44, буква G - производство без использования свинца (Pb-free);
XC9536XL-10PC44I - все то же самое, только температурный диапазон промышленный (-40..+85 С).

КРАМ писал(а): эффективность решения с МК будет тем выше, чем более низкий уровень разработки Вы примените.

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

Jack_A писал(а):Присоединяюсь к каждому слову.

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

Пушистые, нас уже трое !!! Присоединяюсь..

Во времена, когда компов не было и программ трансляторов тоже../имеется в виду в наличии/ наблатыкался писать прямо в машинных кодах,
получалось быстрее, чем щас на АСМе..

Jack_A писал(а): Присоединяюсь к каждому слову. Но, кажется, мы в меньшинстве...
Забавно, но у непосвященных "низкоуровневое программирование" стойко ассоциируется с "низкокачественное" .

На самом деле программы на ассемблере зачастую оказываются качественнее, чем на ЯВУ (особенно если сравнивать с плохими ЯВУ вроде Си/Си++ с их ужасным синтаксисом, отсутствием или слабым контролем типов и т.д.). Вероятно, это происходит в силу двух причин сразу: 1) низкоквалифицированный и тем более не шибко умный человек просто не сможет что-нибудь серьёзное написать на ассемблере (у дурака мозгов не хватит, у умного, но неквалифицированного -- этой самой квалификации, хотя он её сможет поднять, в отличие от идиота); 2) ассемблер не даёт расслабиться, требует повышенного внимания к мелочам.

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

Gudd-Head писал(а):

Jack_A писал(а):Присоединяюсь к каждому слову.

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

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

КРАМ, вопрос не в этом.. Четвёртым будешь?

Я не пью...

А мы и не предлагаем..
Вступай в клуб кошаков-динозавров-на-АСМе-и-ниже-писателей..

Нее, я сам по себе.
Это моя работа.
За последний календарный год сдал в производство 7 проектов разной степени сложности на 8 и 16 разрядных МК. Все без исключения на АСМе. Ни разу не было проблем со временем на разработку кода. И это при весьма напряженном графике.
А вот у моих соратников по борьбе (сослуживцев) с написанием кода на Си вечные заморочки. То с синтаксисом нового компилятора, то с ограничениями компилятора, то с реализацией на Си ДСП-задач...

Для средних и легких задач ассемблер использовать удобнее, если в системе малый объем памяти для программы.
Для "объемных" систем удобнее использовать Си, попробуйте напишите под какой-нибудь ARM линукс на ассемблере...

Jack_A писал(а): Присоединяюсь к каждому слову. Но, кажется, мы в меньшинстве...
Забавно, но у непосвященных "низкоуровневое программирование" стойко ассоциируется с "низкокачественное" .

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

Arlleex писал(а):Для средних и легких задач ассемблер использовать удобнее, если в системе малый объем памяти для программы.
Для "объемных" систем удобнее использовать Си, попробуйте напишите под какой-нибудь ARM линукс на ассемблере...

Если сильно захотеть, то можно и на ARM написать своё ядро, которое будет иметь достаточные возможности, необходимые для поставленной задачи. Причём, написать на АСМе

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

FreshMan Я вам дал название программы, пробуйте. Она компилирует и асм-код и Си-код из графического алгоритма. Кстати, для начала обучения самое то - можно посмотреть и разобраться как эта программа описывает некоторые команды обработки, скажем, для дисплея или выводит на индикатор. Просто из меня компилируете в Си и смотрите код с комментариями... на английском

Господа, доброй ночи!

Я это... ламер... за ночь удавил 3 тиньки 13А...
С I2C работал... надо было помедленнее.. я и запульнул в код
#pragma optsize-
CLKPR=0x80;
CLKPR=0x08;
#ifdef _OPTIMIZE_SIZE_
#pragma optsize+
#endif

ну и программатор больше не увидел..
долго не разбирался, выпая, впаял новую.
Убедился что проблема в коде - влил, ну и потерял
Впаял третью.. полез в фьюзы... сказал ей CKSEL 11
(128 kHz internal oscillator (CKSEL[1..0] = 11))
программатором потерял...
но по осциллографу видно, что программа работает, данные шлет, и медленно, как заказывал
Вопрос.. как ее обратно программатором подцепить можно?

128 кГц и CLKPR=8 выходит 8 кГц тактирования ядра.
Программатор должен подать частоту SCK не выше 2 кГц.
Смотрите настройки программатора, как в нём и до какой степени снижается частота.

avreal-у нужно было бы дать ключ -o8khz (ему задаётся частота ядра, он сам вычисляет частоту SCK).

Там какая-то фигня, почему-то при _подаче_ сброса CLKPR не сбрасывается во fuse-вое значение (0 или 3 в зависимости от CKDIV8). Соответственно, программатор при подаче сброса получает ту низкую частоту, которую установила программа.
Я пробовал подавать двойной импульс сброса (подать, ненадолго снять, опять подать), чтобы хоть по _снятию_ сброса CLKPR возвращался в нужное состояние, но толи где-то ошибался во времени и программа успевала доходить до новой записи в CLKPR и подача сброса опять ничего не давала, толи ещё что-то.
Надо вернуться к этому вопросу.

Спасибо большое!

Отложил в сторонку дешевый USBasp, взял mkii, в avr studio задал режим программирования ISP в 1.956 kHz, программатор директиву скушал, а потом успешно считал тиньку. Победа

Осталось понять как c помощью USBasp программировать..
===
Никак, кроме как в код программатора USBasp изменения вносить. Судя по прочитанному, там есть джампер, который только позволяет выбрать одну из двух частот

SCK signal can work at two frequencies 375kHz and 8kHz which can be selected by Jumper JP3. If Jumper is unconnected, then SCK speed is 375kHz. Low speed SCK is used when MCU is clocked with low speed oscillator like 32kHz.