Easyelectronics.ru • Просмотр темы - Алгоритм билдер (описания, без программ)

Easyelectronics.ru

Электроника для всех
Текущее время: 14 авг 2018, 13:29

Часовой пояс: UTC + 5 часов


Правила форума


Входить исключительно со своей туалетной бумагой. Можно невозбранно получить по голове за быдляк и личные наезды.


    • JLCPCB - Прототипы 10 PCBs всего за 2$ (100*100mm, 2-layer)
    • Как мы делаем платы, смотрите на YouTube
    • Крупнейшая китайская фабрика прототипов. 300000+ заказчиков и 10000+ заказов в день!
    • LCSC - Крупнейший китайский онлайн магазин комплектующих.

Начать новую тему Ответить на тему  [ Сообщений: 1181 ]  На страницу Пред.  1 ... 42, 43, 44, 45, 46, 47, 48  След.
Автор Сообщение
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 01 мар 2015, 21:41 
Старожил

Зарегистрирован: 22 июн 2010, 21:53
Сообщения: 976
Откуда: Brussels
Alexandr_1 писал(а):

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

...

Подойдет ли предложенный вами метод в моей ситуации?
Маленький периферийный МК, память небольшая, постоянно «молотится» с электронным узлом, отвлекаться некогда. Есть небольшие временные окна, когда МК отвлекается для связи с центральным МК.
Во время окна сделал выброс байтов для дебаггера, нашел ошибку. Выбросить несколько байтов – на это еще есть время. А больше затраты времени приведут к нарушению работы электронного блока, что может привести к его поломке. Такое бывало, а это крайне нежелательно, т.к. блок дорогой. Так что экспериментировать с отладкой бывает непросто и опасно.
Да и что даст точка отказа? При аппаратном сбое программа может сбиться в любой точке.


Этот метод предлагается не мной. Этот методика обязательна (насколько я понимаю) для сертификации.

" ... на это еще есть время... " " ... блок дорогой" - ну и почему не использовать МК помощнее? Наверняка оценка рисков при аварии покроет использование более мощного МК.

Дигностика (как POST так и runtime) - неотъемлемая часть проекта. Т.е. не может возникать вопроса - "у меня дигностика не помещается в МК", точно так же как не бывает "у меня задача не помещается в МК". Точнее бывает конечно - но это ошибка проектирования.

Вы извините, Alexandr_1, но всвете самой 1й процитированной фразы: "... тратить неделю для поиска ..." думаю нам нет смысла серьёзно что-то дискутировать. У меня 100% нет намерения хоть как-то изменить именно ваш образ мыслей.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 10 мар 2015, 09:41 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
Alexandr_1 писал(а):
Насколько я представляю, логер занимает место, а МК маленькие. Кроме того, часто МК заняты скоростным управлением каких-либо устройств, поэтому МК не может надолго отвлекаться. У меня нередки ситуации, когда в нужном месте нет времени даже на выброс одного байта в дебаггер. В таких случаях нужный байт выбрасываю в регистр, а затем, когда у МК появляется окно, он выбрасывает байт (или массив байтов) в дебаггер.

А может все таки неправильно выбран контроллер?
Отказываться от вменяемого дебага, логгирования, тестирования. При этом оправдывая это тем, что используется устаревший контроллер с ограниченным количеством ресурсов, который не позволяет реализовать все вышесказанное. В то время как если аналогичные по стоимости решения, которые это все позволяют. Если нет ресурсов реализовать вменяемую защиту, то может быть МК не подходит, а реализация ПО без защиты просто не имеет право на существование?
Признайте уже, что вы не знаете как это сделать/не можете/проект сильно усложняется при использовании текущих средств разработки.
Цитата:
Насчет тестирования – вначале проверяю сам, затем проверяют испытатели, затем опытная эксплуатация. За это время должны отловиться все ошибки.

А почему бы не сделать автоматическое тестирование? Сэкономит кучу человекочасов, премию дадут.

Alexandr_1 писал(а):
elisey писал(а):
…Изделия непростые, стоят 4 МК….
Обычно это значит, что вы не правильно выбрали аппаратную платформу.

Обоснуйте.
У меня в аппарате несколько независимых систем, выполненных в виде отдельных блоков. Каждый блок – непростой узел. Я поставил в каждом блоке по МК и связал их по SPI.
Думаю, в моей ситуации переход к применению нескольких МК – отличное решение.
1 Резко упростилась написанием программ. Каждый МК занят своей задачей.
2 Резко упростилась доработка и модернизация аппарата.
3 Резко упростилась ремонт – для быстрой диагностики можно легко заменить подозреваемый в дефекте блок.

