Десятик «Вязьма»

Новый десятик анонсирован на 1 апреля.

@темы: мии, монетики

---

25 рублей Сочи

12 марта анонсировали двадцатипятик:


Опять не смогу найти ><

@темы: мии, монетики

---

Google Reader

Ааа, эти нехорошие дяди из гугла закроют читалку 1 июля 2013. Опять надо искать удобную RSS-читалку, чтоб за обновлениями манги следить .з.


Вот жеж пирожки. Перенёс всё в Яндекс.Подписки, пока можно... Но как быть с телефоном, чтоб он мне сообщал о новых?Оо

UPD от 19.03.2013: что-то Яндекс.Подписки медленные. Одна манга ещё вчера обновилась, он не заметил. Сегодня ещё две новые главы, а он не знает .з. Жамкаешь «Обновить», а ему пофиг.
UPD от 21.03.2103: feedly актуально (через гуглоридер) следит. Но фиг (не зря он "фиг ли" называется) через него добавишь какую-нибудь RSS == Только через гуглоридер. Мда. Яндекс за два дня всё же увидел обновления, молодец, быстрый.

@темы: мии

---

Закрытая запись, не предназначенная для публичного просмотра

---

Семинар по Altera FPGA/Cortex-A9

19 марта, вторник, в Питере (в другие даты ещё где-то) от компании EBV Electronik: Altera SoC FPGA Seminar.

Видимо, очень интересно. Взаимодействие программируемой логики и процессорного ядра Cortex-A9, да и вообще что это и накой сдалось.

@темы: arm, семинары, электроника, fpga

---

STM32F4. Структура программы

Этот пост не относится конкретно к какой-то платформе, но примеры даны именно для stm32f4, ибо stm32 много у кого есть.

Раньше я особо не задумывался над структурой программ. Каждая программа была сделана по-разному, была весьма запутанной и со множеством очевидных и не очень связей между частями. Жуть. Между тем, использовать операционные системы не очень хотелось.
За год работы в ADL я всё же выработал для себя достаточно удобное представление кода в проекте.

Основные принципы вполне очевидны и широко используются:
- Инкапсуляция. Все модули сами по себе, они интроверты. Как и что они делают - это их личное дело. Общаемся только через предоставленные ими функции. Никаких глобальных переменных а ля extern uint8_t dmx_buffer[512];
- Не засоряем пространство имён. Всё, что не нужно остальному коду, отмечаем как static. Всякие структуры, не нужные вне модуля, объявляем в отдельных файлах, подключаемых только к нему. Опять же, никаких глобальных переменных для связи между модулями;
- Многоуровневый код. Алгоритм работает независимо от периферии и ничего о ней не знает. Общаемся только через драйвера;
- Обратные связи через callback-процедуры. Если нам надо получить извещение о наступлении какого-либо события, то скажем драйверу, какую функцию вызывать, а дальше он сам всё в нужный момент сделает. Нет причин его постоянно опрашивать.

