Тест 8-ферзей на Ардуино-BASIC недокомпьютере

Submitted by Vitasam on вс, 11/03/2018 - 00:32

Сделал тест бенчмарка 8-Ферзей на ардуино-шилде:
basic

1 A=8
2 B=0
3 C=0
4 DIM Q(9)
5 C=C+1
6 Q(C)=A
7 B=B+1
8 D=C
9 IF (D-1)<=0 THEN GOTO 24
10 D=D-1
11 R=Q(C)-Q(D)
12 IF R>=0 THEN GOTO 15
13 T=-R
14 GOTO 16
15 T=R
16 Y=C-D
17 IF R<>0 AND Y<>T THEN GOTO 9
18 B=0
19 Q(C)=Q(C)-1
20 IF Q(C)<>0 THEN GOTO 9
21 C=C-1
22 Q(C)=Q(C)-1
23 GOTO 20
24 IF B<>1 THEN GOTO 7
25 IF C<>A THEN GOTO 5
26 PRINT Q(1);Q(2);Q(3);Q(4)
27 PRINT Q(5);Q(6);Q(7);Q(8)

Результат: 3.4 секунды.

Это означает, что Ардуино-недокомпьютер примерно в 2.2 раза быстрее МК161 и находится между TI-NSpire и HP-48GX (последний под кросс-компилятором GCC... WHAT?!!):

- 4.20 TI-Nspire CAS Formula / List / OS 1.3
-
- 4.18 DM-42 Keystroke / RPN
-
- 3.90 TI-Nspire Formula / List / OS 1.3
-
- 3.37 HP-48GX HP48XGCC / Structured / Cross Compiler
-
- 3.30 HP-200LX QBasic 1.1 / DEFINT / Bytecode

Тестовые
Другие ПМК

Комментарии

Изображение пользователя Электромонтёр.
Submitted by Электромонтёр on вс, 11/03/2018 - 09:02

По даташиту, микроконтроллер МК-161 выполняет машинный цикл за четыре такта, то есть его быстродействие при 22МГц порядка 5,5 млн. оп./с а микроконтроллер ардуины выполняет машинный цикл за один такт и на тактовой частоте 16МГц его быстродействие как раз 16 млн. оп./с. Итого 16/5,5=2,91, теоретически твой микрокомпьютер должен быть быстрее МК-161 почти втрое. Поскольку прошивка МК-161 написана на чистом ассемблере, а микрокомпьютера на gcc(?), то получается, эффективность кода на уровне 75% от ассемблерного при на порядок меньшей трудоёмкости написания. Однозначно респект!

Сайт

Изображение пользователя Vitasam.
Submitted by Vitasam on вс, 11/03/2018 - 11:23

Хотя сравнение не совсем честное - все-таки в МК161 двоично-десятичная арифметика, а тут обычный Float.
Но, тем не менее, компилятор против ассемблера :)

Submitted by KPG on вс, 11/03/2018 - 12:57

например такой кристалл Nuvoton https://direct.nuvoton.com/ru/n76e003at20
(бывший Winbond)

Изображение пользователя Vitasam.
Submitted by Vitasam on пн, 12/03/2018 - 16:36

N76E003 – a 1T-8051 based series MCU, offers 18 KB Flash ROM, configurable Data Flash and 1 KB SRAM

Почти в 2 раза меньше флеша и в 2 раза - оперативки (по сравнению с atmega368p).
Бэйсик этот не влезет

Submitted by AtH on вт, 13/03/2018 - 02:29

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

Бейсик не самый лучший язык для карманной машинки. МК-85 позволял писать программы, и я это делал, но такого энтузиазма не вызывал. Слишком уж расточительно расходуют длинные ключевые слова Бейсика крохотный экранчик ПМК. Логика программы видна только на настольном мониторе, это не компактный язык.

Submitted by Ватник on вт, 13/03/2018 - 08:29

Сам язык МК и даже Форт имеют компактные слова, но низкий уровень абстракции не позволяет компактно записывать алгоритмы. Например Бейсик имеет спец. синтаксис и вообще понятие массивов, в том числе многомерных. Насколько дольше париться на низкоуровневом языке!

Submitted by AtH on вт, 13/03/2018 - 09:13

В Форте массивы есть. Уровень Форта меняется — начиная от уровня Бейсика и подстраиваясь под задачу. Бейсик же деревянный. Как начал с уровня массивов, так и сиди на нём до конца решения задачи.