Обосновываю. Подсознательное стремление к аппаратному "упрощению", стремлению разбивания на модули с МК в каждом из них, узловой конструкции говорит о проблемах с управлением сложностью. При отсутствии методик кодирования проект очень быстро усложняется, и его становится очень сложно модифицировать и поддерживать. Так же если язык не позволяет создавать гибкие системы, которые можно легко собирать "из кубиков" на этапе компиляции, появляется такое стремление выделить под каждую задачу свой контроллер. Эдакая простая "тупо в лоб" модульность. На деле же это несет за собой следующий негатив:
1. Дополнительные аппаратные затраты на связь модулей. Каждый отдельный модуль теперь должен не только реализовывать свой функционал, но и поддерживать модуль связи с остальными модулями. Причем в актуальном состоянии. А это значит что нужно поддерживать протокол обмена в актуальном состоянии на всех модулях сразу. А если будут обновления, то обновления нужно накатывать на все модули. Или сразу делать протокол обмена "на будущее", а это дополнительные ресурсы.
2. Дополнительные затраты человекочасов на поддержку связи всех этих модулей.
3. Эффективность и надежность связи модулем драмматически падает, по сравнению с внутрипроцессорным взаимодействием. А это значит что получаем ограничение возможностей по быстрому и надежному реагированию.
4. Стоимость компонентов (микоконтроллеры, дублирование их обвязки), стоимость печатных плат, размер готового изделия, энергопотребление увеличивается.
Думаю в вашей ситуации переход к многопроцессорному решению это попытка решить проблемы сложности кодирования. Якобы упрощение модернизации вашей системы появилась только из за того, что это позволило отказаться от большого неподдерживаемого проекта на АБ, и прийти к маленьким, более менее поддерживаемых проектам на АБ.

Цитата:
Маленький периферийный МК, память небольшая, постоянно «молотится» с электронным узлом, отвлекаться некогда. Есть небольшие временные окна, когда МК отвлекается для связи с центральным МК.
Во время окна сделал выброс байтов для дебаггера, нашел ошибку. Выбросить несколько байтов – на это еще есть время. А больше затраты времени приведут к нарушению работы электронного блока, что может привести к его поломке. Такое бывало, а это крайне нежелательно, т.к. блок дорогой. Так что экспериментировать с отладкой бывает непросто и опасно.

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

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 10 мар 2015, 18:41 
Старожил

Зарегистрирован: 27 апр 2013, 13:53
Сообщения: 740
Кто в данной теме, из "натуралов" использовал АБ в своих проектах, чтобы лучше понять предпосылки выбора для работы данного инструмента?

P.S. Вроде сторонники АБ всё доходчиво объясняют :) а то что инструмент не обрёл ещё больше хороших индустриальных свойств,
и методологий использования, то это вопрос отдельный.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 10 мар 2015, 19:19 
Старожил

Зарегистрирован: 19 мар 2013, 19:37
Сообщения: 2481
Откуда: Санкт-Петербург
У "натуралов" (во всяком случае, у тех, кто знает хоть с полдюжины языков) есть наработанные методики быстрой оценки разных инструментов. Чтобы с ходу получить ответ на вопросы "что он мне даст" и "чем за это придётся платить".
Пока по сравнению с макроассемблером - только стрелочки (которые не всем нужны), а платить придётся дорого...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 11 мар 2015, 17:27 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
KPG писал(а):
Кто в данной теме, из "натуралов" использовал АБ в своих проектах, чтобы лучше понять предпосылки выбора для работы данного инструмента?

Серьезно? На дворе 2015 год, а вы предлагаете рассмотреть предпосылки использования ассемблера в коммерческой деятельности?
Я знаю асм, смотрел исходники на АБ, читал его хелп. Не думаю, что если я им попользуюсь, то мое мнение радикально изменится.

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 11 мар 2015, 18:01 
Старожил

Зарегистрирован: 22 июн 2010, 21:53
Сообщения: 976
Откуда: Brussels
KPG писал(а):
Кто в данной теме, из "натуралов" использовал АБ в своих проектах, чтобы лучше понять предпосылки выбора для работы данного инструмента?

P.S. Вроде сторонники АБ всё доходчиво объясняют :) а то что инструмент не обрёл ещё больше хороших индустриальных свойств,
и методологий использования, то это вопрос отдельный.

Красивый вброс.

Аргументов в пользу АБ пока что не было ни одного.
Я повторю вопрос заданный уже наверное год назад, пусть АБшники приведут простой пример:
Цитата:
"Мы перевели кодовую базу проекта наработанную за последнии N лет (XXX тыс строк, NNN человекочасов) на АБ и получили результат:
TTM (time-to-market) уменьшился до ... недель
Количество багов на 1000 строк кода уменьшилось ... %
Время на исправление бага уменьшилось на ... %
Беклог девелопера сократился на %% (ну или мы сократили ... девелоперов)