Практически любая программа может быть разделена на три уровня:
- драйвера, которые непосредственно управляют периферией (портами, таймерами, интерфейсами типа UART, SPI и т.д.);
- драйвера внешних устройств, которые работают через драйвера периферии (уже никаких #include или не допускаем) и предоставляют доступ ко всем устройствам на плате (светодиодам, кнопкам, микросхемам и т.д.), вся завязка на номера выводов и ножки именно здесь;
- пользовательская программа, реализующая конечный алгоритм через эти два уровня драйверов.

Показываю на структуре прилагаемого проекта:
./main.c - основной код, запуск инициализации в нужном порядке, главный цикл;
./drivers.c - инициализация драйверов периферии в нужном порядке (сначала базовые типа gpio и таймеров, потом более сложные типа spi и uart, которым gpio и таймеры могут быть нужны);
./bsp.c - инициализация драйверов внешних устройств, в данном случае драйвера светодиодов и кнопки;
./drivers/system.c - включение/выключение прерываний;
./drivers/systick.c - системный таймер. С заданной периодичностью может вызывать функции;
./drivers/gpio.c - драйвер портов ввода/вывода, позволяет настраивать как вход, выход, задавать альтернативную функцию (для других драйверов), задавать уровень на ножке и считывать её состояние;
./bsp/led.c - драйвер светодиодов. Работает через gpio.c и знает только, что светодиоды сидят на порту D и выводах 12-15. Его задача - предоставить доступ к светодиодам по независимым от платы номерам: от 0 до 3. Включать их и выключать по требованию основного алгоритма. При этом наличие или отсутствие отдельных светодиодов никак не повлияет на работу алгоритма в целом;
./bsp/button.c - драйвер кнопки. Периодический опрос и фиксация нажатия;
./main/test.c - тестовая программа. Моргает светодиодом с частотой 10 Гц и по нажатию на кнопку меняет текущий светодиод.

С CMSIS общаются только файлы, находящиеся в папке drivers. Остальные даже не знают, на каком контроллере они работают. И при сохранении интерфейса драйверов код можно перенести, например, на LPC23xx. Собственно, я проделал обратное. Почти все эти интерфейсы таймеров и GPIO взяты из проекта под LPC2368, а ранее из проекта под atmega1280.

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

Минимальный интерфейс имеет всего две функции:

// Запуск таймера с заданной частотой. Частота, впрочем, может быть фиксированной внутри модуля
void timer_Init(uint32_t Frequency);

// Добавление в планировщик функции, которая будет вызываться с заданной частотой
void timer_AddFunction(uint16_t Frequency, void * Handler);

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

while(1)
{
	timer_Main(); // Оттуда-то всё и вызывается
}

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

// Количество обработчиков максимальное
#define TIMER_HANDLERS    10

typedef struct 
{
	void  (* Handler)(void);
	uint16_t Countdown;
	uint16_t Reload;
    
	// Запущено
	bool     Run;
	// Сработало
	bool     Fired;
} THandlers;

// Функции, кои будут вызываться
THandlers Handlers[TIMER_HANDLERS];
uint32_t  TimerFrequency;

void SysTick_Handler(void)
{
    int i;
    
	for(i = 0; i < TIMER_HANDLERS; i++)
	{
		if(Handlers[i].Run)
		{
			if(--Handlers[i].Countdown == 0)
			{
				Handlers[i].Countdown = Handlers[i].Reload;
		
				// Запишем, что сработало
				Handlers[i].Fired = true;
			}
		}
	}
}

// Запуск таймера с заданной частотой
void timer_Init(uint32_t Frequency)
{
    if(!Frequency) return;
    
    // Сбросим параметры
    TimerFrequency = Frequency;
    memset(&Handlers[0], 0, sizeof(Handlers));
    
    // Настройка частоты
    // По умолчанию на SysTick Timer идёт частота, меньшая, чем системная в 8 раз
    SysTick_Config(SystemCoreClock / Frequency / 8);
    
    // Разрешение прерывания
    NVIC_EnableIRQ(SysTick_IRQn);
}

// Добавить функцию в список вызова, Handler будет вызываться с заданной частотой
void timer_AddFunction(uint16_t Frequency, void * Handler)
{
	int i;
	
	for(i = 0; i < TIMER_HANDLERS; i++)
	{
		// Найдём пустой слот
		if(!Handlers[i].Handler)
		{
			// Обработчик, частота опроса
			Handlers[i].Run       =  true;
			Handlers[i].Fired     =  false;
			Handlers[i].Handler   = (void (*)(void))Handler;
			Handlers[i].Reload    = (TimerFrequency / Frequency);
			Handlers[i].Countdown =  Handlers[i].Reload;
			
			break;
		}
	}
}

void timer_Main(void)
{
    int i;
	
	for(i = 0; i < TIMER_HANDLERS; i++)
	{
        // Если сработало - вызовем.
        if(Handlers[i].Fired)
        {
            Handlers[i].Fired = false;
            Handlers[i].Handler();
        }
    }
}

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

static bool State = false;
static int  Index = 0;

// Периодически вызываемая функция, моргание
static void test_onTimer(void)
{
    if(State)
    {
        led_On(Index);
    }
    else
    {
        led_Off(Index);
    }
    
    // Сменим состояние
    State = !State;
}

// Сменим номер светодиода по нажатию
static void test_onKey(uint8_t Button)
{
    // Погасим светодиод текущий
    led_Off(Index);
    
    // Выберем следующий номер
    Index++;
    Index &= 0x03;
    
    // Пусть и следующую итерацию он светится
    State = true;
    
    // зажгём следующий
    led_Off(Index);
}

// Запуск тестовой программы
void test_Init(void)
{
    // Функция test_onTimer будет вызываться с частотой 10 Гц
    timer_AddFunction(10, &test_onTimer);
    
    // Обработчик нажатия на кнопку
    button_SetHandler(&test_onKey);
}

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

Точно так же надо делать и всё остальное. Например, кнопки. Не дело главной программы фильтровать дребезг и прочую ерунду. Она только должна сказать: при нажатии кнопки вызови этот обработчик. А драйвер кнопок уже отфильтрует дребезг, зафиксирует нажатие, и при долгом нажатии сможет периодически вызывать обработчик.
И даже если вдруг кнопки станут абсолютно другими: сенсорными, например, или появится микруха, которая эти кнопки обслуживать будет по I2C, то основная программа от этого не изменится! Изменится только сам файл button.c.

Ну и в любом случае приятно, когда алгоритм не загромождён всякими не относящимися к его задаче проверками.

Суть изоляции алгоритма от физической привязки к номерам выводов:

#define LED_COUNT 4

typedef struct
{
    TPort   Port;
    uint8_t Pin;
} TPin;

// Светодиоды сидят на порту D, выводах 12-15.
TPin Leds[LED_COUNT] = { {PORTD, 12}, {PORTD, 13}, {PORTD, 14}, {PORTD, 15} };

// Инициализация драйвера светодиодов
void led_Init(void)
{
    int i;
    
    for(i = 0; i < LED_COUNT; i++) gpio_DigitalOutput(Leds[i].Port, Leds[i].Pin);
}
    
// Включить светодиод по его номеру
void led_On(uint8_t Index)
{
    if(Index >= LED_COUNT) return;
    
    gpio_HighLevel(Leds[Index].Port, Leds[Index].Pin);
}
    
// Выключить светодиод по его номеру
void led_Off(uint8_t Index)
{
    if(Index >= LED_COUNT) return;
    
    gpio_LowLevel(Leds[Index].Port, Leds[Index].Pin);
}

Если светодиод куда-то переедет, то будет достаточно поменять всего три символа, чтобы всё снова заработало.
Да и led_On(LED_LEFT) куда как понятнее, чем gpio_HighLevel(PORTD, 12) или GPIOD->BSRR = GPIO_BSRR_BS_12.

UPD от 14.05.2013: я в итоге решил, что передавать указатель на структуру, в которой указан номер порта и вывода логичнее и нагляднее:

typedef enum { PA = 0, PB = 1, PC = 2, PD = 3, PE = 4} TPort;

typedef struct
{
    TPort   Port;
    uint8_t Pin;
} TPin;

...

static const TPin SCK = { PA, 0 };
static const TPin MOSI = { PA, 1 };

{
    // Даже писать не надо, что тут происходит
    gpio_HighLevel(&SCK);
    gpio_LowLewel(&SCK);
}

Интересные файлы:
gpio.c
systick.c
led.c
button.c
test.c

Проект целиком.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, stm32f4discovery, stm32

---

STM32F4. Контроллер внешних прерываний

Контроллер умеет следить за линиями ввода-вывода и генерировать события по фронту сигнала и имеет 7 векторов прерываний (5 индивидуальных и 2 групповых).

За тактирование контроллера отвечает бит SYSCFGEN в регистре APB2ENR.

Регистров тут совсем немного и нас интересуют только несколько из них:
EXTI_IMR — маска разрешения прерывания. Бит 0 отвечает за нулевую линию, бит 1 за первую и т.д;
EXTI_RTSR — маска включения детектора нарастающего фронта сигнала;
EXTI_FTSR — маска включения детектора спадающего фронта сигнала;
EXTI_PR — флаги сработавшего детектора. Тут их и надо сбрасывать, Чтоб покинуть прерывание.

Номер линии совпадает с номером пина в порту. Разрешается лишь выбирать, с какого порта эта линия берётся: с порта A или с порта B, или ещё откуда. Это номера от 0 до 15. Остальные линии подключены к разным сигналам:
Линия 16: PVD.
Линия 17: RTC Alarm.
Линия 18: USB OTG FS Wakeup.
Линия 19: Ethernet Wakeup.
Линия 20: USB OTG HS Wakeup.
Линия 21: RTC Tamper и RTC TimeStamp.
Линия 22: RTC Wakeup.

Первые 5 линий имеют индивидуальные вектора EXTI0_IRQHandler, EXTI1_IRQHandler, EXTI2_IRQHandler, EXTI3_IRQHandler, EXTI4_IRQHandler. Потом линии делятся на две группы, 5-9 (EXTI9_5_IRQHandler) и 10-15 (EXTI15_10_IRQHandler). В этих векторах ещё потребуется опросить регистр EXTI_PR, чтоб понять, какая из линий сработала.

Код практически такой же, как и в предыдущем примере за исключением другой периферии.

Примерный код настройки, срабатывание по обоим фронтам по нажатию кнопки User на плате:

; Главная программа
            EXPORT __main
__main      PROC
            ; Сбросим счётчик
            MOV   R1, #0
            LDR   R7, =Counter
            STR   R1, [R7]

            ; Кнопка прицеплена на ногу PA0

            ; Разрешим прерывание от 0 линии EXTI
            MOV   R0, #EXTI0_IRQn
            BL    NVIC_EnableIRQ

            ; Загружаем базовое смещение регистра настройки тактирования
            LDR   R0, =RCC_APB2ENR
            
            ; Установить флаг разрешения тактирования SYSCFG (он же тактирует и EXTI)
            LDR   R1, [R0]
            ORR   R1, #RCC_APB2ENR_SYSCFGEN
            STR   R1, [R0]
            
            ; Загружаем базовое смещение SYSCFG
            LDR   R0, =SYSCFG_BASE
            
            ; Записываем, с каого порта берём сигнал
            ; По-человечески надо считывать регистр, обнулять нужную часть и
            ; записывать необходимое число. Но пофиг.
            LDR   R1, =0x0000         ; Порт A (0) на первые 4 пина
            STR   R1, [R0, #SYSCFG_EXTICR1_OFFSET]
            
            ; Загружаем базовое смещение EXTI
            LDR   R0, =EXTI_BASE
            
            ; Маска, разрешаем генерировать прерывание на канале 0
            LDR   R1, =EXTI_IMR_MR0
            STR   R1, [R0, #EXTI_IMR_OFFSET]
            
            ; Любой фронт
            ; В идеале тут тоже надо просто ставить бит, а не вот так
            MOV   R1, #EXTI_FTSR_TR0
            STR   R1, [R0, #EXTI_FTSR_OFFSET]
            MOV   R1, #EXTI_RTSR_TR0
            STR   R1, [R0, #EXTI_RTSR_OFFSET]
            
__mainloop  ; Вечный цикл
            ; Смотрим, что натикал счётчик
            LDR   R0, =Counter
            LDR   R1, [R0]
            
            ; Новый круг~
            B __mainloop

            ENDP

Пример обработчика прерывания:

; Внешнее прерывание
            EXPORT EXTI0_IRQHandler 
EXTI0_IRQHandler  PROC
                    ; Прерывание автоматически сохраняет состояние регистров 0-3, 12, LR, PC на стеке
                    
                    ; Увеличим счётчик на 1
                    LDR   R0, =Counter
                    LDR   R1, [R0]
                    ADD   R1, #1
                    STR   R1, [R0]
                    
                    ; Сбросим флаг прерывания (иначе никогда из него не выйдем)
                    LDR   R0, =EXTI_BASE
                    
                    ; Сброс выполняется записью бита
                    MOV   R1, #EXTI_PR_PR0
                    STR   R1, [R0, #EXTI_PR_OFFSET]
                    
                    BX LR
                    ENDP

По нажатию на кнопку переменная Counter (и регистр R1 в главном цикле) будут увеличиваться.

Интересные файлы:
main.s

Проект целиком.

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


<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, ассемблер, stm32f4discovery, stm32

---

Протокол IGMPv2

Протокол IGMP (Internet Group Management Protocol) отвечает за регулирование групповых передач в сети.
То есть с его помощью можно сказать маршрутизатору: мне нужны пакеты с такими-то адресами, остальные можешь слать лесом. Тем самым сетевая нагрузка на устройство может сильно уменьшиться, если в сетке этих мультикастов гуляет целая куча.
Если регулироваться их прохождение не будет, то устройство получит все пакеты

Протокол прост и незамысловат, если не вдаваться в тонкости. Я пока смотрел только вторую версию протокола IGMPv2. Остальные не сильно сложнее.
IP-заголовок пакета отличается от UDP, во-первых, типом (вместо 0x11 у UDP здесь 0x02), во-вторых дополнительным полем Router Alert (4 байта в конце 0x94 0x04 0x00 0x00), которое заставляет маршрутизатор посмотреть содержимое пакета (иначе он просто пошлёт дальше, проигнорировав).

Устройство должно уметь принимать всего один тип пакетов:
— Membership Query Message. Запрос списка нужных рассылок. Внутри него интересно лишь одно поле: адрес. Если в поле адреса нули (0.0.0.0), то устройство, получившее запрос, шлёт список адресов рассылок, которые ему надо получать. Если там какой-то адрес, то отвечаем только конкретно по нему: нужна нам эта рассылка или нет.

Отправлять надо два типа пакетов:
— Membership Report Message — нам нужна эта рассылка, шлите мне её;
— Membership Leave Message — нам эта рассылка более не нужна, фильтруйте.

Отличаются они только типом 0x16 у Report и 0x17 у Leave. Кроме типа и, собственно, адреса мультикаст-рассылки, там ничего важного и нет.
А, ещё один важный момент: Membership Report Message шлётся по адресу рассылки (который указан в пакете), а Membership Leave Message шлётся по адресу 224.0.0.2 (всем маршрутизаторам что ли).

Пакеты могут отправляться в любое время, если есть такая надобность, и Report отправляется, если пришёл запрос Query.

Сам формат пакетов можно посмотреть тут: IP Multicast.

Или так:

typedef __packed struct
{
    uint8_t  Type;             // 0x11 для Query, 0x16 для Record, 0x17 для Leave
    uint8_t  MaxRespTime;      // Используется только в Query.
    
    uint16_t Checksum;         // Обычная контрольная сумма, какая используется в базовых сетевых протоколах.
    uint32_t MulticastAddress; // 0x0200fffe для 239.255.0.2
} TIGMP2Message;

Мне оно надо, так как протокол sACN (E1.31) использует мультикаст рассылки и требует поддержки этого протокола.

@темы: мии, программизмы

---

Не знаю, о чём это, но как-то так

Небольшая цитатка из лекции по предмету Electrical Engineering and Computer Science (электроника и компьютерные технологии) Массачусетского технологического института:
def changeFirstEntry(x):
... x [0] = 'nya nya'
>>> b = [1 , 2 , 3]
>>> changeFirstEntry(b)
>>> b
['nya nya', 2 , 3]
^^"

Или в этой газете того же института на 13 странице можно посмотреть на повешенного на стенку длинноНянкета. Забавно.
Ну и окончательно упороться можно китайским философом У Ня Ня и всем остальным (я не осилил) можно в сценарии КВН 95 года.

@темы: мии, nya, няшодки

---

Закрытая запись, не предназначенная для публичного просмотра

---

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

Выходные ^^

@темы: мии

---

Закрытая запись, не предназначенная для публичного просмотра

---

Выигрышные ожидания в риичи-маджонге

В скобочках — среднее количество тайлов в стене, которые надо посмотреть, чтоб найти в них нужный (без учёта вышедших и имеющихся на руках).

Интересно, реально ли всё это запомнить или узнавать зайчатки подобного в руке?Оо

1. Односторонние.
. Ожидание: . Максимум 3 аута (45 т).
. Ожидание . Максимум 4 аута (34 т).
. Ожидание . Максимум 4 аута (34 т).

2. Двухсторонние.
. Ожидание: . Максимум 4 аута (34 т).
. Ожидание: . Максимум 6 аутов (23 т).
. Ожидание . Максимум 7 аутов (23 т).
. Ожидание: . Максимум 8 аутов (17 т).

3. Трёхсторонние.
. Ожидание . Максимум 5 аутов (27 т).
. Ожидание . Максимум 6 аутов (23 т).
. Ожидание: . Максимум 7 аутов (23 т).
. Ожидание . Максимум 8 аутов (17 т).
. Ожидание: . Максимум 9 аутов (15 т).
. Ожидание: . Максимум 9 аутов (15 т).
. Ожидание . Максимум 9 аутов (15 т).
. Ожидание . Максимум 9 аутов (15 т).
. Ожидание . Максимум 10 аутов (14 т).
. Ожидание . Максимум 10 аутов (14 т).
. Ожидание . Максимум 11 аутов (12 т).
. Ожидание: . Максимум 11 аутов (12 т).
. Ожидание: . Максимум 11 аутов (12 т).

4. Четырёхсторонние.
. Ожидание . Максимум 7 аутов (23 т).
. Ожидание . Максимум 8 аутов (17 т).
. Ожидание: . Максимум 9 аутов (15 т).
. Ожидание . Максимум 9 аутов (15 т).
. Ожидание: . Максимум 10 аутов (14 т).
. Ожидание . Максимум 11 аутов (12 т).
. Ожидание: . Максимум 13 аутов (11 т).
. Ожидание: . Максимум 13 аутов (11 т).
. Ожидание . Максимум 13 аутов (11 т).
. Ожидание: . Максимум 14 аутов (10 т).

В две масти!
. Ожидание . Максимум 9 аутов.
. Ожидание . Максимум 10 аутов (14 т).

5. Пятисторонние.
. Ожидание . Максимум 10 аутов (14 т).
. Ожидание . Максимум 11 аутов (12 т).
. Ожидание . Максимум 11 аутов (12 т).
. Ожидание . Максимум 12 аутов (11 т).
. Ожидание . Максимум 13 аутов (11 т).
. Ожидание . Максимум 15 аутов (9 т).
. Ожидание . Максимум 15 аутов (9 т).
. Ожидание . Максимум 16 аутов (8 т).
. Ожидание: . Максимум 17 аутов (8 т).
. Ожидание: . Максимум 17 аутов (8 т).

В две масти!
. Ожидание . Максимум 13 аутов (11 т).

6. Шестисторонние.
. Ожидание . Максимум 11 аутов (12 т).
. Ожидание . Максимум 13 аутов (11 т).
. Ожидание . Максимум 16 аутов (8 т).
. Ожидание: . Максимум 19 аутов (7 т).
. Ожидание . Максимум 19 аутов (7 т).

7. Семисторонние.
. Ожидание . Максимум 18 аутов (7 т).
. Ожидание . Максимум 17 аутов (8 т).
. Ожидание . Максимум 23 аута (6 т).
. Ожидание . Максимум 23 аута (6 т).

8. Восьмисторонние
. Ожидание . Максимум 22 аута (6 т).
. Ожидание . Максимум 23 аута (6 т).
. Ожидание. Максимум 23 аута (6 т).
. Ожидание . Максимум 23 аута (6 т).

9. Девятисторонние.
. Ожидание . Максимум 23 аута (6 т).

10. Тринадцатисторонние.
Кокуши Мусо. Максимум 39 аутов (4 т).

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

Дополнительные материалы:
— 聴牌;
— 複合面子(多メンチャン.

То же в текстовом виде: mj_waitings.txt.
Некоторая небольшая выборка многосторонних ожиданий из моих игр на тенхочке (логи коих у меня есть): tenhou_hand_waiting.txt. Потом попробую собрать статистику по ожиданиям какую-нибудь.

@темы: мии, маджонг

---

Турнир

По итогам у меня 8 место из 26 что ли игроков =) Для начала неплохо... Места в ханчанах: 1, 1, 3, 3, 3, 2, 1, 2.

@темы: мии, маджонг

---

Работа с UDP-пакетами на языке C#

Вдруг понадобилось мне с компьютера отправлять пакеты ArtNet по сети. Желательно, чтобы это было просто, удобно и достаточно гибко. Для подобного рода задач (что-то сделать на компьютере) я в последнее время предпочитаю C#. Там дофига готовых проверенных библиотек и заниматься велосипедостроением не надо.

Вообще, отправить широковещательный UDP-пакет достаточно просто:

using System.Net;
using System.Net.Sockets;

class ArtNetNode
{
        private IPEndPoint BroadcastEndPoint;
	private UdpClient udpClient; // Сетевой интерфейс
	private int Port;

	
	public ArtNetNode()
        {
		// Стандартный порт ArtNet: 6454
		Port = 0x1936;

		// 2.255.255.255
		IPAddress Address = new IPAddress(0xffffff02);
		BroadcastEndPoint = new IPEndPoint(Address, Port);

		udpClient = new UdpClient(Port);

		udpClient.EnableBroadcast = true;

		udpClient.Client.SendTimeout = 100;
		udpClient.Client.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
	}

	// Отправка пакета по широковещатльному адресу 2.255.255.255
	public Send(byte[] Data)
	{
		udpClient.Send(Data, Data.Length, BroadcastEndPoint);
	}
}

Но интересно не это, интереснее мне, как же удобнее представлять пакеты внутри кода? В языке Си есть структуры, которые могут задать расположение объектов в памяти. В C# ничего такого нет, и всю разборку на байты и их расположение надо выполнять вручную.
В идеале класс должен давать доступ к полям структуры, как для записи, так и для чтения. Пусть не всем, но самым важным, которые непременно будут раз от раза меняться.

Для первого опыта я выбрал достаточно простой пакет: ArtDMX.

typedef struct _ArtDmx
{
	char     ID[8];
	uint16_t OpCode;    // Тип пакета ARTNET_DMX = 0x5000
	uint8_t  ProtVerH;  // Версия протокола: 14.0
	uint8_t  ProtVer;
	uint8_t  Sequence;  // Для определения последовательности пакетов
	uint8_t  Physical;  // Физический порт устройства (только для информации)
	uint8_t  Net;
	uint8_t  Universe;  // Идентификатор потока
	uint8_t  LengthH;
	uint8_t  Length;    // Кличество передаваемых каналов (512)
	uint8_t  Data[512]; // 512 каналов с данными
} ArtDmx;

Принцип создания пакета дубовый: записываем в массив байт по нужным смещениям числа. Для удобства можно создать функции, которые бы записывали по смещению в массив строки заданной длины, массивы, числа разного размера (1, 2, 4 байт) и формата (Big/Little Endian).
Поля ID, OpCode, ProtVer (H), Length здесь будут всегда одними и теми же, потому можно их жёстко захардкодить в инициализации класса.

// побайтовое представление пакета
private byte[] Packet = new byte[11 + 512];

public ArtDMX()
{
	// Оформим заголовок

	// ID[8]
	Helper.WriteString(ref Packet, 0, "Art-Net", 8);
	// OpCode: 0x5000, Little Endian
	Helper.WriteUInt16(ref Packet, 8, Convert.ToInt16(OpCodes.OpDmx));
	// ProtVer: 00, 14, Big Endian
	Helper.WriteUInt16BE(ref Packet, 10, 0x000E);

	// Length: 512, Big Endian
	Helper.WriteUInt16BE(ref Packet, 16, 512);
}

Остальные поля можно представить уже в виде свойств класса, которые читают и записывают этот массив так, как надо:

public byte Net
{
	get { return Packet[15]; }
	set { Packet[15] = value; }
}

// Чтение и запись каналов данных
public byte[] Data
{
	get
	{
		byte[] DMX = new byte[512];
		Buffer.BlockCopy(Packet, 18, DMX, 0, 512);

		return DMX;
	}
	set
	{
		Buffer.BlockCopy(value, 0, Packet, 18, Math.Min(value.Length, 512));
	}
}

// Для работы с отдельными каналами
public byte this[int index]

{
	get { return ((index >= 0) && (index < 512)) ? Packet[18 + index] : Convert.ToByte(0); }
	set
	{
		if ((index >= 0) && (index < 512))
		{
			Packet[18 + index] = value;
		}
	}
}

Получение пакета для внешнего кода:

public byte[] GetPacket()
{
	// если пакет меньше, то считать размер и выделять столько, сколько надо
	byte[] Data = new byte[Packet.Length];

	// Sequence - порядковый номер отправленного пакета, увеличим на 1
	Helper.WriteByte(ref Data, 12, Sequence++);

	// Копипастим массив
	Buffer.BlockCopy(Packet, 0, Data, 0, Packet.Length);

	return Data;
}

Для внешнего кода работа с полями будет такой же, как и в Си:

ArtDMX DMX = new ArtDMX();

DMX.Universe = 0x01; // subnet 0, universe 1.

// Пила на 239 канале (в DMX номера каналов начинаются с 1, в коде же с 0)
{
	DMX[238]++;

	byte[] Packet = DMX.GetPacket();
	udpClient.Send(Packet, Packet.Length, BroadcastEndPoint);
}

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

Внизу предложены мои варианты исходников, использовать просто:
private ArtNet.ArtNetNode Node = new ArtNet.ArtNetNode();
Node.Start();

В итоге в сети появится поток 0-0, в котором на 239 канале будет пила. Выбор канала объясняется просто: тут стоит башка, у которой стартовый адрес 239. И при запуске программы она начинает крутиться вокруг вертикальной оси. Для просмотра потоков ArtNet можно воспользоваться программой DMX Workshop.

Файлы:
ArtNetNode.cs
ArtDMX.cs
OpCodes.cs
Helper.cs

П.С. Я язык C# знаю весьма посредственно, потому может существовать 100500 куда как лучших решений оной проблемы, просто я о них пока не знаю.

@темы: программизмы, artnet, C#

---

Логи высших дановых лобби тенхо

О, я-таки нашёл, где приведены логи мегаигроков из Феникс-лобби (и, возможно, высшего данового). Пример части списка сегодняшних игр.

Для всех игр (из всех лобби) там есть результаты. Но ссылки на логи есть только для этого лобби. См. список игр, название файла которых начинается на scc и заканчивается на .html. Сам файл открывается по нажатию на кнопочку "表示". Может, конечно, это общеизвестный факт, но я не знал >< Или тут в менее загромождённом виде и за больший срок.

Вообще, название файла говорит само за себя, начинается название с идентификатора:
sca - все частные лобби;
scb - общее и первое дановое лобби (L0000);
scc - высшие дановые лобби;
scd - ещё что-то.

Далее идёт дата и какой-то номер.
Например, scc2013021113: 13 лог за 11.02.2013 из высшего лобби (то ли Феникс, то ли нет).

Все игры из высших лобби есть и в этом файле: sccall.html. Смотреть не пересмотреть.

@темы: мии, маджонг, няшодки, tenhou

---

Десятики по универсиаде

Не знаю, что это такое и что там будет. Но, видимо, что-то важное, раз центробанк аж два десятика 23 января анонсировал по ней (с названием чиби-серии «UNIVERSIADE KAZAN 2013 RUSSIA»):


Тираж по 10 миллионов, как и обычно. Будем искааать.

@темы: монетики

---

Расчёт числа шантен

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

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

Для начала можно рассмотреть вторые два как более простые. Шантен до читойцу считается просто. В темпае в руке 6 пар и один левый тайл. Соответственно, надо посчитать число пар и вычесть это из шести. Повторяющиеся пары не считаются.
ShantenChiitoi = 6 - (Paircount);

Шантен до Кокуши считается аналогично, только считаются уже отдельные тайлы. Все терминалы, все ветра, все драконы.
Максимальный шантен: 13. За каждый нужный неповторяющийся тайл отнимаем единицу. И один раз отнимаем за повтор нужного тайла (нужна одна пара). Все остальные повторы не уменьшают число шантен.

Самый сложный алгоритм, конечно, относится к обычной руке, так как там могут быть различные и пересекающиеся формы. Суть алгоритма всё же не такая и мудрёная: вырезать все пары, сеты и таацу (незаконченные формы) всеми возможными способами, — и тем самым найти минимальное значение числа шантен. Максимальное значение шантен для обычной руки: 8. То есть как бы имеем зайчатки для 4 сетов и одной пары, но только по одному тайлу от каждого (итого 13 - 5 = 8). Соответственно, пара будет уменьшать число шантен на единицу (как пара или как незаконченный ankou в дальнейшем), два (изолированных от остальных) соседних тайла будут уменьшать число шантен на единицу, образуя таацу, законченный сет же (3 одинаковых или 3 последовательных тайла) уменьшает число шантен на 2, так как к изолированному тайлу пришло два подходящих тайла. Итого, число шантен для текущего разложения считается: Temp = 8 - Mentsu * 2 - Kouho - Toitsu;

Mentsu в данном случае обозначает число сетов (чи, пон).
Toitsu — голова, пара тайлов, или 0 или 1.
Kouhou — все таацу и остальные пары (кантян, пентян, рянмен, пара).

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

Например: имеем часть руки .

Проходим первый раз без выделения пары, начиная с 2х:
1. Убирается сет ;
2. Убирается сет ;
Остался в руке лишний тайл: . Посчитали Mentsu = 2. Если остальные сеты открыты (Mentsu += 2), то это темпай. (8 - 2 * 4) = 0.

Проходим в другой раз, но сначала убирая пару:
1. Убирается пара .
2. Убирается сет .
3. Убирается кантян: .
В руке ничего не осталось. Mentsu = 1. Toitsu = 1. Kouho = 1. Это тоже темпай: (8 - 3*2 - 1 - 1) = 0.

Ещё раз проходим, начиная с 4х:
1. Убирается сет ;
2. Убирается пара: ;
3. Убирается рянмен: ;
В руке ничего не осталось. Mentsu = 1. Toitsu = 1. Kouho = 1. Расчёт такой же: (8 - 3*2 - 1 - 1) = 0.

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

Для удобства расчётов руку удобно представлять в виде массива, где индекс обозначает конкретный тайл, а содержимое — количество оных тайлов в руке.
uint8_t Tehai[38];

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

0: разделитель;
1-9: тайлы ман;
10: разделитель;
11-19: тайлы пин;
20: разделитель;
21-29: тайлы соу;
30: разделитель;
31: 東 (восток)
32: 南 (юг)
33: 西 (запад)
34: 北 (север)
35: 白 (белый дракон)
36: 発 (зелёный дракон)
37: 中 (красный дракон)

Для примера выше массив будет инициализирован так:

Tehai[22] = 2; // 2 2s
Tehai[23] = 1; // 1 3s
Tehai[24] = 2; // 2 4s
Tehai[25] = 1; // 1 5s
Tehai[26] = 1; // 1 6s

Теперь остаток от деления на 10 будет давать номер тайла в данной масти. И алгоритмы нахождения последовательностей будут проще из-за того, что все масти в массиве расположены симметрично и разделены нулями.
Чтобы полностью обойти все возможные варианты разбиения руки надо использовать рекурсивный алгоритм. Перед запуском назначаем руке шантен 8, число всех сетов, пар и форм 0. Когда вырезаем форму, убираем используемые тайлы и увеличиваем счётчик форм, вызываем ту же функцию, пусть она ищет дальше. Когда ничего полезного не останется, считаем по формуле шантен и сравниваем с записанным где-то. Если получился меньше, то обновим его. По выходе из функции возвращаем тайлы на место, уменьшаем счётчик форм (чтоб потом попробовать тайлы скомбинировать по-иному) и идём дальше.
Так же, не стоит забывать, что сетов нам надо всего четыре, потому лишние формы нам с шантеном не помогут, их надо пропускать.
Очерёдность вырезания тоже понятна: сначала сеты, потом из того, что осталось, вычленяем незавершённые формы. Единственное исключение: голову вырезать пробуем первой (она всё же отличается от сетов).
Что здорово, нет ограничения на число тайлов. Если есть открытые сеты, то просто запишем в Mentsu их количество.

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

Вот кусок кода на C#, который считает шантен по данному алгоритму:

{
	private uint Mentsu; // Количество сетов
	private uint Kouho;  // Количество форм
	private uint Toitsu; // Количество пар

	private uint[] Tehai = new uint[38]; // Для анализа руки

	private uint ShantenChiitoi; // Шантен до 7 пар
	private uint ShantenKokushi; // Шантен до Кокуши
	private uint ShantenNormal;  // Шантен до обычной руки

	private uint TempShantenNormal;

	private uint Shanten;

	private void Test()
	{
		// Когда рука сформирована
		Shanten = GetShanten();
	}

	private uint GetShanten()
        {
		// Шантен — минимальное из трёх

		// Шантен до обычной руки
		ShantenNormal = CalcShantenNormal();
		// Шантен до 7 пар
		ShantenChiitoi = CalcShantenChiitoi();
		// Шантен до кокуши
		ShantenKokushi = CalcShantenKokushi();

		return Math.Min(ShantenChiitoi, Math.Min(ShantenKokushi, ShantenNormal));
	}


	// Шантен до читойцу
	private uint CalcShantenChiitoi()
	{
		int i;
		uint Types = 0;

		// Считаем пары
		Pair = 0;
		for (i = 0; i < 38; i++)
		{
			if (Tehai[i] >= 2) Pair++;
		}

		// Посчитаем количество типов тайлов
		for (i = 0; i < 38; i++)
		{
			if (Tehai[i] > 0) Types++;
		}

		// Шантен равен 6 - количество имеющихся пар
		uint shanten = 6 - Pair;

		// Единственное ограничение: пары не должны повторяться, повторы (4 одинаковых тайла) увеличивают шантен
		// Иначе может получиться так, что там какое-нибудь сууанко собирается: 111 222 333 44 55
		// А это ещё 3-шантен до читойцу.
		if (Types < 7) shanten += 7 - Types;

		return shanten;
	}

	// Шантен до Кокуши
	private uint CalcShantenKokushi()
	{
		uint KokushiPair = 0;
		uint shanten = 13;
		int i;

		// посмотрим терминалы
		// Для кокуши нужны все единицы и девятки
		for (i = 1; i < 30; i++)
		{
			if ((i % 10 == 1)|| (i % 10 == 9))
			{
				if (Tehai[i] > 0) shanten--;
				if ((Tehai[i] >= 2) && (KokushiPair == 0)) KokushiPair = 1;
			}
		}

		// Посмотрим благородные тайлы
		for (i = 31; i < 38; i++)
		{
			if (Tehai[i] > 0)
			{
				shanten--;
				if ((Tehai[i] >= 2) && (KokushiPair == 0)) KokushiPair = 1;
			}
		}

		// Если есть одна необходимая пара - уменьшим шантен
		shanten -= KokushiPair;

		return shanten;
	}

	// Шантен до обычной руки
	private uint CalcShantenNormal()
	{
		int i;

		// Шантен максимален
		TempShantenNormal = 8;

		// Сетов пока не считали
		Mentsu = 0; // Если есть открытые сеты, то запишем сюда их количество
		Toitsu = 0;
		Kouho = 0;

		// Нам нужна одна пара, попробуем все тайлы в качестве её.
		for (i = 1; i < 38; i++)
		{
			// Если тайлов этой масти более одного, то от него можно попробовать отчекрыжить пару и посмотреть,
			// что из этого выйдет
			if (Tehai[i] >= 2)
			{
				Toitsu++;
				Tehai[i] -= 2;
				CutMentsu(1);
				Tehai[i] += 2;
				Toitsu--;
			}
		}

		// Что ж, попробуем и без пары оценить строение руки
		CutMentsu(1);

		return TempShantenNormal;
	}

	// По очереди вырезаем сеты из руки и смотрим, что там остаётся
	private void CutMentsu(int StartTile)
	{
		int i = StartTile;

		// Ищем первый попавшийся тайл
		if(i < 38) for(; (i < 38) && (Tehai[i] == 0); i++);

		// Сеты кончились, смотрим с начала незаконченные формы
		if(i >= 38) { CutTaatsu(1); return; }

		// если таких тайлов 3, то можно их рассмотреть как пон
		if(Tehai[i] >= 3)
		{
			Mentsu++;
			Tehai[i] -= 3;
			CutMentsu(i);
			Tehai[i] += 3;
			Mentsu--;
		}

		// Если есть следующий и ещё послеследующий тайл, то это можно рассмотреть как чи
		// Только для числовых тайлов (i < 30)
		// Благодаря разделителям (0, 10, 20, 30) не надо беспокоиться о пересечениях с чужой мастью
	        if((i < 30) && (Tehai[i + 1] > 0) && (Tehai[i + 2] > 0))
	        {
		        Mentsu++;
		        Tehai[i]--;
			Tehai[i+1]--;
			Tehai[i+2]--;

			CutMentsu(i);

			Tehai[i]++;
			Tehai[i + 1]++;
			Tehai[i + 2]++;
			Mentsu--;
	        }

		// Отрезали, смотрим дальше
		CutMentsu(i + 1);
	}

	private void CutTaatsu(int Start)
	{
		int i = Start;

		// Ищем первый попавшийся тайл
		if (i < 38) for (; (i < 38) && (Tehai[i] == 0); i++) ;

		// Если закончили и с формами, то посмотрим, что получилось
		if(i >= 38)
		{
			// Если шантен данного разложения меньше, чем насчитанный в других
			// вариантах, запишем его.
			uint Temp = 8 - Mentsu * 2 - Kouho - Toitsu;
			if (Temp < TempShantenNormal) { TempShantenNormal = Temp; }
                	return;
		}

		// Если форм ещё недостаточно, считаем
		// Лилшние формы шантен не уменьшают
		if (Mentsu + Kouho < 4)
		{
			// Пары
			if (Tehai[i] == 2)
			{
				Kouho++;
				Tehai[i] -= 2;
				CutTaatsu(i);
				Tehai[i] += 2;
				Kouho--;
			}

			// Пентян и рянмен
			if((i < 30) && (Tehai[i + 1] > 0))
			{
				Kouho++;
				Tehai[i]--; Tehai[i + 1]--;
				CutTaatsu(i);
				Tehai[i]++; Tehai[i + 1]++;
				Kouho--;
			}

			// Кантян
			if((i < 30) && ((i % 10) <= 8) && (Tehai[i + 2] > 0))
			{
				Kouho++;
				Tehai[i]--; Tehai[i + 2]--;
				CutTaatsu(i);
				Tehai[i]++; Tehai[i + 2]++;
				Kouho--;
			}
		}
		CutTaatsu(i + 1);
	}
}

А имея алгоритм расчёта шантен, можно уже посчитать уке-ире и иные параметры руки. То есть круто.
Данный алгоритм подсмотрен на упоминавшемся мной ранее сайте: 麻雀C言語プログラム集 (Collection of C language mahjong program).

@темы: мии, программизмы, маджонг

---

Бывают люди ж =D

НЛО из принтера. Смешно =D

@темы: мии

---

Анализ реплеев tenhou

Нашёл программки по скачиванию файлов логов игр и, видимо, их просмотру и простому анализу на каком-то форуме.
LogGrabber; ReplayAnalyzer.

Надо тоже посмотреть, а то я хотел себе статистику кой-какую замутить, не вручную ж Оо

UPD: программы оные у меня так и не заработали, я не знаю, что ей надо в качестве исходных данных.
Зато наколхозил своё на C#, разбирает все раздачи: и открытые, и закрытые руки, умеет считать шантен и уке-ире (надеюсь, что правильно) и тоже может подсматривать всю стену, как и оф. клиент. Надо только научить её считать разные параметры.

UPD: tenhou_archive.rb — опенсорсный парсер логов тенхи. Ruby.
Ещё один парсер. C#, консоль. Есть расчёт шантен, определение ожиданий и т.д.
Код распаковки файлов mjlog, кои сидят в архивах типа mjlog_pf4-20_n1.zip. VB.NET. Тенхочка их сервером распаковывает и отдаёт уже вот так.

Ну и конвертировать ссылки на реплеи из закодированного вида в обычный (и обратно) она тоже умеет:
2012090306gm-0089-0000-x666f4d41e26b — закодированный, используется во флеш-клиенте.
2012090306gm-0089-0000-dc81a77a — декодированный, используется в клиенте виндовом.
Обе ссылки ведут на один и тот же реплей.

UPD1 от 06.02.2013: первый этап завершён. Формат файла лога исследован и поддаётся анализу. Задача: сделать удобное внутреннее представление лога, интерфейс просмотрщика.
UPD2 от 25.02.2013: определение ожиданий в темпае.
UPD3 от 30.10.2013: см. TenhouViewer (дневники, google code).

@темы: мии, программизмы, маджонг, tenhou