К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

А есть программеры МК, желающие передать опыт? )

Гость
0 - 13.12.2011 - 03:24
На безвоздмезной дружеской основе? ) Я не говорю про занятия или обучение с нуля, просто иногда возникают вопросы (в си++/ардуино), а спросить то блин в аське и некого.. Гугл выручает, но трудновато конечно с непривычки - программировал на более поздних вещах. По складу мозга, конечно, программист - в какой то степени на делфи, пхп и т.д.


Гость
1 - 13.12.2011 - 03:25
66945401
Гость
2 - 13.12.2011 - 12:46
А разве для ардуино используется C++ а не просто С.
Потом же та зачастую для всего есть библиотеки что сводит весь напряг к минимуму.
Гость
3 - 14.12.2011 - 04:45
3-TVV1 >вот например воспользовался я тремя библиотеками для написания довольно простой программы, и эта программа уже не влазит в 8кб атмеги.. А она еще не закончена.
Конечно, можно купить 168ю а лучше 328ю мегу и просто феном сменить камень, но это не тот путь, который мне видится правильным.

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

Опять же есть чужой код на ассемблере, программная реализация протокола чтения неких RFID-карт. Мне бы помочь по пониманию алгоритма, чтобы я мог переписать его на си и заставить работать..
Гость
4 - 14.12.2011 - 04:48
Хотелось бы скооперироваться с тем, кто имеет опыт работы с МК но не любит паять. Я б мог, например, изготавливать ему довольно качественно оные на смд компонентах. Всякие плюшечки, например. Программатор там простой или usb-uart маленький, как флешка.
Гость
5 - 14.12.2011 - 13:26
В atmega 8 влазит довольно много, с RFID это те что опрашиваются по 1-wire тоже проблем быть не должно
У того же atmel лежат датащеты с примерами как это реализовать (обмен по 1-wire) на C (там конечно не фонтан и они используют весь потенциал их девайса, но спецификациям сие творение соответствует)

ps у нас как то в atmega 8 чуть чуть не влезла прошивка для управления мини элеватором, пришлось ставить atmega 16. Приложения пишу на C с редкими ассемблерными вставками типа запрета / разрешения прерываний, не любитель я ассемблера из-за тог что такой код сложнее сопровождать, да и компиляторы сейчас научились хорошо код оптимизировать. Плюс если это творение кто то прочитает и дизассемблирует то и флаг ему в руки с разбором того что там оптимизатор наворотил ;)
Гость
6 - 14.12.2011 - 13:27
>и они используют весь потенциал их девайса
читать как и они НЕ используют весь потенциал девайса
Гость
7 - 15.12.2011 - 02:28
Ну конечно, чтобы использовать весь потенциал - нужен ассемблер.. Но минусы которые вы описали даже вижу. Чтобы заюзать RFID на готовом контроллере - да, читать даташит и работать по 1wire или i2c или то там еще хочет контроллер RFID. В моем случае схема аналоговая с программным считыванием карты - то есть программой надо реализовать часть протокола Манчестер, а я даже не читал еще его. Примеры не могу найти на си. Есть на Асме..
Не сможете помочь именно перевести часть программы на русский язык? Листинг вродене большой. С русского я уже переведу в си :)


;************************************************* ******************************
;*
;* Version: 0.50
;* Build: Июль 18, 2002 17:00:29
;*
;************************************************* ******************************

;******** Includes ************************************************** ***********

.include "2313def.inc"

;******** Constants ************************************************** **********

.equ fck = 8000000
.equ baud_rate = 19200
.equ ubrv = (fck/(16*baud_rate))-1

;******** Bit Definitions ************************************************** ****

.equ DEMOD = 0x01
.equ RDYCLK = 0x02
.equ SHD = 0x03
.equ MOD = 0x04

;******** Global Register Variables ********************************************