Лично мне очевидно, что при переходе к АБ, это недостижимо - ни один из пунктов выше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 02 апр 2015, 15:40 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 399
elisey писал(а):
А может все таки неправильно выбран контроллер?
Отказываться от вменяемого дебага, логгирования, тестирования. При этом оправдывая это тем, что используется устаревший контроллер с ограниченным количеством ресурсов, который не позволяет реализовать все вышесказанное. В то время как если аналогичные по стоимости решения, которые это все позволяют. Если нет ресурсов реализовать вменяемую защиту, то может быть МК не подходит, а реализация ПО без защиты просто не имеет право на существование?
Признайте уже, что вы не знаете как это сделать/не можете/проект сильно усложняется при использовании текущих средств разработки.


Дело не в устаревшем МК.
Что дает «вменяемый дебаг, логгирование, тестирование»?
При скоростных процессах это вообще не подойдет, вам придется писать на ассемблере, в этом случае АБ в несколько раз лучше.
При не скоростных процессах. Думаю, мой дебаггер, практически не влияющий на работу программы, предпочтительнее при реальной работе.
Какой выигрыш дают логгирование и тестирование – вопрос.

elisey писал(а):
А почему бы не сделать автоматическое тестирование? Сэкономит кучу человекочасов, премию дадут.

Плохо представляю, как автоматическое тестирование сэкономит кучу человекочасов. Как проводится автоматическое тестирование?

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

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


elisey писал(а):
Эдакая простая "тупо в лоб" модульность. На деле же это несет за собой следующий негатив:
1. Дополнительные аппаратные затраты на связь модулей. Каждый отдельный модуль теперь должен не только реализовывать свой функционал, но и поддерживать модуль связи с остальными модулями. Причем в актуальном состоянии. А это значит что нужно поддерживать протокол обмена в актуальном состоянии на всех модулях сразу. А если будут обновления, то обновления нужно накатывать на все модули. Или сразу делать протокол обмена "на будущее", а это дополнительные ресурсы.

Насчет «дополнительных аппаратных затрат на связь модулей» - это еще вопрос, что лучше.
В моем варианте связь с блоком по интерфейсу SPI – простенький плоский кабель и шинник 74НС244 на плате центрального МК.
В варианте одного МК придется заводить все сигналы от всех датчиков и исполнительных устройств на плату центрального МК – это куча проводов (в том числе экранированных, поскольку датчики аналоговые). Большие разъемы, много пайки проводов, падение надежности из-за механического контакта в разъемах.
Мой вариант проще модернизировать. Скажем, попросили поставить в блоке дополнительно датчик давления. Мне придется дорабатывать только плату блока.
А в варианте одного МК придется также дорабатывать плату центрального МК.
Неясно, что значит «поддерживать протокол обмена в актуальном состоянии на всех модулях сразу».
Я сделал просто – центральный МК периодически опрашивает периферийные МК.
Центральный МК, когда нужно, опросил периферийный, обменялись данными – и все.
Думаю, при использовании отработанных библиотечных элементов не должно быть проблемы обновления.

elisey писал(а):
2. Дополнительные затраты человекочасов на поддержку связи всех этих модулей.

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

elisey писал(а):
3. Эффективность и надежность связи модулем драмматически падает, по сравнению с внутрипроцессорным взаимодействием. А это значит что получаем ограничение возможностей по быстрому и надежному реагированию.

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

Отдельный МК быстрее и надежней отреагирует на ситуацию в своем блоке, чем центральный МК, на который навешены все блоки.

elisey писал(а):
4. Стоимость компонентов (микоконтроллеры, дублирование их обвязки), стоимость печатных плат, размер готового изделия, энергопотребление увеличивается.
Думаю в вашей ситуации переход к многопроцессорному решению это попытка решить проблемы сложности кодирования. Якобы упрощение модернизации вашей системы появилась только из за того, что это позволило отказаться от большого неподдерживаемого проекта на АБ, и прийти к маленьким, более менее поддерживаемых проектам на АБ.

У меня пока не было проекта, который я бы не смог поддержать на АБ.
В данном проекте я использовал многопроцессорное решение вовсе не из-за сложности кодирования, а исходя из преимуществ, которые дает такое решение.
Ну а возрастание стоимости и прочего очень несущественно.
Изделие с многопроцессорным управлением, естественно, непростое, дорогое (десятки и более тысяч рублей), габаритное, так что дополнительные МК с обвязкой – копейки.

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

[/quote]
Если простой и недорогой МК хорошо выполняет поставленную задачу, почему же он плохо подходит?
Гордиться мне не чем, тут специалисты по программированию выше классом.
Просто пытаюсь и разобраться, и обосновать, что АБ при соответствующем развитии имеет право на существование.

Девайс в этом году должен пойти в дело, а заранее афишировать, естественно, не хочется.

//Mt писал(а):
Я повторю вопрос заданный уже наверное год назад, пусть АБшники приведут простой пример:
"Мы перевели кодовую базу проекта наработанную за последнии N лет (XXX тыс строк, NNN человекочасов) на АБ и получили результат:
TTM (time-to-market) уменьшился до ... недель
Количество багов на 1000 строк кода уменьшилось ... %
Время на исправление бага уменьшилось на ... %
Беклог девелопера сократился на %% (ну или мы сократили ... девелоперов)
Лично мне очевидно, что при переходе к АБ, это недостижимо - ни один из пунктов выше.