Для тех, кто умеет программировать (в том числе меня) это значительное преимущество. Де факто задачи решаются за логарифм времени — выразительность используемых языковых конструкций растёт экспоненциально.

Изображение пользователя Vitasam.
Submitted by Vitasam on вт, 13/03/2018 - 09:51

BASIC - это "тёплый ламповый" аспект карманного 8-битного компьютера на батарейке. Тёплость и ламповость тут ключевые слова. Входной порог Бэйсика на уровне плинтуса, по сравнению с Фортом.

Submitted by Ватник on вт, 13/03/2018 - 13:24

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

Изображение пользователя Vitasam.
Submitted by Vitasam on вт, 13/03/2018 - 15:07

Другой вопрос, если за клавиатурой не тупой непрограммирующий юзер, а человек умеющий строить уровни абстракций, ему то в рамках Барсика будет тесновато.

Несомненно! И тогда такой продвинутый человек сделает новый шилд на основе esp32 или stm32 и запортирует туда что угодно :)

Submitted by AtH on вт, 13/03/2018 - 17:18

Повторюсь. Новичкам Бейсик хорош по двум причинам. 1. Много литературы и старших товарищей. 2. 20-25 строчек экрана, позволяющих видеть несложные алгоритмы без утомительного для новичков скроллинга.

Второй пункт на экранчике в 1-2 строчки не получается. И даже 128x64 не позволяет новичку так удобно программировать на Бейсике, как десктоп.

Каллисто специально разработана так, чтобы полноценное определение слова размещалось на одном экране полностью. А то и несколько таких определений! Храним заветы Трохименко. Слова тоже короткие. Например, точка (одно нажатие) вместо PRINT (пять нажатий, а кнопки ещё искать надо).

Изображение пользователя Vitasam.
Submitted by Vitasam on вт, 13/03/2018 - 17:28

Когда у меня в свое время появилась МК85, то ПМК был задвинут в очень дальний ящик сразу. Одна строчка Бейсика была удобнее, чем ассемблерный индикатор ПМК.

Submitted by AtH on вт, 13/03/2018 - 19:49

Индикатор удобней, не спорю. А программы писать для МК-85 мне в своё время не понравилось. Слишком пресно и скучно. Я искал развитие языка в сторону Форта, ещё в то время. Чтобы можно было определять новые слова — и тут же их использовать.

Изображение пользователя Электромонтёр.
Submitted by Электромонтёр on вт, 13/03/2018 - 21:35

Тогда компромиссом будет однокнопочный ввод команд как в Спектруме:
ZX-spectrum

Сайт

Изображение пользователя Vitasam.
Submitted by Vitasam on вт, 13/03/2018 - 22:01

удастся прикрутить SPI SRAM для нужд бейсика (освободится как минимум полкило оперативки)

Submitted by AtH on ср, 14/03/2018 - 06:03

Меня клавиатура Спектрума бесила. После Ямахи счёл её крайне неудобной. Хотя и написал с её помощью достаточно сложную программу.

Множество клавиш с четырьмя-пятью смыслами это плохое решение. У нас и так на клавишах висят русские и английские буквы двух размеров, а в случае калькулятора ещё и цифры. При подходе Спектрума и МК-85 появляются ключевые слова FOR LIST PRINT — в Каллисто же написано на клавише «:», и она вводит слово «:». Разгружает клавиатуру и голову. Главное же, что PRINT занимает на скромном индикаторе ПМК больше места, чем точка — как его не вводи.

BASIC имеет право на существование, особенно для привлечения новичков. Им кажется, что на Бейсике будет просто программировать. Но на Каллисто вводить новый код и просматривать уже существующий быстрей и удобней, язык специально разрабатывался под калькулятор.

Ватник тут настойчиво впиаривает, что Форт это якобы «низкий уровень». Но это лишь от поверхностного знакомства с Фортом. Логика «что для меня сложно, то низкий уровень». На деле же сложно всё, что не изучал. Форт требует меньше времени на изучение, чем Бейсик, и проще в использовании. А когда вкладываешь больше сил в изучение Форта — он предоставляет больше возможностей, чем другие языки программирования.

Submitted by Ватник on чт, 15/03/2018 - 10:38

Форт мне нравится потому что он является метаязыком, который можно надстраивать. Но сам по себе он ОБЪЕКТИВНО является языком низкого уровня, причём довести его до уровня большей части высокоуровневых языков без существенной мутации его среды выполнения не получится (вряд ли на галимой реализации Форта вы сделаете полноценный Хаскель :-)

