Topic atmega8 | Hey, ruX is here. https://rux.vc Delivering things - from code to product Wed, 14 Apr 2010 10:47:03 +0000 en-US hourly 1 https://wordpress.org/?v=6.4.8 162978439 Cветодиодная линейка на MAX7219 https://rux.vc/2010.04/led-line-based-on-max7219/ https://rux.vc/2010.04/led-line-based-on-max7219/#comments Sat, 03 Apr 2010 21:32:44 +0000 http://rux.pp.ru/blog/?p=467 Попалась мне в руки светодиодная линейка неизвестного происхождения из 52 двухцветных светодиодов - красный и зелёный. Которая управлялась двумя микросхемами maxim max7919(драйвер). У этой платки было 8 пинов для подпайки, один из которых ни к чему не подключался. Цель - разобраться что она из себя представляет, как работает и сделать что-нибудь с ней - погонять ... Read more

The post Cветодиодная линейка на MAX7219 first appeared on Hey, ruX is here..]]>

Попалась мне в руки светодиодная линейка неизвестного происхождения из 52 двухцветных светодиодов - красный и зелёный. Которая управлялась двумя микросхемами maxim max7919(драйвер). У этой платки было 8 пинов для подпайки, один из которых ни к чему не подключался.

Цель - разобраться что она из себя представляет, как работает и сделать что-нибудь с ней - погонять "бегущие огни" будет вполне достаточно.

Предыстория

Конечно, сама она мне в руки не упала :). Дал мне её преподаватель нового предмета - Основы проектирования. Он очень много знает и желает делится знаниями со студентами, предлагая создать различные проекты.

Внутри

Понятия не имею откуда эта линейка и для чего она предназначалась. Поэтому пришлось разбираться. Единственное что было на плате - цифры 8485-01, видимо какой то серийный номер - ровным счётом ничего не дало. Осмотр схемы + чтение даташита - час ушёл на то, чтоб понять как она примерно работает.

Каждые 4 диода общим анодом к выходам "номерам цифр" драйвера, и к каждому цвету светодиода по ноге из сегментов. В итоге на первый драйвер приходится 8 "номеров цифр", на второй - 5. Под номерами цифр я подразумеваю номера цифр на 7ми сегментных дисплеев

Схему в общем виде линейку можно обрисовать так:

Ага, рисовал карандашиком. Жутко не хотелось в каде. Посмотрел библиотеки компонентов gEDA, KiCad и даже eagle - там не было драйвера. Пробежался по гуглу - тоже нет. Рисовать - лень, да и не нужно это для одного раза. Вот карандашиком.. как на начерталке ))

Разводку платы знать и не нужно - главное,что есть интерфейс. На рисунке - он слева. Пару слов о нём:

  1. Пусто.. видимо для отсчёта
  2. GND - земля. Общая для двух драйверов
  3. DIN - данные. Также общий для драйверов - разумеется данные предназначаются тому, у которого активен CS
  4. CS1 - chip select для первой микросхемы. Выставляем в 0, когда хотим что-то сказать ей. На ней 5 сегментов(5 * 4 = 20светодиодов)
  5. CS2 - аналочино, для второго драйвера. На этом драйвере висят 8 сегментов(8 * 4 = 32светодиода)
  6. CLK - clock. Тактируем..
  7. Iset - установка максимальной яркости led. НЕ ЯРКОСТИ, как многие(судя по форумам) понимают. Яркость задаётся ШИМом и устанавливается значением регистра. Для NONAME светодиодов которые попались - 37кОм слишком много - еле видны, а 31кОм - самое то. Значение устанавливается в зависимости от мощности нагрузки - читаем даташит.
  8. VCC - питание 5v

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

Для эксперементов подключил atmega8, вот таким способом:

Разумеется, можно было без кварца, для такой фигни-то. Просто он был на "отладочной плате" - ну и пусть. Также, не отображён коннектор для прошивки. Питалось это всё от USB.
Забыл нарисовать резистор 10кОм подключённый между VCC и ногой RESET - без него мега если и запустится, то будет от каждого чиха перезагружаться

Прошивка

Сначала хотел управлять через usb - но раздумал, не стоит это того, всё равно скоро отдавать, да и практической пользы мало.

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

I/O

Не буду пересказывать даташит. Комманда состоит из 2 байт - в старшем: старшие 4 бита - незначащие, младшие - комманда. Второй байт(младший) - если можно так выразится - аргументы для комманды, ну или значения которые нужно положить в определённый регистр драйвера.

Несколько вспомогательных функций для работы с CS, DIN и CLK линиями.

#define LOW 0
#define HIGH 1

void led_cs1(char x) {
PORTC = x ? PORTC | _BV(4) : PORTC & ~_BV(4);
}
void led_cs2(char x) {
PORTC = x ? PORTC | _BV(5) : PORTC & ~_BV(5);
}
void led_clk(char x) {
PORTD = x ? PORTD | _BV(7) : PORTD & ~_BV(7);
}
void led_din(char x) {
PORTD = x ? PORTD | _BV(6) : PORTD & ~_BV(6);
}

Аргумент у них - должен отвечать на вопрос: установить ли 1 на линии?

Когда умеем дёргать линии, можно посылать данные:

void outputByte(unsigned char val) {
for(signed char i = 7; i >= 0; i--) {
led_din(val & (1 << i));
_delay_ms(CLOCK_TIME_MS /2);

led_clk(HIGH);
_delay_ms(CLOCK_TIME_MS);

led_clk(LOW);
_delay_ms(CLOCK_TIME_MS);
}
}
void outBytes(char pin, unsigned char reg, unsigned char dat) {
PORTC &= ~_BV(pin);
outputByte(reg);
outputByte(dat);
PORTC |= _BV(pin);
}

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

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

#define outBytesChip1(reg, dat) outBytes(PIN_CS1, reg, dat);
#define outBytesChip2(reg, dat) outBytes(PIN_CS2, reg, dat);

void outBytesChips(unsigned char reg, unsigned char dat) {
outBytesChip1(reg, dat);
outBytesChip2(reg, dat);
}

outBytesChipN() - через дефайн, т.к. эксперементально определил что прошивка меньше места занимает :)

Инициализация

Как я уже писал выше - промучился, пока жостко не проинициализировал.

void init() {
// configure pins to output
DDRC |= _BV(5) | _BV(4);
DDRD |= _BV(6) | _BV(7);

// pre-init drivers line
led_cs1(HIGH);
led_cs2(HIGH);
led_clk(LOW);

// setup clock interrupt and prescaler
TCCR0 |= (1<<CS02)|(1<<CS00);
TIMSK |= (1<<TOIE0);
TCNT0 = 0;

// initialize drivers
outBytesChips(0xc, (1)); // shutdown
outBytesChips(0xa, (15)); // intensity
outBytesChips(0x9, 0); // decode mode
outBytesChips(0xf, 0); // test mode
outBytesChips(0xb, 7); // scan limit

// finally, enable interrupts
sei();
}

Для чего нужны прерывания по таймеру? Ниже.

Управление светодиодами

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

Я сделал нечто "видеопамяти". Некоторый буффер, в котором хранятся значения цветов для каждого светодиода. Элементарное обращение - через несколько функций, которые знают в какую часть массива "видеопамяти" полезть и какие биты прочитать/изменить.

Каждая ячейка состоит из 2х бит - цвета.

enum LedStatus{
lsOff, lsGreen, lsRed, lsOrange
};

Говорящие названия - комментировать не нужно.

Выделяем память под массив "видеопамяти" и флажок - признак того, что содержимое памяти изменилось и нужно снова посылать новые значения в драйверы.

char buffman_changed = 0;
char buffman_data[13];

Функции для манипуляции с массивом таковы:

LedStatus buffman_get(unsigned int num) {
if (num > 52) return lsOff;
int bitcount = (num * 2);
int off_bit = bitcount % 8;
return (LedStatus) ((buffman_data[bitcount/8] & (3 << off_bit)) >> off_bit);
}
void buffman_setAll(LedStatus stat) {
unsigned char mask = stat << 0 | stat << 2 | stat << 4 | stat << 6;
for(int i = 0; i < 13; i++) buffman_data[i] = mask;
buffman_changed = 1;
}
void buffman_set(unsigned char num, LedStatus stat) {
if (num > 51) return;
int bitcount = (num * 2);
int off_byte = num >> 2, off_bit = bitcount % 8;
buffman_data[off_byte] = (buffman_data[off_byte] & ~(3 << off_bit)) | (((char)stat) << off_bit);
buffman_changed = 1;
}

Суть одна - умеют работать с "видеобуфером".

Самое интересное - то как эта "видеопамять" отображается на массив. По таймеру.

ISR(TIMER0_OVF_vect) {
int mask = 0;
if (!buffman_changed) return;

for(int i = 0; i < 15; i++) {
mask = 0;
for(int j = 0; j < 4; j++) {
switch(buffman_get(i*4+j)) {
case lsOff: continue;
case lsOrange: mask |= 2 << redMatrix[j] | 1 << greenMatrix[j]; break;
case lsRed: mask |= 2 << redMatrix[j]; break;
case lsGreen: mask |= 1 << greenMatrix[j]; break;
}
}

if (i < 8) {
outBytesChip2(i+1, mask);
} else {
outBytesChip1(i-7, mask);
}
}
}

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

При том, маска для каждого номера светодиода и цвета в определённой позиции лежит в

static unsigned char redMatrix[] = {4, 2, 0, 6},
greenMatrix[] = {6, 4, 2, 0};

А теперь можно в цикле рисовать в массиве через через buffman_set() с определённой задержкой - и эти изменения практически моментально отразятся на светодиодной линейке.

Наример вот такая прошивка:

int main(void)
{
init();

buffman_setAll(lsOff);

int dir = 1, i = 1;
LedStatus ls = lsRed;
do {
buffman_set(i-1, lsOrange);
buffman_set(i, lsRed);
buffman_set(i+1, lsRed);
buffman_set(i+2, lsGreen);
if (i == 0 || i == 49) dir = - dir;
i+=dir;
wait(25);
if (i%2) buffman_set(0, (buffman_get(0) == lsOff ? lsRed : lsOff ));
if (i%2==0) buffman_set(51, (buffman_get(51) == lsOff ? lsRed : lsOff ));

} while( 1 );

return 0;
}

Делает вот такое:

Ещё вот баловался:

На этом всё

На этом всё. Поиграл - и хватит. Делюсь файлами.
Полный текст прошивки:

#include <avr/io.h>
#include <avr/eeprom.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>

#define PIN_CS1 4
#define PIN_CS2 5

// Clock duration
#define CLOCK_TIME_MS 0.0005

#define LOW 0
#define HIGH 1

static unsigned char redMatrix[] = {4, 2, 0, 6}, greenMatrix[] = {6, 4, 2, 0};

enum LedStatus{
lsOff, lsGreen, lsRed, lsOrange
};

char buffman_changed = 0;
char buffman_data[13];

LedStatus buffman_get(unsigned int num) {
if (num > 52) return lsOff;
int bitcount = (num * 2);
int off_bit = bitcount % 8;
return (LedStatus) ((buffman_data[bitcount/8] & (3 << off_bit)) >> off_bit);
}
void buffman_setAll(LedStatus stat) {
unsigned char mask = stat << 0 | stat << 2 | stat << 4 | stat << 6;
for(int i = 0; i < 13; i++) buffman_data[i] = mask;
buffman_changed = 1;
}
void buffman_set(unsigned char num, LedStatus stat) {
if (num > 51) return;
int bitcount = (num * 2);
int off_byte = num >> 2, off_bit = bitcount % 8;
buffman_data[off_byte] = (buffman_data[off_byte] & ~(3 << off_bit)) | (((char)stat) << off_bit);
buffman_changed = 1;
}

void led_cs1(char x) {
PORTC = x ? PORTC | _BV(4) : PORTC & ~_BV(4);
}
void led_cs2(char x) {
PORTC = x ? PORTC | _BV(5) : PORTC & ~_BV(5);
}
void led_clk(char x) {
PORTD = x ? PORTD | _BV(7) : PORTD & ~_BV(7);
}
void led_din(char x) {
PORTD = x ? PORTD | _BV(6) : PORTD & ~_BV(6);
}
//#define led_din(x) PORTD = x ? PORTD | _BV(6) : PORTD & ~_BV(6);

void outputByte(unsigned char val) {
for(signed char i = 7; i >= 0; i--) {
led_din(val & (1 << i));
_delay_ms(CLOCK_TIME_MS /2);

led_clk(HIGH);
_delay_ms(CLOCK_TIME_MS);

led_clk(LOW);
_delay_ms(CLOCK_TIME_MS);
}
}

void outBytes(char pin, unsigned char reg, unsigned char dat) {
PORTC &= ~_BV(pin);
outputByte(reg);
outputByte(dat);
PORTC |= _BV(pin);
}

#define outBytesChip1(reg, dat) outBytes(PIN_CS1, reg, dat);
#define outBytesChip2(reg, dat) outBytes(PIN_CS2, reg, dat);

void outBytesChips(unsigned char reg, unsigned char dat) {
outBytesChip1(reg, dat);
outBytesChip2(reg, dat);
}

void init() {
// configure pins to output
DDRC |= _BV(5) | _BV(4);
DDRD |= _BV(6) | _BV(7);

// pre-init drivers line
led_cs1(HIGH);
led_cs2(HIGH);
led_clk(LOW);

// setup clock interrupt and prescaler
TCCR0 |= (1<<CS02)|(1<<CS00);
TIMSK |= (1<<TOIE0);
TCNT0 = 0;

// initialize drivers
outBytesChips(0xc, (1)); // shutdown
outBytesChips(0xa, (15)); // intensity
outBytesChips(0x9, 0); // decode mode
outBytesChips(0xf, 0); // test mode
outBytesChips(0xb, 7); // scan limit

// finally, enable interrupts
sei();
}

ISR(TIMER0_OVF_vect) {
int mask = 0;
if (!buffman_changed) return;

for(int i = 0; i < 15; i++) {
mask = 0;
for(int j = 0; j < 4; j++) {
switch(buffman_get(i*4+j)) {
case lsOff: continue;
case lsOrange: mask |= 2 << redMatrix[j] | 1 << greenMatrix[j]; break;
case lsRed: mask |= 2 << redMatrix[j]; break;
case lsGreen: mask |= 1 << greenMatrix[j]; break;
}
}

if (i < 8) {
outBytesChip2(i+1, mask);
} else {
outBytesChip1(i-7, mask);
}
}
}

inline void wait(float ms) {
for(; ms > 0; ms-=1) _delay_ms(1);
}

int main(void)
{
init();

buffman_setAll(lsOff);

int dir = 1, i = 1;
LedStatus ls = lsRed;
do {
buffman_set(i-1, lsOrange);
buffman_set(i, lsRed);
buffman_set(i+1, lsRed);
buffman_set(i+2, lsGreen);
if (i == 0 || i == 49) dir = - dir;
i+=dir;
wait(25);
if (i%2) buffman_set(0, (buffman_get(0) == lsOff ? lsRed : lsOff ));
if (i%2==0) buffman_set(51, (buffman_get(51) == lsOff ? lsRed : lsOff ));

} while( 1 );

return 0;
}


А также запакованный вариант - вместе с мейкфайлом и прошивкой: led-line-firmware.tar.gz

UPD

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


inline void wait(int ms) {
for(; ms > 0; ms-=1) _delay_ms(1);
}

void e1() {
int dir = 1, i = 1;
for(int j = 0; j < 300 ; j++) {
buffman_set(i-1, lsOrange);
buffman_set(i, lsRed);
buffman_set(i+1, lsRed);
buffman_set(i+2, lsGreen);
if (i == 0 || i == 49) dir = - dir;
i+=dir;
wait(25);
if (i%2) buffman_set(0, (buffman_get(0) == lsOff ? lsRed : lsOff ));
if (i%2==0) buffman_set(51, (buffman_get(51) == lsOff ? lsRed : lsOff ));
}
}
void e2() {
LedStatus ls = lsRed;
int i = 1, len=6, end = 52;;
int delay = 14;
while(end > 0) {
for(i = 0; i < end;i++) {
for(int k = 0; k < len; k++) {
buffman_set(k+i, ls);
}
buffman_set(i-1, lsOff);
wait(delay);
}
delay++;
end--;end--;
if (ls == lsRed) ls = lsGreen;
else if (ls == lsGreen) ls = lsOrange;
else if (ls == lsOrange) ls = lsRed;
}
}

void e3() {
for(int dir = 1, i = 1, j = 0; j < 400; j++) {
buffman_set(i, lsRed);
buffman_set(dir>0?i+1:i-1, lsRed);
buffman_set(i-dir, lsOff);

buffman_set(52-i, lsGreen);
buffman_set(52-i-(dir>0?+1:-1), lsGreen);
buffman_set(52-i+dir, lsOff);

if(i > 52/2-10) {
for(int k = 0; k < i-20; k++) {
buffman_set(k, lsOrange);
buffman_set(52-k, lsOrange);
}
}

i += dir;
if (i == 0 || i == 52/2) dir = - dir;
wait(31);
}
}

void (*examples[]) (void) = { &e3, &e2, &e1};

int main(void)
{
init();

buffman_setAll(lsOff);

for(int i = 0; ; i = ++i % (sizeof(examples)/sizeof(examples[0]))) {
examples[i]();
for(int b = 15; b > 1; b--) {
outBytesChips(0xa, (b)); // intensity
wait(150);
}
buffman_setAll(lsOff);
wait(300);
outBytesChips(0xa, (15)); // intensity

}

return 0;
}

Обожаю си за возможность писать такие выверты :)
Всю прошивку можно скачать с исходниками: ledline-firmware-3-effects.tar

Ну и видео

The post Cветодиодная линейка на MAX7219 first appeared on Hey, ruX is here..]]> https://rux.vc/2010.04/led-line-based-on-max7219/feed/ 3 467 CPU load indicator https://rux.vc/2010.03/cpu-load-indicator/ https://rux.vc/2010.03/cpu-load-indicator/#comments Thu, 04 Mar 2010 09:26:39 +0000 http://rux.pp.ru/blog/?p=378 Что это? Этот проект может стать хорошим начальным опытом в разработке устройств на микроконтроллере и программировании его, как прошивки мк так и создании управляющей программы. Собственно это очень простое устройство, плавно показывающее текущую нагрузку процессора меняя яркость светодиода(ну или по желанию можно использовать другую нагрузку). Людям, которые занимаются моддингом особо думаю понравится - нужно только ... Read more

The post CPU load indicator first appeared on Hey, ruX is here..]]> Что это?

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

Собственно это очень простое устройство, плавно показывающее текущую нагрузку процессора меняя яркость светодиода(ну или по желанию можно использовать другую нагрузку). Людям, которые занимаются моддингом особо думаю понравится - нужно только приложить фантазию :) Работает через USB, причём программный, реализованный с помощью прооекта V-USB. В качестве мк выбран Atmega8

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

Принцип работы

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

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

Подробнее

Девайс

Схема достаточно простая и вполне собирается легко на макетной плате(у кого она есть) или как у меня - на картонке :) Конечно же, при желании можно сделать печатную плату - будет шикарно - я делать не стал, потому, что CPU load indicator оказался промежуточным этапом к большему проекту который я сейчас делаю. Конечно, гик скажет, что это слишком просто, чтоб уделять этому внимание, но кто-то только учиться, вроде меня =:)

Комментарии по схеме:

  • J1 - USB порт к компьютеру(D- это вторая нога, D+ это третья), J2 - SPI видимо к программатору :)
  • X1, C5, C6 - генератор. Кварц можно поставить, например, на 15МГц, главное, чтоб V-USB поддерживал эту частоту, а кондёры тут от 18 до 22пф можно выбирать. У меня 22пф стоят
  • R1 - подтягивающий резистор, лучше всё-таки 10кОм. Для работы мк ведь требуется reset пассивный, а т.к. он инверсный, нужно подать "1". По идее, там есть внутри 100кОм, но как пишут, нога ловит каждый чих
  • D2, D3 - стабилитроны для того, чтоб не превысить напряжение на линии USB - так должно быть по стандарту, единица - не должна привышать 3.6в. У меня стеклянные - чёрной полоской к сигнальным линиям(D+ & D-)
  • R4, R5 - везде стоят по 68 Ом, у меня нормально работает 100 Ом. Если я правильно понимаю, они нужны чтоб не получилось ситуации, когда можно спалить порт мк
  • R2 - нужно оставить именно таким, это некая индикация USB-хосту что подключённо низкоскоростное устройство. Для эксперемента можно подцепить к usb только этот резюк и ядро будет писать что обнаруженно новое низкоскоростное устройство.
  • C3 - сглаживает помехи по питанию

ШИМ (PWM)

Наверное всё это мутно - интервалы, шаги, яркость.. Так вот, "яркость" - это численное значение от 0..255 - значение, которое подаётся на ШИМ(Широтно - Импульсная Модуляция) выход. Про ШИМ можно много где прочитать, мне понравилось на myRobot. Соответственно максимальной яркости(состоянию, в котором максимальное количество "1") соответствует 255, минимальной - 0(максимальное количество "0"), среднему - 127(примерное равное количесво "1" и "0"). Думаю логика прослеживается.

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

Как я уже указал, программа посылает уже конкретное значение ШИМ которое нужно установить. Но перед отправкой, нужно его ещё вычислить. Т.е. при загрузки процессора в 100% яркость индикатора должна быть максимальной, а не (если бы послать просто значение ШИМ 100) меньше половины от полной. Для этого нужно пересчитать его по простой формуле: (cpu_load * 255/100), где cpu_load - текущая нагрузка процессора.

Надеюсь пока ещё понятно, я ж предупредил что минимальная подготовка должна быть =).
А ведь вполне может быть такая ситуация, что светодиод начинает светиться только от значния 80 в ШИМ? Вполне может быть - значит при маленькой нагрузке мы вообще не увидим свечения. А что, если после ШИМ 200 индикатор так ярко светит, что кажется, вот-вот сгорит? Можно прийти в выводу, что требуется поставить рамки от и до и высчитывать соответственно величину ШИМ. Вычисляется по формуле(выжимка из кода):
cpu_load = ((valueMax - valueMin) / 100.0 ) * cpu_load + valueMin ;
Названия переменных говорят за себя, пояснения не требуются, как я думаю.

Управляющая программа(сторона компьютера) - драйвер

Основная программа сосредоточенна в software/cpu_indicator.c.
Внимание! Для сборки приложения нужно воспользоваться коммандой make clean all. Для запуска(из папки software) ./cpuload_indicator.
У вас обязательно должен быть установлен пакет libusb-dev и libgtop-dev, иначе ничего не соберётся. Разумеется в зависимости от дистрибутива исходные коды этих библиотек могут отличаться названием.

libusb нужен очевидно для работы с USB, а libgtop для получения информации о текущей нагрузке процессора.

В начале software/cpu_indicator.c подключаются хедеры и указываются дефолтные значения переменных.
О функциях

  1. bool parseOpts(int, char *) - служит для парсинга коммандной строки и проверки на корректность значений.
  2. bool connectUsb() - ищет устройство среди всех и открывает его, если нашла. А если не нашла то в зависимости от наличия аргумента коммандной строки -catch будет пытаться искать снова или просто попросит завершить работу программы с информацией о том, что устройство не найдённо. В противном случае, если указан -catch программа будет ждать пока подключат устройство. После открытия успешного устройства посылается комманда устанавливающая шаг времени, с которым значение ШИМ приблежаться к новому. Этот аргумент можно задать в коммандной строке ключом -step N, где N - значение задержки в мсек.
  3. int main (int, char *) - собвственнно входная точка программы. Вызывает parseOpts() и connectUsb(), высчитывает нагрузку на процессор за время в процентах, переводит в соответствующее значение ШИМ с учётом верхних и нижних смещений границ(о чём речь шла ранее) и посылает значение в USB. При ошибке, в зависимости от -catch, либо завершается работа программы, либо пытается подсоединиться снова, если аргумент указан.
    Особенно сложным оказалось для меня получение информации о нагрузки на процессор. Я воспользовался статьёй Calculating CPU Usage from /proc/stat, где нагрузка вычисляется bash скриптом и берётся информация из /proc/stat.
  4. void usage(char *) - выводит информацию об использовании, лучше показать:

    $ ./cpuload_indicator -help
    Control program for CPU Load indicator (c) ruX 2010
    Usage ./cpuload_indicator [option=[value]] ..
    Options:
    -min NN - set minimal PWM value [0..255]
    -max NN - set maxmimum PWM value [0..255]
    -step NN - set step interval for LED (in msec)
    -update NN - interval for update load about current CPU(in seconds)
    -catch - never quit(always trying to catch device)
    -help - this help promt
    Copyright by ruX, 2010, http://ruX.pp.ru/

Думаю на столько краткого описания достаточно. За подробностями - в исходник. Есть ещё файл obdev_usb.c - там лежат довольно стандартные функции для открытия устройства(по его VID:PID, имени, имени разработчика) - они качуют из различных проектов, иногда немного правясь. Так и я взял за из проекта usb-relay.

Программа прошивки

Разумеется, всё что относится к прошивке девайса лежит в firmware, как ни странно :)

Код программы для мк можно разделить условно на 2 части: работа с USB, реализованная с помощью библиотеки V-USB и основной логики.

Важный этап - настройка V-USB, которая находится в файле firmware/usbdrv.h. То, что там определенно будет решать каким будет устройство. Файл шаблонный, от obdev. Но добавил 2 строчки, которые определяют константы комманд, которые посылает компьютер - для установки нового значения ШИМ и установки интервала шага приближения к новому значению:
#define REQUEST_SET_TARGET 1
#define REQUEST_SET_STEP 2

В основном файле логики firmware/cpuload_indicator.c сначала устанавливается конфигурация перефирии: направление вывода и настройка ШИМ.
// Configure port B pin 1 as output
DDRB = (_BV(1));

// Setup PWM
TCCR1A=0xA1;
TCCR1B=0x09;
TCNT1H=0x00;

Дальше вызывается process() в котором и происходит основная работа - один раз инициализируется USB и начинается бесконечный цикл, в котором происходит опрос usb - usbPoll() и приближение значения ШИМ, выполняется маленькая задержка:

void process(void)
{
unsigned int dsec = 0;

for(startUsb(); ;dsec++){
usbPoll();

if (dsec % (delay * 10) == 0 && OCR1A != target) {
if (OCR1A > target) OCR1A--; else OCR1A++;
}

_delay_ms(0.1);

if (dsec == 10000) dsec = 0;
}
}

У меня в качестве выхода ШИМ используется T/C1 - PORTB, бит 1, нога 15 в PDIP корпусе, соответственно имеем дело с OCR1A. Ещё нюанс: компьютер посылает интервал шага приближения в мсек, а внутри цикла задержка 0.1мсек, поэтому приходиться делать (delay * 10), чтоб привести к одному порядку - к примеру у нас компьютер передал,что шаг - 50мсек(=5 * 10-2, значит нужно сделать 50 * 10 = 500 циклов перед тем, как будет приблежение значения ШИМ к новому.

Если кто то не понял код выше - в цикле сначала происходит опрос, а дальше проверяется, если наступило время, когда нужно сделать шаг(т.е. интервал задержки прошёл) и при этом текущее значение ШИМ это не то, что компьютер "попросил" выставить, то приблежаемся к требуемому значению. Дальше задержка на 10-4сек и попытка избежать переполнения если число в счётчике циклов dsec достаточно большое.

Ещё определенна uchar usbFunctionSetup(uchar data[8]), которая вызывается, когда компьютер послал данные - в нашем случае это либо новое значение ШИМ, либо установка интервала шага приблежения.

uchar usbFunctionSetup(uchar data[8])
{
usbRequest_t *request = (usbRequest_t*) data;
switch (request->bRequest) {
case REQUEST_SET_TARGET:
target = request->wValue.bytes[0];
break;

case REQUEST_SET_STEP:
delay = (short int)(request->wValue.bytes);
break;
}

return 0;
}

Структура usbRequest_t *request содержит информацию о том, что нам пришло, подробнее можно узнать в доках. request->bRequest определяет номер комманды, а request->wValue.bytes переданные от компьютера данные.
target - значение ШИМ, которое нужно установить, фактически используется только 1 байт, поэтому и выбираем только первый байт из того, что пришло. А delay - задержка в милисекундах, поэтому тут одним байтом не обойтись, берём 2 сразу, делая тайпкастинг к short int.

Прошивка прошивки :)

В firmware/ определён мэйкфайл, который можно настроить под себя - в моём случае я использовал мк atmega8, программатор usbasp и частота цварца - 12MГц. По желанию можно изменить:

. . . .
DEVICE = atmega8
PROGRAMMER = usbasp
FREQ = 12000000
. . . .

Чтоб полностью откомпилировать, прошить программу и фьюзы, достаточно выполнить make clean all flash fuse :) Из фьюзов нужно отметить, что установленно тактирование от кварца, свыше 12МГц, кому интересно найдут интерпретацию фьюзов. Кстати о них(для atmega8) : старший байт - 0xC9, младший - 0xEF

Фото

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

Финал

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

Это - всё таки посложнее просто миганием светодиодов. И даже посложнее чем мигание светодиодов через USB(кстати, огромное спасибо проекту usb-Relay, который помог мне разобраться во многом).

Стоимость сборки такого устройства порядка 100-120р(по крайней мере с ценами, которые в мегаэлектронике в СПБ)

У линуксодидов проблемм быть не должно. У *bsd и solaris как я понимаю тоже нет(разве что поправить пути к инклюдам в мейкфайле). С виндой всё хуже. То, что нужно libusb это очевидно, кто чистал описание проекта V-USB сразу это поняли. По идее, как я понимаю, ничего не изменится, кроме места получения текущей нагрузки процессора - тут придётся разбираться самостоятельно. Или, если получится, воспользоваться cygwin(не из за libusb, а из за libgtop!), если умеете, я если честно практически не предствляю что он умеет и как :) Ну и разумеется нужно иметь make & gcc & winAvr

Скачать прошивку, программу и схему(в формате KiCad) в одном файле: cpuload_indicator_v0.1.tar.gz

The post CPU load indicator first appeared on Hey, ruX is here..]]> https://rux.vc/2010.03/cpu-load-indicator/feed/ 13 378