Крайне сомнительно, что кто-то приведет вам такой пример.
Зачем переводить отработанный проект на другой язык, это же огромные пустые затраты времени? Проще поддерживать проект на старом языке.
Кто помнит количество багов на 1000 строк и кто их считает? Что это дает?
Скажем, один разработчик в свеженаписанной программе за пару часов нашел 6 багов, другой неделю искал один баг, как в упомянутом выше случае.


elisey писал(а):
Серьезно? На дворе 2015 год, а вы предлагаете рассмотреть предпосылки использования ассемблера в коммерческой деятельности?
Я знаю асм, смотрел исходники на АБ, читал его хелп. Не думаю, что если я им попользуюсь, то мое мнение радикально изменится.

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

Send_Paket (kom_WWrite_Paket, kom_RRead_Paket, adress_OOtkuda, NN_byte, flg_no_FFinish_SPI)

kom_WWrite_Paket – команда на запись нужной переменной в периферийный МК,
kom_RRead_Paket– команда на чтение нужной переменной из периферийного МК,
adress_OOtkuda – адрес нужной переменной в центральном МК,
NN_byte – число байт в переменной,
flg_no_FFinish_SPI – флаг, оставлять или нет периферийный МК после окончания передачи на связи.

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

Элемент непростой, число ассемблерных команд за 100 или более, не считал.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 02 апр 2015, 16:42 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3996
Alexandr_1 писал(а):
При нормальном написании, похоже, АБ близок к ЯВУ.
ога, ога. как обычно "макроассемблер - это уже ен ассемблер, а почти ЯВУ!"... как бы ни так. никуда ассемблерные проблемы не деваются и деться не могут.
Alexandr_1 писал(а):
Зачем переводить отработанный проект на другой язык, это же огромные пустые затраты времени? Проще поддерживать проект на старом языке.
было бы проще - никто бы не переводил. проект типа мигания лампочкой или термостат - наверное вообще один раз написать и больше не трогать. а что посерьезнее - там всегда есть доработки, усовершенствования.
Alexandr_1 писал(а):
Кто помнит количество багов на 1000 строк и кто их считает? Что это дает?
серьезные конторы, как вам уже говорили, используют кучу методик для упрощения повседневной работы. это и тестирование, и багтрекеры, и системы контроля версий. багтрекеры помнят кол-во багов, могут дать статистику по качеству продукта. тесты уменьшают вероятность накосячить при внесении очередной правки. скв позволяют знать, что было с проектом до тебя, позволяют быстро локализовать баг и ответить на еще кучу разных возникающих вопросов (ну, не говоря о том, что без них работа в команде вообще сложна). но если у тебя одноразовый проект 2000 строк, то ничего этого не надо. а вот когда сотни тыщ строк чужого забористого асма - тут взгляд уже совсем другой и на асм, и на подход к работе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 13 июн 2015, 02:48 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 399
Ink писал(а):
Alexandr_1 писал(а):
При нормальном написании, похоже, АБ близок к ЯВУ.
ога, ога. как обычно "макроассемблер - это уже ен ассемблер, а почти ЯВУ!"... как бы ни так. никуда ассемблерные проблемы не деваются и деться не могут.

Проблемы тут уже обсуждалось, они либо малосущественны, либо проблемы у начинающих, не умеющих писать на АБ.
Ink писал(а):
Alexandr_1 писал(а):
Зачем переводить отработанный проект на другой язык, это же огромные пустые затраты времени? Проще поддерживать проект на старом языке.
было бы проще - никто бы не переводил. проект типа мигания лампочкой или термостат - наверное вообще один раз написать и больше не трогать. а что посерьезнее - там всегда есть доработки, усовершенствования.