Как правило языки низкого уровня в умелых руках предоставляют "больше возможностей", чем другие языки программирования, потому что на языке низкого уровня вы как правило можете сделать ЧТО УГОДНО, но не на каждом высокоуровневом языке можно написать DOOM или СУБД. К сожалению вопрос применения метаязыков с выращиванием необходимых абстракций за >40 лет существования Форта и других расширяемых языков остаётся уделом горстки энтузиастов.
В этом для ПМК мечты как бы шанс на некую новизну и самобытность :-) Только юзеру и даже программисту из коробки хотелось бы уже дать выращенный уровень повыше базового Форта. Чтоб ему не пришлось самому изобретать: строки, массивы, матрицы, структуры, динамические сложные древообразные структуры (управление памятью и удобное представление) и т.д.

Изображение пользователя st.
Submitted by st on ср, 15/01/2020 - 14:28

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

Submitted by Ватник on вт, 13/03/2018 - 13:19

Язык не обязан быть низкоуровневым, чтобы быть метаязыком. Бейсик (классический) конечно же дубовое гамно, но может хорошо пригодиться как уровень какого то метаязыка, который к тому же можно нарастить.

Submitted by KPG on вт, 13/03/2018 - 13:39

и где та грань отнесения языка к низкоуровневым или нет :)

http://my-cellar-door.blogspot.ru/2005/08/forth.html Кратко о плюсах языкового Форт подхода.

P.S. И как тогда понимать "мета" свойства для Бейсик языка?

Submitted by Ватник on чт, 15/03/2018 - 10:45

Все языковые конструкции и семантика жёстко вмонтированы в Бейсик, никаких мета свойств у него нет. То есть у него нет языковых конструкций позволяющих изменять или дополнять сам язык. Метаязык, это язык, позволяющий перепрограммировать его синтаксис и семантику - например реализовать встроенный Пролог или добавить новую конструкцию организации цикла, специальную объектную систему и т.д. и т.п.

Я знаю только два хорошо известных языка, способных на это в полной мере - Forth и Lisp (может быть Nemerle и другие языки с процедурными макрами могут ???).
Даже JavaScript и Lua не смотря на крайнюю гибкость не позволяют внести встроенный язык внутрь своего синтаксиса.

Submitted by KPG on чт, 15/03/2018 - 11:10

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

P.S. Большие проекты (подобные Wn32Forth и др. Форт системам), а также всевозможный полезный код на них
не характеризует Форт язык, как только для чтения. Даже на ассемблере с его макросистемой создают и поддерживают сложный код.

Submitted by Ватник on чт, 15/03/2018 - 12:15

высоко(низко)уровневость языка и его гибкость - вообще не связанные (ортогональные) категории.
"Всё можно добавить" - это не то же самое "поставляется стандартно из коробки в отлаженном виде". Вот вам машкод и мучайтесь с ним для написания современной версии DOOM, может быть вам повезёт и слепите пол компилятора Си (или даже С++) и на нём допишете свою нетленку раньше чем вас разобьёт старость. :-)

Большие проекты на Форте ??? Это наверное в той всленной где R2D2 и C3PO (недаром Йода говорит как фортер :-) Но в нашей вселенной больших проектов на Форте ещё никто не смог сделать. "Wn32Forth" - это сама среда Форта ? :-)

Никто и не говорит, что Форт это язык только для чтения, но по объективным причинам он к нему стремится со страшной силой :-) На ассемблере СОЗДАВАЛИ когда то и поддерживали относительно сложный код, но скорее всего небольшой по функционалу и объёму, ибо экономически не обоснованно тратить время больше чем на 20% кода программы, который представляет собой главный затык по производительности. Сегодня вообще не понятно зачем это кому то может понадобиться ??? Нормальный человек и ядро ОС не станет писать на ассемблере. Это означает, что писать всю систему на Форте будет только маньяк, для того чтобы он стал пригодным для больших проектов надо его нарастить до более высокоуровневого языка, будет ли он по сути Фортом - это большой вопрос !

А если подчеркнуть суть, то камень вовсе не в огород Форта и вообще не о холиварах. Вопрос в том, как должен выглядеть некий идеальный язык для ПМК(ЭКВМ), который бы сходился и для низкоуровневых вещей и мог быть наращен до пользовательского уровня ? Такой пример есть, очень близкий к Форту - это SysRPL -> UserRPL, но там из-за нехватки ресурсов и другим причинам сделали слишком специфические языки со страшными тараканами в голове :-)
Хотелось бы подъёма плавнее типа: Форт -> Форт помощнее с батарейками -> Почти уже не Форт для программистов платформы (смахивающий на Лисп и др.) -> Могучий числодробильный юзерский язык аля Matlab -> Созданный юзером DSL

