LINUX.ORG.RU

Низкоуровневый язык программирования


0

0

Какие есть низкоуровневые языки программирования под Линь(Кроме Си)? Какие есть толковые ассемблеры? Кто-нить пользовался? Как ощущения?

Просто я хочу заняться низкоуровневым кодингом под Linux, и я хотел бы посмотреть инструментарий.


Ответ на: комментарий от anonymous

>Попробуй оторвать GUI от дебаггера в MSVS, умник. Так, чтоб он из юнит тестов запускался молча.

тебе дать ссылку про юнит-тесты в Qt на QtScript?

>оторвать GUI от дебаггера в MSVS

или ссылку на Rational Robot или аналог, которая сама кнопки нажимает?

man SendMessage

anonymous
()
Ответ на: комментарий от koTuk

>>Error prone, потому что не содержит информационной избыточност

>то что тут написано было гораздо проще и нагляднее написать на assembler,так что даже применение С было излишеством. Как я говорил это для отладки таймингов в реальном времени. Остальные команды аналогичны - далее пойдет надстройка.

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

писал бы конечные автоматы в духе SWITCH, и так бы не геммороился

anonymous
()
Ответ на: комментарий от anonymous

>ну и чо, у тебя тайминги все с потолка или все-таки есть спецификация протокола

http://www.atmel.com/dyn/resources/prod_documents/doc2545.pdf
раздел 27.6 стр. 290

>писал бы конечные автоматы в духе SWITCH, и так бы не геммороился

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

koTuk
()
Ответ на: комментарий от anonymous

Это не имеет никакого отношения к быдлоинтерактивному дебагу, о котором тут так хнычут некоторые низкопрофессиональные личности.

anonymous
()
Ответ на: комментарий от anonymous

> Это не имеет никакого отношения к быдлоинтерактивному дебагу,

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

anonymous
()
Ответ на: комментарий от koTuk

>раздел 27.6 стр. 290

ну то есть, есть процесс и параметры, а не шаманство и black fuckin magic?

>В данном случае геморрой это как раз то что ты предлагаешь. Если у тебя иное мнение - приведи пример как бы сделал ты.

а если понадобится второй процесс запустить параллельно? нужна будет уже микроRTOS.

Я бы написал микроядрышко, которое бы мультиплексировало ресурсы и исполняло формализованные, верифицированные, семантически целостностные конечные автоматы, представляющие процессы.

anonymous
()
Ответ на: комментарий от koTuk

чем не нравится конкретно этот код. nopы и задержки в delay --это black fuckin' "magic numbers", которые вычисляются в зависимости от тактовой конкретного контроллера. уже на этом уровне в спецификации протокола -- одно, в реализации -- другое.если это quick'n'dirty прототип и портирования не предполагается, и портирования не предполагается, то сойдёт, иначе -- "ССЗБ грабли заминировал".

anonymous
()
Ответ на: комментарий от anonymous

>чем не нравится конкретно этот код. nopы и задержки в delay --это black fuckin' "magic numbers", которые вычисляются в зависимости от тактовой конкретного контроллера. уже на этом уровне в спецификации протокола -- одно, в реализации -- другое.если это quick'n'dirty прототип и портирования не предполагается, и портирования не предполагается, то сойдёт, иначе -- "ССЗБ грабли заминировал".

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

koTuk
()
Ответ на: комментарий от koTuk

>раздел 27.6 стр. 290

27.7.1, 27.7.4, 27.7.5. Это фактически спецификация на семантически полном языке программирования (псевдокоде). А у тебя с magic numbers -- дыра в семантике и не мобильный код (на другой контроллер такого же семейства)

Теперь представь, что вместо красноглазовово одноразовово кода на асм ты бы написал компилятор с этого языка в "целевой микроконтроллер". И "движок", который исполняет, что нагенерировал этот компилятор. (на форте, си, асме, форт+конечные автоматы -- не важно)

В итоге, можно было бы запросто перенести основной проект на другой микроконтроллер, с другим алгоритмом "параллельного программирования" (на PIC, например, ЕМНИП, другой).

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

И развивать было бы проще: понадобится второй процесс, многозадачность -- появится "ОС", изменится "бекенд", но модель останется той же самой, из той же самой спецификации.

anonymous
()
Ответ на: комментарий от koTuk

>nop в данном случае не для задержки а для учета особенности работы портов ввода-вывода -

и там и там (с delay)-- задвижка чтобы медленный порт успевал отработать.

>Точность _delay_ms обеспечивается компилятором - достаточно указать частоту генератора на которой будет работать микроконтроллер.

Нифига себе басню сократили ^U -- а в PIC надо было вручную подбирать и задержки и количество nop'ов. По-любому, это сильно завязано на реализацию, на конкретный контроллер

anonymous
()
Ответ на: комментарий от anonymous

Идею я понял. Это займет много времени тем более для меня - я же электроникой в качестве хобби занимаюсь.

koTuk
()
Ответ на: комментарий от anonymous

>Нифига себе басню сократили ^U -- а в PIC надо было вручную подбирать и задержки и количество nop'ов. По-любому, это сильно завязано на реализацию, на конкретный контроллер

Не совсем понял о чем тут. avr-gcc вычисляет количество nop и строит конструкции из вложенных циклов если требуется сам - если встречает _delay_ms ему надо явно указывать либо в командной строке либо в исходниках частоту target. От PIC я отказался - при том же функционале они стоят намного дороже, хотя раньше использовал только их. Чтобы не быть голословным близкий по функционалу pic16f876a стоит порядка 150 руб, atmega48 - 40 руб. И тем более в linux есь опенсорсный бесплатный avr-gcc который очень хорошо поддерживается огромным комьюнити - не припомню нормальный (не урезаный и не глючный) C бесплатный для PIC.

koTuk
()
Ответ на: комментарий от koTuk

> avr-gcc вычисляет количество nop и строит конструкции из вложенных циклов если требуется сам - если встречает _delay_ms ему надо явно указывать либо в командной строке либо в исходниках частоту target.

хм, не знал, тогда это вообще сказка. А то я с PIC начинал, ну и увидел что-то знакомое. И как же потом код проходилось рихтовать , когда понадобилось перенести на другой контороллер :)

anonymous
()
Ответ на: комментарий от anonymous

>хм, не знал, тогда это вообще сказка. А то я с PIC начинал, ну и увидел что-то знакомое. И как же потом код проходилось рихтовать , когда понадобилось перенести на другой контороллер :)

Вот для примера тест.

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
    DDRB = 0xFF;
    PORTB = 0xFF;
    _delay_ms(3);
    PORTB = 0x00;
}

Вот то что avr-gcc сгенерировал с флагом  -DF_CPU=1000000UL 

int main(void)
{
  6c:   cf ef           ldi     r28, 0xFF       ; 255
  6e:   d2 e0           ldi     r29, 0x02       ; 2
  70:   de bf           out     0x3e, r29       ; 62
  72:   cd bf           out     0x3d, r28       ; 61
    DDRB = 0xFF;
  74:   8f ef           ldi     r24, 0xFF       ; 255
  76:   84 b9           out     0x04, r24       ; 4
    PORTB = 0xFF;
  78:   85 b9           out     0x05, r24       ; 5
 */
void
_delay_loop_2(uint16_t __count)
{
        __asm__ volatile (
  7a:   8e ee           ldi     r24, 0xEE       ; 238
  7c:   92 e0           ldi     r25, 0x02       ; 2
  7e:   01 97           sbiw    r24, 0x01       ; 1
  80:   f1 f7           brne    .-4             ; 0x7e <main+0x12>
    _delay_ms(3);
    PORTB = 0x00;
  82:   15 b8           out     0x05, r1        ; 5
  84:   00 c0           rjmp    .+0             ; 0x86 <_exit>

00000086 <_exit>:
  86:   ff cf           rjmp    .-2             ; 0x86 <_exit>

Вот с флагом -DF_CPU=5000000UL 

int main(void)
{
  6c:   cf ef           ldi     r28, 0xFF       ; 255
  6e:   d2 e0           ldi     r29, 0x02       ; 2
  70:   de bf           out     0x3e, r29       ; 62
  72:   cd bf           out     0x3d, r28       ; 61
    DDRB = 0xFF;
  74:   8f ef           ldi     r24, 0xFF       ; 255
  76:   84 b9           out     0x04, r24       ; 4
    PORTB = 0xFF;
  78:   85 b9           out     0x05, r24       ; 5
 */
void
_delay_loop_2(uint16_t __count)
{
        __asm__ volatile (
  7a:   86 ea           ldi     r24, 0xA6       ; 166
  7c:   9e e0           ldi     r25, 0x0E       ; 14
  7e:   01 97           sbiw    r24, 0x01       ; 1
  80:   f1 f7           brne    .-4             ; 0x7e <main+0x12>
    _delay_ms(3);
    PORTB = 0x00;
  82:   15 b8           out     0x05, r1        ; 5
  84:   00 c0           rjmp    .+0             ; 0x86 <_exit>

00000086 <_exit>:
  86:   ff cf           rjmp    .-2             ; 0x86 <_exit>

koTuk
()
Ответ на: комментарий от anonymous

Пока что я не встречал задач для которых нужна была ОС. Племянница машину радиоуправляемую сломает - попробую робота из нее сделать чтобы препятствия объезжала сама - там она реально нужна будет :)

koTuk
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.