На мой взгляд, все доработки и усовершенствования можно проводить на АБ, не вижу смысла перевода отработанной программы с АБ на другой язык.
Ink писал(а):
Alexandr_1 писал(а):
Кто помнит количество багов на 1000 строк и кто их считает? Что это дает?
серьезные конторы, как вам уже говорили, используют кучу методик для упрощения повседневной работы. это и тестирование, и багтрекеры, и системы контроля версий. багтрекеры помнят кол-во багов, могут дать статистику по качеству продукта. тесты уменьшают вероятность накосячить при внесении очередной правки. скв позволяют знать, что было с проектом до тебя, позволяют быстро локализовать баг и ответить на еще кучу разных возникающих вопросов (ну, не говоря о том, что без них работа в команде вообще сложна). но если у тебя одноразовый проект 2000 строк, то ничего этого не надо. а вот когда сотни тыщ строк чужого забористого асма - тут взгляд уже совсем другой и на асм, и на подход к работе.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 13 июн 2015, 06:27 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3996
Alexandr_1 писал(а):
На мой взгляд, все доработки и усовершенствования можно проводить на АБ, не вижу смысла перевода отработанной программы с АБ на другой язык.
ну вот скажут вам, что девайс ваш должен не только температуру регулировать, но и логировать все на сд-карту карту в формате фат32 (с возможностью горячей замены) и управляться/наблюдаться через tcp/ip. очень будет забавно (точнее уныло) наблюдать, как вы будете это реализовывать на аб. или что, это задача не для авр? это еще почему? в авр и еще больше влезет. при этом, на си - это дело одной недели вместе с отладкой, на аб - дело года, если не больше.
Alexandr_1 писал(а):
Во-вторых, насколько удобно и приемлемо применение указанных методов для МК, управляющих быстрыми устройствами, – большой вопрос.
вы про быстрые устройства заканчивайте. всё быстрое делается на чем-то типа фпга, а мк - это так, середнячок. при том, что вам уже говорили, что ваша быстрота чаще всего вообще не нужна на самом деле.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 26 июн 2015, 16:36 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 399
Ink писал(а):
ну вот скажут вам, что девайс ваш должен не только температуру регулировать, но и логировать все на сд-карту карту в формате фат32 (с возможностью горячей замены) и управляться/наблюдаться через tcp/ip. очень будет забавно (точнее уныло) наблюдать, как вы будете это реализовывать на аб. или что, это задача не для авр? это еще почему? в авр и еще больше влезет. при этом, на си - это дело одной недели вместе с отладкой, на аб - дело года, если не больше.

Я с такими задачами не сталкивался, ничего сказать не могу.
Тут возникают такие вопросы.
1 Может быть, есть библиотечные элементы на АБ для таких задач.
2 Может быть, есть специальные микросхемы для решения таких задач.
3 Вообще, насколько актуальна такие задачи? Под актуальные задачи обычно создают специальные микросхемы.

Ink писал(а):
вы про быстрые устройства заканчивайте. всё быстрое делается на чем-то типа фпга, а мк - это так, середнячок. при том, что вам уже говорили, что ваша быстрота чаще всего вообще не нужна на самом деле.

Есть много задач, где надо быстро, но АВР еще успеет. Как я понял, СИ-шники в этом случае пишут на ассемблере, а это тоска, АБ значительно лучше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 26 июн 2015, 17:53 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3996
Alexandr_1 писал(а):
1 Может быть, есть библиотечные элементы на АБ для таких задач.
ну да, ну да, может есть, а может нет. 99.99999% что нет, т.к. никому не надо. а на си - давно есть, годами выверенные решения, тысячи инсталляций. берешь и на любой платформе используешь.
Alexandr_1 писал(а):
2 Может быть, есть специальные микросхемы для решения таких задач.
есть, только зачем тратиться на спец. микросхему, если все можно сделать софтово и быстро? я уже не вспоминаю, что могут быть какие-то ограничения по функционалу и неисправимые глюки у таких аппаратных реализаций.
Alexandr_1 писал(а):
3 Вообще, насколько актуальна такие задачи?
логгеры каких-то параметров? да они на каждом шагу практически. хотя это не важно, важно то, что аб на таких задачах ставит крест либо нереально завышает их стоимость (при сомнительном качестве).
Alexandr_1 писал(а):
Есть много задач, где надо быстро, но АВР еще успеет. Как я понял, СИ-шники в этом случае пишут на ассемблере
правильно делать - это не писать на си или асме, а правильно выбрать инструмент. и очень редко правильным инструментом будет тот единственный, который знаешь.

Alexandr_1, заходи почаще, а?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 08 июл 2015, 14:17 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
Alexandr_1 писал(а):
2 Может быть, есть специальные микросхемы для решения таких задач.

Очень часто специальная микросхема для таких задач - это контроллер с библиотекой. Либо просто контроллер с подходящей периферией.

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 09 июл 2015, 17:38 
Старожил
Аватара пользователя

Зарегистрирован: 22 июл 2014, 13:20
Сообщения: 325
Откуда: правая юрта тундры
elisey писал(а):
Очень часто специальная микросхема для таких задач - это контроллер с библиотекой. Либо просто контроллер с подходящей периферией.

Очень сложно понять о чём вы говорите
(это всё равно, что разжевать студенту, что такое "ремонт дефектов").
Есть ли конкретный пример - и из какой области.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 09 июл 2015, 22:10 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3996
о привет пингвинчик:)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 12 июл 2015, 17:35 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 399
Ink писал(а):
Alexandr_1 писал(а):
1 Может быть, есть библиотечные элементы на АБ для таких задач.
ну да, ну да, может есть, а может нет. 99.99999% что нет, т.к. никому не надо. а на си - давно есть, годами выверенные решения, тысячи инсталляций. берешь и на любой платформе используешь.

