| 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 >[*****], вот спасибо! | |
| 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в подавать на вход. | |
Интернет-форум Краснодарского края и Краснодара |