Submitted by KPG on вт, 13/03/2018 - 09:55

в Форте можно, например, записать и так "частный" случай сравнения двух строк вместо использования стандартного слова compare.
\ ( adr len - adr len flag ) исходная строка остаётся для последующего сравнения.
over @ [ s" xxxx" drop @ lit, ] =
те 4-е байта сравнимой строки извлекаются как число и сравниватся с четыремя байтами-литералом шаблона.

P.S. Сколько ещё "хаков" можно изобразить с помощью Форт? :)
Полезна к прочтению "Способ мышления - Форт язык и философия для решения задач" Добавил к книгам о Форт в Web архив хранилище https://archive.org/details/Broudie2 по Форт языку.

Submitted by Ватник on чт, 15/03/2018 - 12:23

...встроена в язык с чётко понятной библиотекой операций над ними. В идеале язык должен иметь понятие "последовательности" и обобщённые конструкции итераций по ним, куда должны входить и строки. Речь не идёт о языках, предназначенных для чётко заточенных операций, например если язык только для числодробления, там строки конечно не нужны.

Submitted by A.L. on вс, 11/03/2018 - 18:42

Удивительно быстро.
Особенно клавиатура классная.

www.avl.by

Изображение пользователя Vitasam.
Submitted by Vitasam on пн, 12/03/2018 - 11:13

не самая удобная, но допустимый компромисс между бюджетностью и удобством. Хотя кнопки надежные.
А скорость Бэйсика угу, порадовала.

Изображение пользователя Vitasam.
Submitted by Vitasam on вт, 18/12/2018 - 14:58

Несмотря на успешность портирования Ардуино-Бейсика на STM32 восьмибитность AVR-ок всё-таки притягивает. Вдобавок в мусоре нашлась вполне рабочая PS2 клавиатура маленького формата (что-то индустриальное от приборов). Уровень тёплой ламповости от набора Бейсика на такой клавиатуре (по сравнению с кнопками на вышеупомянутой stm32 самоделке) зашкаливает :)

В общем, возвращаюсь к истокам:
AVRbasic p2s keyboard

Если влезет в atmega328p, то хотелось бы еще SD-карточку. И батарейный отсек на две "АА" батарейки. И напечатать корпус на 3д принтере. Вот только нет никаких идей о возможном форм-факторе.
kbd

Изображение пользователя st.
Submitted by st on вт, 18/12/2018 - 16:09

О, у меня тоже подобная клавиатура есть, только бытовая, мини-фактор.

Изображение пользователя Vitasam.
Submitted by Vitasam on вт, 18/12/2018 - 21:25

С PS2 клавиатурами удобно работать из Ардуины - всю "черную" работу делает контроллер самой клавиатуры. Ардуина получает скан-код. Библиотека не очень большая. Работать с ней легко:

// Keyboard
const int KbdDataPin = 8;
const int KbdIRQpin =  3;
PS2Keyboard keyboard;
...
keyboard.begin(KbdDataPin, KbdIRQpin);
...
        while (keyboard.available())
        {
...
            char c = keyboard.read();

В ардуину идет два провода (не считая +5V, GND)

Submitted by AtH on ср, 19/12/2018 - 02:32

А через последовательный порт МК-161 удобно будет? Каллисто полноразмерная клавиатура не помешает.

Изображение пользователя Vitasam.
Submitted by Vitasam on ср, 19/12/2018 - 09:13

Не уверен. К Raspberry Pi, к порту Rx, клавиатуру цепляли:
https://sites.google.com/site/mincepi/m2pi

Но там linux kernel module модифицирован для поддержки - PS2 протокол не UART протокол, стандартное UART железо, может, не сможет принимать.

Изображение пользователя Vitasam.
Submitted by Vitasam on пт, 21/12/2018 - 11:54 
Увы, поддержка SD-карточки не влезает в Ардуину с Бейсиком:
Sketch uses 27918 bytes (86%) of program storage space. Maximum is 32256 bytes.
Global variables use 2383 bytes (116%) of dynamic memory, leaving -335 bytes for local variables. Maximum is 2048 bytes.

Попробую уйти от Ардуино IDE в чистый avr-gcc. Из спортивного интереса не хочется переползать на stm32

UPDATE: полный комплект хотелок (этот Бейсик с плавающей точкой и полноценная SD-карточка) не влезают в ардуину и в avr-gcc.

Submitted by KPG on чт, 20/12/2018 - 22:31

https://zx-pk.ru/forums/95-programmiruemye-kalkulyatory.html

P.S. Литература по ZX-Spectrum https://vtrd.in/book.php

Submitted by KPG on чт, 02/01/2020 - 22:40

https://usamodelkina.ru/16524-kalkuljator-s-bejsikom.html

Изображение пользователя Vitasam.
Submitted by Vitasam on пт, 03/01/2020 - 01:02

Да, я этот бейсик и использовал в своих экспериментах. Вот мой пулл-реквест в его гитхаб, но не пригодилось (с) :)