Согласен, что недостаток АБ – отсутствие большой сделанной в едином стиле библиотеки. Для меня это малосущественно, т.к. для основных целей АВР – измерение, контроль и управление – все библиотечные элементы давно уже есть.
Кстати, создание библиотечных элементов на АБ – довольно интересная задача.
Кроме того, библиотечные элементы на АБ – это не «черный ящик», их можно легко модернизировать, совершенствовать и дорабатывать под свои задачи, в общем, гибкая вещь.
Ink писал(а):
Alexandr_1 писал(а):
2 Может быть, есть специальные микросхемы для решения таких задач.
есть, только зачем тратиться на спец. микросхему, если все можно сделать софтово и быстро? я уже не вспоминаю, что могут быть какие-то ограничения по функционалу и неисправимые глюки у таких аппаратных реализаций.

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

Ink писал(а):
Alexandr_1 писал(а):
3 Вообще, насколько актуальна такие задачи?
логгеры каких-то параметров? да они на каждом шагу практически. хотя это не важно, важно то, что аб на таких задачах ставит крест либо нереально завышает их стоимость (при сомнительном качестве).


Предполагал, что задачи для АВР, требующие мощный специальный библиотечный элемент, редко встречаются.
С логгерами не сталкивался. Посмотрел в интернете, что это такое. В чем там проблема? В записи на флэшку и работа через tcp/ip? Может быть, для этих задач есть специализированные микросхемы?

Ink писал(а):
Alexandr_1 писал(а):
Есть много задач, где надо быстро, но АВР еще успеет. Как я понял, СИ-шники в этом случае пишут на ассемблере
правильно делать - это не писать на си или асме, а правильно выбрать инструмент. и очень редко правильным инструментом будет тот единственный, который знаешь.

Вот тут спорный вопрос.
Изучение разных языков программирования занимает много времени, а время – ценный ресурс. Причем для профессиональной работы язык надо основательно, со всякими тонкостями и нюансами. Все это затраты времени.
Программистам, конечно, проще. Но тут вопрос – а что программисты делают на АВР?
Как правило, АВР тесно связана с электроникой, соответственно, разрабатывать должен электронщик. А электронщику, занятому в серьезном проекте, некогда изучать массу всяких языков. Кончай индукцию, гони продукцию – как-то так у Райкина.
А чистому программисту нельзя разрабатывать электронику. Тут уже был пример с лифтом. Да и в описании АБ схему программатора электронщик в таком виде не приведет.
Ink писал(а):
Alexandr_1, заходи почаще, а?

Самому интересно, но некогда, напряг на работе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 12 июл 2015, 18:01 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3996
зачем на каждый случай спец микросхемы, когда можно вообще без них?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 25 июл 2015, 13:00 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
PodnimatelPingvinov писал(а):
Есть ли конкретный пример - и из какой области.

Ну тот же самый тут обсуждаемый логгер, преобразователи интерфейсов, шлюзы, драйверы устройств.

Цитата:
Кстати, создание библиотечных элементов на АБ – довольно интересная задача.
Кроме того, библиотечные элементы на АБ – это не «черный ящик», их можно легко модернизировать, совершенствовать и дорабатывать под свои задачи, в общем, гибкая вещь.

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

Цитата:
Во-первых, аппаратная реализация быстрее.

Быстрее всегда лучше? Скорость не должна быть "быстрее", она должна быть "достаточной для выполнения задачи". В некоторых случаях медленнее (об этом ниже). Из минусов аппаратных реализаций - это негибкость и дороговизна. Из примера можно взять реализацию сетевого стека. Аппаратный MAC и софтовый TCP/IP дешевле и гибче полностью аппаратного решения.
Цитата:
Во-вторых, микросхемы разрабатывают профессионалы в этой области, должны делать хорошо, глюки они должны отрабатывать.

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

Цитата:
В-третьих, часто необходимо гальванически развязываться, что при использовании внешней микросхемы легко сделать.

Или взять еще одну тиньку и отвязать ее.

Цитата:
Скажем, плату преобразователя USB-COM купил по цене около 40 рублей, правда, до скачка доллара.

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

Цитата:
С логгерами не сталкивался. Посмотрел в интернете, что это такое. В чем там проблема? В записи на флэшку и работа через tcp/ip? Может быть, для этих задач есть специализированные микросхемы?

Так любой МК и есть микросхема для этой задачи. Гибкий, дешевый. Все библиотеки доступны, поэтому разработка ПО тоже дешевая.

Цитата:
Вот тут спорный вопрос.
Изучение разных языков программирования занимает много времени, а время – ценный ресурс. Причем для профессиональной работы язык надо основательно, со всякими тонкостями и нюансами. Все это затраты времени.
Программистам, конечно, проще. Но тут вопрос – а что программисты делают на АВР?
Как правило, АВР тесно связана с электроникой, соответственно, разрабатывать должен электронщик. А электронщику, занятому в серьезном проекте, некогда изучать массу всяких языков. Кончай индукцию, гони продукцию – как-то так у Райкина.
А чистому программисту нельзя разрабатывать электронику. Тут уже был пример с лифтом. Да и в описании АБ схему программатора электронщик в таком виде не приведет.

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

