Какое-то отклонение от темы, и сравнение «теплого» с «мягким».
Понятное дело, что ПЛИС позволяет многие вещи делать совсем иначе, но это никак не связанно с циклами (не понял что Вы под этим подразумеваете, если — такт, то в AVR они так же — гарантированы), как и вход в прерывание клиента, с началом посылки — сервера. Начало посылки в моём случае выполняется сразу (не считая нескольких тактов на инициализацию).
Касаемо калибровочных байт Вы, вероятно видите задачу связи между микроконтроллерами, хотя я настойчиво утверждаю и в статье, и в комментариях к ней, что функции приема и передачи написаны с учетом стандарта.
Моя задача: читать и принимать данные любым терминалом. А это уже не позволяет использовать калибровочные данные.
Если бы я реализовывал связь между микроконтроллерами, я бы точно отказался от UART, в пользу параллельных шин, на нестандартных частотах, с потоковым сжатием, коррекцией и проверкой валидности.
Но это другая задача, и для других контроллеров.
Только не стоит забывать, что расстояния там не очень большие, возможно лучше использовать другие интерфейсы. Есть планы на счет реализации i2c и twi, но пока это размазано и туманно. Хотя есть заказ. В общем — думаю.
Для себя я так и делаю, после того как библиотека прошла тесты и показала полную работоспособность, а пишу так, потому что привычка с тех времен, когда еще не было окон и вкладок. Мне удобно перемещаться по листингу не переключаясь между окнами в маленьких проектах, и считаю, что новичкам так проще не запутаться.
По поводу коммерции — бесспорно, ведь не я придумал протокол обмена, здесь я имел ввиду сам код и его «несвободность». То есть продажу кода как своего личного, любого измененного приложения — как своего, либо в составе собственного продукта в качестве библиотеки, с нарушением авторских прав. Во всех остальных случаях, с соблюдением этикета, вы можете пользоваться так, как считаете нужным, с указанием источника, автора, и исходного кода.
Согласен, объективное замечание. Я много чего хотел написать, в том числе и про испытания. Но 3 часа ночи сыграли против меня в этот раз :)
Поэтому не буду раздувать статью дальше, пусть она останется стихотворением, написанным водой на горячем асфальте, а Вам отвечу здесь:
Грел строительным феном прямо на мини-борде почти до 100 градусов. Больше не рискнул, побоявшись оплавления ABS (температура стеклования 120-140).
При такой температуре передача на 57600 работает без ошибок, 250к — сыпется. Промежуточные не измерял из-за затрудненного процесса прошивки (MiniPro 866A), нужно передергивать чип из борды в программатор и обратно. В перспективе если откопаю USBAsp, который забросил в дальний угол, организую стендик и выполню все покрытие диапазона. Отпишусь.
На счет самосинхронизации: при задержке в стоповом бите, тестируется линия на появление низкого уровня. Если событие произошло — безусловный переход на приём следующего символа, в результате чего, программа оказывается на старте уже через два такта после начала низкого уровня. Дальнейший приём идет с запасом по дрейфу, почти двух-кратным.
Это неверно! Я акцентировал проблему пролога прерывания: пока обрабатывается вход, мы уже в середине стартового бита. А если следом за ним передается нулевой бит, то мы никогда не поймем где граница. HurrTheDurr в этом отношении прав, однако подобные синхронизации требуют дополнительного кода как для клиента, так и для сервера. Выше я так же акцентировал, что синхронизацию можно производить по переходным состояниям линии на границах следования бит (0->1 или 1->0), выходя из цикла задержки заранее. И тогда, даже на высоких скоростях дрейф частоты не окажет влияния (в допустимых нормах).
Приём во время отправки запрещен, в остальном все верно, полнодуплекса нет, да и не нужен он тиньке. Ну и не стоит так категорично — «разве что...», минимальный объем кода, меньше мешает при отладке, например. Понятное дело, что это не для «продакшена», лично мне такая либа сэкономила бы уйму времени однажды. А чего уж говорить о новичках, которые только-только слезли с ардуинки, с целью минимизировать свои проекты. В общем я не претендую на роль первопроходца, я это сказал вначале. Повторюсь: это удобный инструмент, не более того. А цель разработки — спортивная.
Нет, Вы всё поняли неправильно. Я сделал инструмент, а каким образом им пользоваться решает каждый для себя сам. Менеджер отправки может написать любой, кому эта тема интересна и нужна.
Да, этот предмет споров и не дает спокойствия противникам. Могу Вас заверить, такие тесты проводились мной в сторону нагрева. И действительно частота плывет, и правда, что обмен «сыпется», но не на 19200, и даже не на 57600, а там, где стартовый бит почти совпадает с окончанием пролога. У таких скоростей, при такой частоте чипа просто нет шансов остаться в окне передачи. При этом на низких скоростях передачи, отклонение даже на 30% не вызовет серьезных проблем, ввиду допусков самого UART. И скорей всего, Вы не заметили слово — самосинхронизация. Последняя написанная мной версия кода (не входящая в планы), делает этот процесс прямо во время передачи, на границах бит 0->1 и 1->0.
3 цвета, включая оттенки.
3 шрифта, включая размеры.
Затеняя иконки, вы лишаете объект целостности.
Размещая иконки закрытия в непредсказуемых местах, вы порождаете противоречия.
Ну и так далее.
А вобще, что есть "интуитивно-понятный"?
Вот например такой шедевр:
Но тогда второе условие у Вас невыполнимо (в смысле — истинно всегда), либо явно преобразуйте типы в знаковые.
Впрочем мой вариант имеет ту же ошибку :)
Уж если Вы задаёте вопрос, то задавайте его корректно, иначе, в приведенном Вами примере:
unsigned long TmpWait;
TmpWait=GetTimer()+SomeDelay;
while (TmpWait > GetTimer()) ; /* первая строка */
while ((TmpWait - GetTimer()) > 0) ; /*вторая строка */
}
Вы, формализуя физический смысл, неверно описали реализацию.
И конкретно в Вашем примере обе строки неверны:
Первая не отвечает требованиям поставленной задачи, а вторая может впасть в вечный цикл цикл, если SomeDelay>0;
Таким образом Вы не учитываете параметр SomeDelay в обоих вариантах, когда он жизненно необходим для реализации задуманного Вами:
unsigned long TmpWait;
TmpWait=GetTimer()+SomeDelay;
while ((GetTimer()+SomeDelay)>TmpWait) ; /* первая строка */
while ((TmpWait - GetTimer() - SomeDelay) > 0) ; /*вторая строка */
}
Вероятно Вы хотели написать так?
Ну а в этом случае, само собой, необходимо учитывать переполнения, которые приведут к истинности условия №1 многократно, за период таймера, когда второе условие выполнится корректно, даже при переполнении.
Исправьте, если я не прав.
Вы даже сейчас пытаетесь меня унизить, смотря на все происходящее с высоты:
Так вот. Когда подготавливается растр для субпиксельного отображения — антиалиасинг используется.
Я не профан в этой теме, и занимаюсь такими алгоритмами.
Ну что за статья). Ну правда.
Статья человека, который испортил свое зрение на продуктах подобным Вашему.
Или нужно было привести другую статью, на другую тему?
Если Вы ожидали от меня научную работу о вреде эффектов размытия на человеческое зрение, то это не ко мне.
Вам, наверное, трудно пересесть на линукс например.
Вы серьёзно?
Я пытался Вам объяснить, что у Вас зум браузера.
Вы не пытались, сразу начали меня обвинять в нечестности.
Проблема есть, но я думаю, что людям, которые используют браузернй зум будет некомфортно пользоваться сложными веб-приложениями.
Я уже отметил, что раз Вы сравнились с Google и Microsoft, то делайте сравнения честно, ведь с их сервисами у меня нет таких проблем.
Если столько проблем — почему мы рисуем сами?
Это можно было пропустить, я уже сказал на эту тему, и отлично понимаю, почему.
Напоследок отмечу, что работы по улучшению растеризации шрифтов — ведутся. И будут вестись.
В таком ключе можно было сразу ответить, поблагодарив за внимательность, а не оскорблять меня, минусить и выставлять идиотом.
Зачем мне что-то доказывать, когда я описал проблему, описал технологии использованные разработчиком, разработчик признал это, а так же, что такая проблема действительно есть, но они попытаются ее устранить.
Всю информацию которую я предоставил об используемых технологиях, можно без труда усвоить из Интернет.
Из минусов за мой комментарий о том, что антиалиасинг из субпиксельное сглаживание это разные вещи, я сделал вывод, что ставят их либо те, кто ничего в этом не понимает, либо те, кто сознательно пытаются меня «заминусить».
Грамотный читатель, сделает вывод правильно, и отметив моё замечание, сделает для себя вывод.
Разработчик отрисовывает шрифт векторно в канву, подобно буферизации в играх, когда выводимое изображение не сразу выводится на экран, а рисуется в памяти, а затем выводится на экран с фильтрами и эффектами. Здесь, вероятно нельзя сделать иначе, потому что разработка была «заточена» так, либо придется вносить массу изменений, что несомненно неприемлемо разработчиком ввиду удорожания продукта.
А этот момент, уже находится в другой плоскости, называемой «Технологии качества программного обеспечения».
Я же, не критикую, а отметил факт, который для меня стал критическим в выборе продукта. Ни коим образом, не пытаюсь повлиять на чьё-то мнение. Это личное дело каждого — пользоваться, или нет.
Чтобы понять о чем я говорю, не нужно думать, просто взгляните на два примера вверху. Первый — скрин приложения с применением антиалиасинга разработчиками, второй — скрин текста в Google Chrome, снятый с комментариев. После выполнения требований разработчиков (изменение зума браузера), эффект антиалиасинга остался, но он стал мельче ввиду увеличения разрешения отрисовки приложением. Что несомненно уменьшает влияние, но не устраняет его.
Ну согласитесь, зачем мне, ради одного приложения изменять настройки отображения браузера для всех страниц, когда все другие страницы отображаются правильно?
Понятное дело, что ПЛИС позволяет многие вещи делать совсем иначе, но это никак не связанно с циклами (не понял что Вы под этим подразумеваете, если — такт, то в AVR они так же — гарантированы), как и вход в прерывание клиента, с началом посылки — сервера. Начало посылки в моём случае выполняется сразу (не считая нескольких тактов на инициализацию).
Касаемо калибровочных байт Вы, вероятно видите задачу связи между микроконтроллерами, хотя я настойчиво утверждаю и в статье, и в комментариях к ней, что функции приема и передачи написаны с учетом стандарта.
Моя задача: читать и принимать данные любым терминалом. А это уже не позволяет использовать калибровочные данные.
Если бы я реализовывал связь между микроконтроллерами, я бы точно отказался от UART, в пользу параллельных шин, на нестандартных частотах, с потоковым сжатием, коррекцией и проверкой валидности.
Но это другая задача, и для других контроллеров.
По поводу коммерции — бесспорно, ведь не я придумал протокол обмена, здесь я имел ввиду сам код и его «несвободность». То есть продажу кода как своего личного, любого измененного приложения — как своего, либо в составе собственного продукта в качестве библиотеки, с нарушением авторских прав. Во всех остальных случаях, с соблюдением этикета, вы можете пользоваться так, как считаете нужным, с указанием источника, автора, и исходного кода.
Поэтому не буду раздувать статью дальше, пусть она останется стихотворением, написанным водой на горячем асфальте, а Вам отвечу здесь:
Грел строительным феном прямо на мини-борде почти до 100 градусов. Больше не рискнул, побоявшись оплавления ABS (температура стеклования 120-140).
При такой температуре передача на 57600 работает без ошибок, 250к — сыпется. Промежуточные не измерял из-за затрудненного процесса прошивки (MiniPro 866A), нужно передергивать чип из борды в программатор и обратно. В перспективе если откопаю USBAsp, который забросил в дальний угол, организую стендик и выполню все покрытие диапазона. Отпишусь.
На счет самосинхронизации: при задержке в стоповом бите, тестируется линия на появление низкого уровня. Если событие произошло — безусловный переход на приём следующего символа, в результате чего, программа оказывается на старте уже через два такта после начала низкого уровня. Дальнейший приём идет с запасом по дрейфу, почти двух-кратным.
3 шрифта, включая размеры.
Затеняя иконки, вы лишаете объект целостности.
Размещая иконки закрытия в непредсказуемых местах, вы порождаете противоречия.
Ну и так далее.
А вобще, что есть "интуитивно-понятный"?
Вот например такой шедевр:
Вам знаком?
Для меня он — интуитивно-понятен.
Впрочем мой вариант имеет ту же ошибку :)
Вы, формализуя физический смысл, неверно описали реализацию.
И конкретно в Вашем примере обе строки неверны:
Первая не отвечает требованиям поставленной задачи, а вторая может впасть в вечный цикл цикл, если SomeDelay>0;
Таким образом Вы не учитываете параметр SomeDelay в обоих вариантах, когда он жизненно необходим для реализации задуманного Вами:
Вероятно Вы хотели написать так?
Ну а в этом случае, само собой, необходимо учитывать переполнения, которые приведут к истинности условия №1 многократно, за период таймера, когда второе условие выполнится корректно, даже при переполнении.
Исправьте, если я не прав.
Я не профан в этой теме, и занимаюсь такими алгоритмами.
Статья человека, который испортил свое зрение на продуктах подобным Вашему.
Или нужно было привести другую статью, на другую тему?
Если Вы ожидали от меня научную работу о вреде эффектов размытия на человеческое зрение, то это не ко мне.
Вы серьёзно?
Вы не пытались, сразу начали меня обвинять в нечестности.
Я уже отметил, что раз Вы сравнились с Google и Microsoft, то делайте сравнения честно, ведь с их сервисами у меня нет таких проблем.
Это можно было пропустить, я уже сказал на эту тему, и отлично понимаю, почему.
В таком ключе можно было сразу ответить, поблагодарив за внимательность, а не оскорблять меня, минусить и выставлять идиотом.
Всю информацию которую я предоставил об используемых технологиях, можно без труда усвоить из Интернет.
Из минусов за мой комментарий о том, что антиалиасинг из субпиксельное сглаживание это разные вещи, я сделал вывод, что ставят их либо те, кто ничего в этом не понимает, либо те, кто сознательно пытаются меня «заминусить».
Грамотный читатель, сделает вывод правильно, и отметив моё замечание, сделает для себя вывод.
А этот момент, уже находится в другой плоскости, называемой «Технологии качества программного обеспечения».
Я же, не критикую, а отметил факт, который для меня стал критическим в выборе продукта. Ни коим образом, не пытаюсь повлиять на чьё-то мнение. Это личное дело каждого — пользоваться, или нет.