.def f0 = r0
.def a0 = r1
.def a1 = r2
.def a2 = r3
.def a3 = r4
.def f5 = r5
.def f6 = r6
.def f7 = r7
.def f8 = r8
.def f9 = r9
.def f10 = r10
.def f11 = r11
.def f12 = r12
.def f13 = r13
.def f14 = r14
.def sreg = r15
.def a = r16
.def b = r17
.def c = r18
.def d = r19
.def e = r20
.def f = r21
.def g = r22
.def h = r23
.def flags = r24
.def f25 = r25

;******** SRAM Variables ************************************************** *****

.dseg

.org 0x60

data0:
.byte 0x08
data1:
.byte 0x0b
free:
.byte 0x5d

.org 0xd0

stack:
.byte 0x10

.cseg

;******** Reset/Interrupt Vectors **********************************************

.org $000
rjmp setup ; Reset Handler
reti ; IRQ0 Handler
reti ; IRQ1 Handler
reti ; Timer1 Capture Handler
reti ; Timer1 Compare Handler
reti ; Timer1 Overflow Handler
reti ; Timer0 Overflow Handler
reti ; UART RX Complete Handler
reti ; UDR Empty Handler
reti ; UART TX Complete Handler
reti ; Analog Comparator Handler

;******** Setup ************************************************** **************

setup:

.org $00b

; Stack Pointer Initialization

ldi a, RAMEND
out SPL, a

; PIO Initialization

ldi a, 0b00000000
out PORTB, a
ldi a, 0b00000000
out PORTD, a
ldi a, 0b11111100
out DDRB, a
ldi a, 0b11111100
out DDRD, a

; Sleep Mode/WatchDog Initialization (PowerDown; WD Disabled)

ldi a, 0b00110000
out MCUCR, a
ldi a, 0b00011000
out WDTCR, a
ldi a, 0b00010000
out WDTCR, a

; Analog Comparator Initialization

ldi a, 0b10000000
out ACSR, a

; Timer1 Initialization

;ldi a, 0b01000000 ; Toggle OC1 on compare match
;out TCCR1A, a
;ldi a, 0b00001001 ; Clear T/C1 on compare match; CK
;out TCCR1B, a
;ldi a, 0x00
;out TCNT1H, a
;out TCNT1L, a
;ldi a, 0x00
;out OCR1AH, a
;ldi a, 0x20
;out OCR1AL, a

; UART Initialization

ldi a, 0b00011000
out UCR, a
ldi a, ubrv
out UBRR, a

; Interrupts Initialization

sei

;************************************************* ******************************
; Main Program
;************************************************* ******************************

clr flags
cbi PORTB, SHD
cbi PORTB, MOD
m0:
rcall rd0
rcall shift
brcs m0
ldi a, '>'
rcall tx_byte
ldi XL, low(data0)
ldi XH, high(data0)
ldi e, 0x05
m1:
ld a, X+
rcall tx_hex8
dec e
brne m1
rcall tx_crlf
rjmp m0

;************************************************* ******************************

rd0:
ldi XL, low(data0)
ldi XH, high(data0)
rd1:
ldi g, 0x00
rd2:
rcall nxt_bit
brcs rd1
rcall nxt_bit_delay
cpi g, 0xff
breq rd5
rjmp rd2
rd3:
ldi h, 0x08
rd4:
rcall nxt_bit
brcs rd0
rcall nxt_bit_delay
dec h
brne rd4
rd5:
st X+, g
cpi XL, low(data0+0x08)
brne rd3
ret