Цитата:
А электронщику, занятому в серьезном проекте, некогда изучать массу всяких языков.
Самообразованием нужно заниматься всегда. Порою нужно притормозить и пошире изучить свою область. И тогда привычную работу можно будет выполнять намного быстрее

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 29 июл 2015, 10:45 
Старожил
Аватара пользователя

Зарегистрирован: 22 июл 2014, 13:20
Сообщения: 325
Откуда: правая юрта тундры
dosikus_2 писал(а):
Сначала докажи, что заБулдыгер инструмент а не рюшечки и свистоперделки ... :)))))))
Только счас дошёл до меня смысл научного понятия "свистоперделка". Корни этого задания надо искать в шпионской технике. http://www.youtube.com/watch?v=4sONDLzLXf0
Видимо, dosikus_2 ...


Вложения:
a261.JPG
a261.JPG [ 12.49 Кб | Просмотров: 7301 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 17 авг 2015, 01:19 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 399
elisey писал(а):
…Кстати, создание библиотечных элементов на АБ – довольно интересная задача.
Кроме того, библиотечные элементы на АБ – это не «черный ящик», их можно легко модернизировать, совершенствовать и дорабатывать под свои задачи, в общем, гибкая вещь…

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

Как я понял, под переносимостью имеется ввиду возможность переносить на разные семейства МК. На AVR в этом плане существенно проще - не надо думать о переносимости.
Не понял, почему вы создаете библиотеки, ведь на СИ они уже должны существовать.
Когда начинал изучать АБ, создал простенькую основную библиотеку, которой до сих пор пользуюсь.
При разработке создаю специфические для данного проекта небольшие подпрограммы низкого уровня – это просто. Дальше уже использую эти подпрограммы и библиотечные элементы, фактически это уже программирование на высоком уровне.

Вы не хотели бы заняться созданием библиотеки для АБ? Эту библиотеку можно будет сделать платной. Конечно, тут много вопросов.

elisey писал(а):
Цитата:
Во-первых, аппаратная реализация быстрее.

Быстрее всегда лучше? Скорость не должна быть "быстрее", она должна быть "достаточной для выполнения задачи". В некоторых случаях медленнее (об этом ниже). Из минусов аппаратных реализаций - это негибкость и дороговизна. Из примера можно взять реализацию сетевого стека. Аппаратный MAC и софтовый TCP/IP дешевле и гибче полностью аппаратного решения.

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

elisey писал(а):
Микросхемы тоже кишат глюками, и проблема в том, что в кремнии ошибки сложнее исправлять. Посмотрите на тот же enc28j60. Добрая половина функционала недоступна из-за ошибок.

Насчет того, что «микросхемы кишат глюками» - я бы так не сказал.
На мой взгляд, как раз из-за того, что в кремнии сложнее исправить, профессионалы тщательно отлаживают микросхему перед запуском.
Я практически не сталкивался с проблемными микросхемами. Базовые функции они выполняют хорошо. Если и есть ошибки – то это какие-нибудь тонкие нюансы.
Скажем, те же МК AVR.
Насчет enc28j60 – не понятно, как такое получилось. Может быть, у них там социализм внедрили и гнали в конце месяца план.

elisey писал(а):
Цитата:
Скажем, плату преобразователя USB-COM купил по цене около 40 рублей, правда, до скачка доллара.

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


Насчет того, что встроенный в МК USB бесплатный – это вопрос. Стоимость USB, скорее всего, включили в стоимость МК. К тому же в этом случае придется применять МК с USB – это резко ограничивает выбор МК.
У USB вроде бы нет гальванической развязки, тогда такое решение имеет очень ограниченное применение.

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

Слишком широкие это области - электроника и программирование. Чтобы разработчик и там, и там был профессионалом – это, наверно, редкое сочетание.
В этом плане АБ – очень удобный язык, позволяет электронщику без проблем применять МК.
Электронику должен делать электронщик. Для проекта, скажем, на ATmega8 пригашать второго специалиста расточительно. А электронщик с АБ сделает такой проект без проблем.

elisey писал(а):
Цитата:
А электронщику, занятому в серьезном проекте, некогда изучать массу всяких языков.

Самообразованием нужно заниматься всегда. Порою нужно притормозить и пошире изучить свою область. И тогда привычную работу можно будет выполнять намного быстрее

Хорошее пожелание. Но для меня это пока нереально.
В контексте этой темы – сомнительно, что СИ сейчас хоть как-то ускорит мою работу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 17 авг 2015, 03:40 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3996
Alexandr_1 писал(а):
Насчет того, что «микросхемы кишат глюками» - я бы так не сказал.
На мой взгляд, как раз из-за того, что в кремнии сложнее исправить, профессионалы тщательно отлаживают микросхему перед запуском.
ну да, ну да. берешь почти любой мк, открываешь еррату и... видишь баги в тривиальнейших интерфейсах типа spi. профессионалы. тщательно отлаживают. что говорить о более сложных вещах? там обязательно будут косячки, и если повезет - незначительные. стойкое ощущение, что вы из какой-то другой галактики:)
Alexandr_1 писал(а):
Для проекта, скажем, на ATmega8 пригашать второго специалиста расточительно. А электронщик с АБ сделает такой проект без проблем.
тогда можно взять ардуину с готовым скетчем. вообще электронщик не нужен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 24 авг 2015, 14:31 
Старожил
Аватара пользователя