Submitted by AtH on пт, 03/01/2020 - 03:24

Даже обычный Форт, без каллистянских технологий, на Ардуино уже был бы куда полезней этого чуда. Должен же на Ардуино быть eForth, например. Прямо в голом виде eForth полезней при работе «на весу», а с библиотекой плавучки — полноценный калькулятор.

Бейсик — многословный язык с минимальными возможностями к расширению. В компактных устройствах неудобен и полезен разве что тем, кто кроме Бейсика ничего в жизни не видел и не нюхал. Его эпоха — полноразмерная клавиатура на столе и дисплей на 20+ строк, в таких условиях язык идеален для начинающих.

Это проект из серии «смотри мама, что я могу». Наверняка даже сам автор разработки этим «калькулятором с Бейсиком» не пользуется. Поэтому устройство и не доведено до готового продукта, как МК-161 и HP-50g. Осталось уникальным клубком проводов на столе разработчика.

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

Изображение пользователя Vitasam.
Submitted by Vitasam on пт, 03/01/2020 - 10:41

Клавиатура в этом проекте сама сделана на atmega328p контроллере,если я не ошибаюсь. Немного жирновато для калькулятора иметь клавиатурный процессор той же мощности :)

Так что да - это из серии "я вон чего могу", а не законченное устройство.

Submitted by AtH on пт, 03/01/2020 - 12:06

Я больше про саму идею физических кнопок, да ещё в таком десктопном количестве. С обычной раскладкой, рассчитанной на слепую печать двумя руками. Это даже смешней, чем десктопный входной язык, заточенный под текстовые терминалы 80×25.

Мощность процессора имеет значение в национальных проектах. Например, если делать русский ПМК, ограничиваясь процессорами отечественной архитектуры, придётся выжимать максимум из каждого мегагерца.

Если создаёшь американский или «международный» ПМК, в мощности ничто не ограничивает. Выходишь на естественные ограничения — размер и количество пальцев, ширина ладони, острота зрения и т.п.

Изображение пользователя Vitasam.
Submitted by Vitasam on сб, 04/01/2020 - 17:07

А какой из фортов лучше всего на Arduino atmega328p?

Submitted by KPG on вс, 05/01/2020 - 03:46

При всём многообразии имеющихся Форт для Ардуино (amForth, FlashForth, eForth ... SwiftForth ..)
они продолжают изобретаться под личное понимание применения, как пример проект https://github.com/oco2000/AVRForth (было обсуждение на рускоязычном Форт-форуме)
или бывает используются для замены ассемблера для AVR https://github.com/ivanivanovo/AVR

P.S. Мне в своё время понравился подход реализованный в FF303 http://www.cqham.ru/forum/showthread.php?8188-------AVR-- (сборку этого Форта делал в более поздней версии системы Win32Forth для системы команд с PDP-11)
т.е. лучший, в моём понимании, это комплексный Форт инструмент пригодный для использования с широкой номенклатурой AVR и не только контроллеров в разных вариантах решений Форт и создающим некоторую инфраструктуру для его всестороннего понимания и применения.
Вплоть до такой экзотики как http://fminus.sourceforge.net/ (а ещё же есть, например и FPGA и Форт к ним)

Хотя, например,amForth собирал для atmega162 (как наиболее популярный и развивающийся проект, урезав в варианте до ~8Кб)
eForth есть здесь http://forth.org/OffeteStore/OffeteStore.html и на Github
The Arduino Controlled By E Forth
The ATTINY Project 2018

Если Форт будет иметь решения по JIT компиляции в контроллере, то тоже неплохо, но оптимально, конечно, иметь уже заточенный аппаратно контроллер под использование с Форт.
Что и как наращивать поверх Форт базиса это ещё один отдельный вопрос :) (можно запустить разные шахматы сделанные на Форт)

P.P.S. Попутная новость
На днях вышел №29 Журнал "Downgrade": http://dgmag.in/N29/DowngradeN29.pdf (Тема номера - "Компьютерный андеграунд").

Ну, а по форту есть и такая дискуссия:) "Почему обречён Форт" http://www.compiler.su/pochemu-obrechyon-yazyk-fort.php

Изображение пользователя Vitasam.
Submitted by Vitasam on вс, 05/01/2020 - 01:27

Спасибо за подробный ответ! Есть что почитать :)

Submitted by KPG on вс, 05/01/2020 - 04:05

По Форт на Веб-архиве есть ещё книги и журналы.

P.S. Попутно встретил и может чем то интересно будет к ознакомлеию Учебник визуальное программирование 2018 (на форуме сайта по "языку" Дракон)

Submitted by AtH on вс, 05/01/2020 - 05:26

Интересно, что хейтеры Форта достаточно разбираются в теме, чтобы видеть перспективность Форта для наших применений:

А сколько было у Форта шансов? Последний из них — это волна мобильных устройств, где были востребованы свойства именно Форта: компактность, «автономность» и «независимость» от ОС (и потенциальная способность заменить собою эту ОС).

За Фортом не стоит крупного капитала, который предпочитает финансировать и поддерживать собственнические языки своей разработки: Джава, Сишарп и т.п. Но пригодность и выгодность Форта для калькуляторов и других карманных/мобильных устройств очевидна.

Изображение пользователя st.
Submitted by st on пт, 03/01/2020 - 12:06

В оригинале статья называается "Маленький карманный компьютер с Бейсиком" (A Small and Cheap Pocket Computer That Can Be Programmed Anywhere)

Изображение пользователя Vitasam.
Submitted by Vitasam on пт, 03/01/2020 - 15:05

Позиционирование этого самодельного устройства - да, карманный компьютер. Так же, как и мои попытки ранее в моем блоге. Я согласился с уважаемым AtH в том, что устройство не тянет на законченное, и мне не нравится выбор клавиатуры - не люблю, когда выч.мощности так расходуются впустую :)

Submitted by AtH on пт, 03/01/2020 - 16:55

Если кто-то хэйтит тачскрины, которые очень удобны для карманных устройств, есть решение — клавиатуры виртуальной и дополненной реальности.

Кому так нужны тактильные фидбэки, может таскать с собой хоть пишмашинку. Главное, чтобы переносной компьютер-калькулятор умел считывать по видео, какие клавиши на ней нажимаешь.

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

Да и производство дешевле, устройства получаются проще и надёжней.

Изображение пользователя st.
Submitted by st on пт, 03/01/2020 - 18:06

Сенсорный экран вытеснил клавиатуры только на универсальных массовых портативных устройствах. На профессиональных клавиатуры как были, так и остались.

Submitted by AtH on пт, 03/01/2020 - 18:53

Скорее, на специализированных устройствах — и то вряд ли надолго. Если у устройства ограниченное назначение, относительно просто под него сделать неизменный интерфейс на железных кнопках.

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

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

Изображение пользователя st.
Submitted by st on пт, 03/01/2020 - 20:54

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

Submitted by AtH on пт, 03/01/2020 - 23:58

Чем сенсорный экран плох для пальцев, что значит «убитые пальцы»? Кнопки же требуют нажатия, поэтому на пальцы больше нагрузка. Сенсорный экран требует меньше усилий. Тем более, что появилось много жестов, отличных от нажатия.

Тренеры Покемон Го ловят покемонов с лета 2016 года. У многих по 100 и 200 тысяч поимок, примерно столько же прокруток покестопов. Да, некоторые поменяли 2-3 телефона за эти годы, но большинство проблем из-за плохой работы аккумуляторов на холоде и быстрого морального устаревания мобильников.

Пальцы у всех целы.

Изображение пользователя st.
Submitted by st on сб, 04/01/2020 - 03:01

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

Submitted by AtH on сб, 04/01/2020 - 13:19

Игры — никакого. Но они хорошо тестируют решения на износ и юзабилити.

Если тачскрин норм для фантов-геймеров, круглосуточно трущих телефоны в поисках «того самого» покемона (миллионы жестов в год), тепличные профтерминалы тем более выдержат.

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

Начнут считать деньги, перейдут на тачскрины. Чья цена ещё ниже опустится. В специализированных устройствах, где кнопок немножко, они ещё могут сохраниться.

Изображение пользователя Vitasam.
Submitted by Vitasam on вт, 14/01/2020 - 00:35

Тема перенесена на форум