nxt_bit:
;
n_bit0a:
clr a0
ldi e, 0x04
n_bit1:
sbic PINB, DEMOD
inc a0
nop
nop
nop
dec e
brne n_bit1
mov e, a0
andi e, 0b11111011
brne n_bit0a
ldi e, 0x00
sbrc a0, 0x02
ldi e, 0x01
;
ldi a, 0x20
nxt_bit0:
clr a0
ldi c, 0x04
n_bit3:
sbic PINB, DEMOD
inc a0
nop
nop
nop
dec c
brne n_bit3
mov c, a0
andi c, 0b11111011
breq n_bit4
nop
nop
nop
nop
rjmp nxt_bit0a
n_bit4:
ldi c, 0x00
sbrc a0, 0x02
ldi c, 0x01
cp c, e
brne nxt_bit1
nxt_bit0a:
nop
nop
nop
dec a
brne nxt_bit0
sec
ret
nxt_bit1:
lsl g
sbrc e, 0
inc g
clc
ret

nxt_bit_delay:
ldi a, 0x00
rcall delay_us
ldi a, 0xa0

delay_us:
dec a
delay_us0:
nop
nop
nop
nop
nop
dec a
brne delay_us0
ret

;************************************************* ******************************

shift:
ldi YL, low(data0)
ldi YH, high(data0)
ld a, Y
cpi a, 0xff
brne shift_err
ldd a, Y+0x07
andi a, 0x01
brne shift_err
rcall shift_sub0
brcc shift_err
ldi XL, low(data1)
ldi XH, high(data1)
ldi g, 0x0b
shift_0:
ldi c, 0x00
ldi e, 0x05
shift_1:
rcall shift_sub0
rol c
dec e
brne shift_1
st X+, c
dec g
brne shift_0
ldi XL, low(data1)
ldi XH, high(data1)
ldi c, 0x00
ldi e, 0x0b
shift_2:
ld a, X+
eor c, a
dec e
brne shift_2
andi c, 0x1e
brne shift_err
ldi XL, low(data1)
ldi XH, high(data1)
ldi g, 0x0a
shift_3:
ld a, X
rcall shift_sub1
sbrc c, 0
rjmp shift_err
st X+, a
dec g
brne shift_3
ldi YL, low(data0+0x05)
ldi YH, high(data0+0x05)
ldi e, 0x05
shift_4:
ld a, -X
ld c, -X
swap c
or a, c
st -Y, a
dec e
brne shift_4
clc
ret
shift_err:
sec
ret
shift_sub0:
ldd a, Y+0x07
rol a
std Y+0x07, a
ldd a, Y+0x06
rol a
std Y+0x06, a
ldd a, Y+0x05
rol a
std Y+0x05, a
ldd a, Y+0x04
rol a
std Y+0x04, a
ldd a, Y+0x03
rol a
std Y+0x03, a
ldd a, Y+0x02
rol a
std Y+0x02, a
ldd a, Y+0x01
rol a
std Y+0x01, a
ret
shift_sub1:
lsr a
ldi e, 0x01
ldi c, 0x00
brcc PC+0x02
ldi c, 0x01
sbrc a, 0
eor c, e
sbrc a, 1
eor c, e
sbrc a, 2
eor c, e
sbrc a, 3
eor c, e
ret

;******** UART Subroutines ************************************************** ***

tx_crlf:
ldi a, 0x0d
rcall tx_byte
ldi a, 0x0a
rjmp tx_byte

tx_hex8:
push a
swap a
rcall tx_hex80
pop a
tx_hex80:
andi a, 0x0f
ldi c, 0x30
cpi a, 0x0a
brlo tx_hex81
ldi c, 0x37
tx_hex81:
add a, c
rjmp tx_byte

rx_byte:
in c, USR
sbrs c, RXC
rjmp rx_byte
in a, UDR
ret

tx_byte:
in c, USR
sbrs c, UDRE
rjmp tx_byte
out UDR, a
ret

;************************************************* ******************************

.org FLASHEND

rev:
.dw 0x0100
Гость
8 - 15.12.2011 - 12:25
Мы для работы с RFID картами типа е-марин используем считыватель типа CP-Z2L http://ironlogic.ru/il.nsf/pages/cpz2l с него данные берем по 1-wire, там имитируется i-button типа DS1990A.

Но если погуглить то вот что то похожее на то что тебе нужно, но как оно работает хз, тут уже нужно разбираться стем как и что там кодируется и передается ;)
http://www.530.ru/wwwboards/mcontrol.../1190473.shtml
Гость
9 - 16.12.2011 - 09:04
9-TVV1 >[*****], вот спасибо!
zeb
10 - 26.12.2011 - 16:08
Глубоко извиняюсь если моя мысль кому то покажется "не в тему", но и промолчать не могу.
У меня не большой но все же опыт работы в разных компаниях имеющих в том числе дело и с железом разного уровня. Так вот везде ассемблер использовался только для загрузчиков либо же если было ООЧЕНЬ узкое место. Местами использовался Си, там где надо поближе к железу, в остальном же нормальный C++ а то и что нибудь еще выше. Сейчас вычислительные мощности не стоят ничего вообще. А время работы программиста все еще в цене. Т.е если прикинуть то разница в цене между 168 и 328 мегой это даже меньше чем час работы программиста. и если ты не делаешь серию в миллион экземпляров то решать как "впихнуть невпихуемое" получается дороже.
другой дело ардуино - изначально вещь придуманная для развлечения а не для денег. там конечно можно и поковыряться, и получить от этого какое то моральное удовлетворение.
если же надо что бы работало то не стоит опускаться ниже чем Си, да и до него только в крайнем случае.
Гость
11 - 07.01.2012 - 05:00
11-zeb >Мнение интересное. Но чтобы склонится к какому либо мнению мне самому, нужно прочувствовать разницу. Я уже сталкивался с нехваткой памяти в простейших устройствах. 7кб оказалось мало для вывода десятка сообщений в сериал и приема пары команд, двух-трех циклов с чтением-записью в ееепром и т.д.

Возможно, это потому что у меня не "чистый" си++ а набор библиотек в ардуино..
Гость
12 - 07.01.2012 - 11:39
to12
А с настройками компилятора пробовал поиграться. Возможно там включено добавление отладочной информации, плюс включена оптимизация по скорости а не по размеру ну или что то подобное.
Вообще для обозначенной задачи amega8 должно хватить.
Гость
13 - 09.01.2012 - 13:51
Савелий, советую для разнообразия попробовать любой хоть самый младший ARM (что-нибудь из AT91SAM например). Цены на них уже не кусаются, а мощности совсем другие. Начать на них не так уж трудно, программаторы специальные не нужны (по UART/USB зашиваются), примеров куча, в ассемблер лезть не нужно совсем (берётся типовой ассемблерный стартовый код, а своё всё на С пишется). Качаете какую-нибудь среду (Keil MDK ARM например) и пробуете прилагающиеся примеры.
Разница с 8бит принципиальная - спокойно занимаетесь непосредственно решением задачи вместо борьбы с узкими местами. Вообще не раз замечал - люди, долгое время просидевшие на 8бит (особенно на PIC в ассемблере) что называется перестают "видеть лес за деревьями", начинают зацикливаться на мелочах, не могут охватить общую идею большого проекта итд. В двух словах: не увлекайтесь извращёнными ассемблерами, рискуете безнадёжно испортить стиль :)
Гость
14 - 09.01.2012 - 15:55
to 14 Сам давно на арм поглядываю, но все упирается в средства для разработки вот тот же keil там только кастрированная версия бесплатна, а остальные стоят очень дорого от 800$ за чуть менее кастрированную версию до 11000 за полную. Это не подъемно. Уж лучше на арм загнать CoDeSys и там писать на ST, ну или извращаться на блочной логике (в общем то тогда лучше взять готовую плату под CoDeSys)
Гость
15 - 09.01.2012 - 17:36
15-TVV1 >так GCC ж бесплатный есть. Его и с Keil можно использовать - http://www.keil.com/arm/gnu.asp
Ещё у Philips для их LPC своя среда вроде бесплатная имеется
Гость
16 - 09.01.2012 - 22:14
ARM - это не просто выше частота и больше память, но и более умная периферия, DMA всякие итд. Например данные в UART уже не побайтово посылаете, а просто кладёте в регистры начальный адрес буфера и длину и забываете про них, они сами уйдут пока процессор другими делами занимается. Ну и возможности роста ограничены только деньгами и фантазией :)
Гость
17 - 09.01.2012 - 23:29
Ну с UART и под атмегой нет проблем он же там тоже зачастую аппаратно реализован. Конечно без DMA. Но для удобства у меня обычно используется два кольцевых буфера один на прием другой на передачу. Так что получается почти тоже самое кинул в буфер и забыл. Другое дело если это RS485 там еще нужно на переключить направление на чтение по окончании передачи последнего байта.

На ARM смотрю потому что они производительнее, а по цене некоторые образцы дешевле атмеги. Но вот со средой разработки пока напряг. На счет того что к lite версии keil можно прикрутить GCC и тогда исчезнут ограничения по размеру кода - не знал.

Что касается Philips гляну
В общем спасибо за наводки ;)
18 - 11.01.2012 - 05:08
Спасибо, но это мне еще ой как рано))
Гость
19 - 11.01.2012 - 05:09
опять моя залогинилась пока отвернулся)
Гость
20 - 11.01.2012 - 17:56
Ну почему рано? Вы ж под Мегу на С пишете? С - он и на ARM такой же С, сразу погружаться во все тонкости периферии никто не заставляет, на первых порах можно и напрямую ногами поуправлять, а большие память/мегагерцы будут доступны сразу и без доп.усилий. В целом код решения одной и той же задачи на "большом" контроллере будет проще из-за меньшего кол-ва узких мест, с которыми придётся бороться.
Простейший пример из Keil, мигание диодами на LPC21xx:
Код:
#include <LPC21xx.H>                       /* LPC21xx definitions */

void wait (void)  **                        /* wait function */
  int  d;

  for (d = 0; d < 1000000; d++);           /* only to delay for LED flashes */
**

int main (void) **
  unsigned int i;                          /* LED var */

  IODIR1 = 0x00FF0000;                     /* P1.16..23 defined as Outputs */

  while (1)  **                             /* Loop forever */
    for (i = 1<<16; i < 1<<23; i <<= 1) **  /* Blink LED 0,1,2,3,4,5,6 */
      IOSET1 = i;                          /* Turn on LED */
      wait ();                             /* call wait function */
      IOCLR1 = i;                          /* Turn off LED */
    **
  **
**
вроде ничего страшного :)

Ещё раз повторюсь - богатый опыт решения "восьмибитных" проблем при дальнейшем росте скорее мешает. У нас работали разные люди, бывших 8битчиков было видно сразу - упёртая склонность к тому что называется "преждевременной оптимизацией", экономия на каждом битике где надо и где не надо (в основном), куча глобальных переменных, в итоге - "одноразовый" код. В итоге пришли к выводу что легче нормального программиста РС "спустить" на ARM, чем "поднять" на него закоренелого 8битчика.
Гость
21 - 11.01.2012 - 20:13
to 21

> куча глобальных переменных
Как бы С к этому располагает
Гость
22 - 11.01.2012 - 22:42
22-TVV1 >Имеете в виду что нельзя как в ++ упрятать данные в объекты? Всё было гораздо запущенней - люди прикидывали как бы сэкономить на передаче параметров (клали их в глобальные переменные чтоб явно не передавать), на объедках памяти (большой глобальный буфер на все случаи жизни, в котором и сборка/разборка пакетов, и тексты сообщений туда sprintfятся итд, и мучительная работа мозга чтоб оно там не встретилось между вызовами функций) и подобное :)
Гость
23 - 11.01.2012 - 23:11
>Имеете в виду что нельзя как в ++ упрятать данные в объекты
Именно это

>клали их в глобальные переменные чтоб явно не передавать)
Можно было положить в структуру и передавать указатель на нее

>(большой глобальный буфер на все случаи жизни, в >котором и сборка/разборка пакетов, и тексты >сообщений туда sprintfятся итд

Это конечно не гуд, и тут что то отлаживать будет то еще веселье особенно если учесть что кроме основного цикла есть еще прерывания ...
ps Но так делают даже крутые спецы. Вон читал про функции работы со строками в CoDeSys так там прямо сказано что их нельзя одновременно использовать в основном цикле и в прерываниях и это под ARM и ноги ясно откуда растут видать они тоже чего то там экономили и для них используют один глобальный буфер при обработке ;) А для пущей крутизны по моему еще и длину строки ограничили чуть ли не 80 символами ....
Гость
24 - 12.01.2012 - 00:49
Пример со строками и прерыванями в CoDeSys - несколько другой случай, это всего-навсего отсутствие "повторной входимости" (что-то более "прямого" перевода для reentrancy не вспоминается :)) - нельзя вызвать одну и ту же функцию параллельно из разных контекстов. Объявите статическую переменную в любой функции, и будет оно самое. У наших же чудиков всё было куда хуже - те использовали общий буфер из нескольких абсолютно разных функций - как раз травма мозга, нанесённая каким-нибудь младшим PIC c 224 байтами RAM
Гость
25 - 12.01.2012 - 16:28
"повторной входимость" для reentrancy - нормальный перевод, я бы перевел также.

>Объявите статическую переменную в любой функции,

ну так и получим по сути глобальную переменную, плюс не хорошую функцию, которая при одинаковых входных данных может вернуть разный результат, это смотря как там с этой статической переменной работают ;)
Гость
26 - 13.01.2012 - 07:38
21-flowswitch >ну я кстати PC программер, МК занялся очень недавно, для себя. Страху в программировании не вижу, но нужно наработать опыт "общего" плана. Ну а тогда - отчего бы и нет)
Гость
27 - 13.01.2012 - 07:42
Кстати, нет ни у кого возможности подсказать по расчету цепи? Необходимо заюзать прерывание, сигнал с катушки (автомобильная высоковольтная), с низковольтной части. Но там думаю "прострелы" такие могут быть что пц..
Пока нашел на транзисторе bc847, перед ним стабилитрон на опорное МК, ну и резистивных делителей пару и кондюки. Одна цепь реагирует на 12в, рядом точно такая же нет - не полностью закрывается транзистор. Ну и непонятно как правильно настроить прерывание..
Гость
28 - 14.01.2012 - 14:45
28-Савелий >заглядывал я в пару коробок автомобильных, на оптронах такие входы делают, через них больше чем надо не пройдёт
Гость
29 - 14.01.2012 - 17:20
29-flowswitch >ну это выход конечно, только устройство уже готово, отлажу его подбором делителя под конкретное авто а там видно будет. Чужой опыт конечно хорошо, но свой ничего не заменит.
Гость
30 - 14.01.2012 - 21:27
А нужно именно с катушки? А то где-то перед ней датчик Холла есть с более "мирным" сигналом. Но если машина не сильно старая, то там фаза будет несколько сдвинута (контроллер опережение меняет в зависимости от оборотов и пр.).
Тема плавно перешла в раздел "Радиолюбитель" :)
Гость
31 - 16.01.2012 - 02:42
31-flowswitch >да не суть важны сдвиги, тахометру просто мерять общее колво))
Хочется универсальности для карбов, не у всех есть ДХ. В общем, вот так сделал: http://grachev.distudy.ru/Uch_kurs/a...rinica/H/H.htm

в плане цепей к катушке) Сделал две таких, одна работает если исключить резистор 220ком вторая также при исключении чуть чуть не закрывается (транзистор).. чуть чуть нехватает чтобы МК за LOW принял. Это если 12в подавать на вход.


К списку вопросов
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск




Copyright ©, Все права защищены