Зарегистрирован: 22 июл 2014, 13:20
Сообщения: 325
Откуда: правая юрта тундры
Глазам не верю: 45 страниц ругать среду - а вот он - металлоискатель, что я давно искал ...
http://tilikum.narod.ru/vers1.html


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 24 окт 2015, 02:58 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 399
Ink писал(а):
Alexandr_1 писал(а):
Насчет того, что «микросхемы кишат глюками» - я бы так не сказал.
На мой взгляд, как раз из-за того, что в кремнии сложнее исправить, профессионалы тщательно отлаживают микросхему перед запуском.
ну да, ну да. берешь почти любой мк, открываешь еррату и... видишь баги в тривиальнейших интерфейсах типа spi. профессионалы. тщательно отлаживают. что говорить о более сложных вещах? там обязательно будут косячки, и если повезет - незначительные. стойкое ощущение, что вы из какой-то другой галактики:)

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

Я из галактики разработчиков.

Alexandr_1 писал(а):
Для проекта, скажем, на ATmega8 пригашать второго специалиста расточительно. А электронщик с АБ сделает такой проект без проблем.
тогда можно взять ардуину с готовым скетчем. вообще электронщик не нужен.[/quote]

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

В плане сравнения АБ и СИ.
Кто-нибудь может сказать, какой объем на СИ занимает программа для расчета десятичного логарифма и какое время расчета логарифма (в тактах МК). Скажем, аргумент может меняется в диапазоне от 1 до 100 с дискретностью 1/256, точность расчета логарифма не хуже 1 %.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 24 окт 2015, 22:16 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3996
Alexandr_1 писал(а):
Я из галактики разработчиков.

*альтернативных разработчиков.
Alexandr_1 писал(а):
Ничего не знаю ардуину. Плохо представляю, как не электронщик будет разрабатывать электронику.
он не будет. электроника уже разработана профессионалами.
Alexandr_1 писал(а):
Кто-нибудь может сказать, какой объем на СИ занимает программа для расчета десятичного логарифма и какое время расчета логарифма (в тактах МК). Скажем, аргумент может меняется в диапазоне от 1 до 100 с дискретностью 1/256, точность расчета логарифма не хуже 1 %.
абстрактный вопрос - абстрактный ответ: на профессиональном компиляторе программа получится качественнее, так как функции логарифма напишут профи. причем, пользователю, чтобы получить быстрый или короткий логарифм надо всего лишь ключ у компилятора поменять, а АБшнику - переписать всю функцию полностью. заодно рекомендую время написания программы учесть. 1 минута против пары дней.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Алгоритм билдер (описания, без программ)
СообщениеДобавлено: 25 окт 2015, 00:42 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 399
Ink писал(а):
Alexandr_1 писал(а):
Я из галактики разработчиков.

*альтернативных разработчиков.

Не слышал про альтернативных разработчиков. Это кто такие?

Alexandr_1 писал(а):
Ничего не знаю ардуину. Плохо представляю, как не электронщик будет разрабатывать электронику.
он не будет. электроника уже разработана профессионалами.
[/quote]

Вы говорите о работе, где нужны чисто программисты. Я же говорю о работе, где требуется разрабатывать электронику и программы для МК. Это, наверное, более распространенная работа.

Alexandr_1 писал(а):
Кто-нибудь может сказать, какой объем на СИ занимает программа для расчета десятичного логарифма и какое время расчета логарифма (в тактах МК). Скажем, аргумент может меняется в диапазоне от 1 до 100 с дискретностью 1/256, точность расчета логарифма не хуже 1 %.
абстрактный вопрос - абстрактный ответ: на профессиональном компиляторе программа получится качественнее, так как функции логарифма напишут профи. причем, пользователю, чтобы получить быстрый или короткий логарифм надо всего лишь ключ у компилятора поменять, а АБшнику - переписать всю функцию полностью. заодно рекомендую время написания программы учесть. 1 минута против пары дней.[/quote]

Почему абстрактный вопрос? Какой объем программы и время выполнения получится при заданных условиях – мне вопрос представляется вполне конкретным. У меня возникла такая задача.
Можно привести значения для короткого и длинного логарифма.
СИшник напишет-то за минуту, но потом, как я тут читаю, будет неделю искать ошибку.
АБшник потребуется время только один раз написать, потом вызов функции – тоже одна минута. Что-то поменять – зачем всю функцию переписывать?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 1181 ]  На страницу Пред.  1 ... 42, 43, 44, 45, 46, 47, 48  След.

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB