ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
21 ноября
457135
Связанные сообщения
Холивар
Холивар: вот коллега переехал с STM32 на LPCXXXX и доволен."Все работает". Документация внятная. Какие тенденции?2012-12-22
Звероящер (25.10.2013 10:36, просмотров: 18880) MBedder
Ну что, начнём пятничный срач! В общем ситуация такая: столкнулись два барана программиста железяк. Пишут оба на Сях. Да! Забыл сказать, что один программер писал сначала на асме, а потом перешёл на более продвинутый язык. Другой же писал под писюки, а потом спустился на микраши. И спор возник вот в чём: первый программер, назовём его "Железкин" пишет один хидер, где прописывает всю используемую периферию и всякие унутрение регистры и прочие константы. Ну как-то так.
#ifndef _MCU_CFG_H
#define _MCU_CFG_H
#include "iom168.h"
#include "inavr.h"
#include "avr_macros.h"
#include "types.h"
/**************************************************************/
//    SYSTEM CLOCK CONFIGURATION
/**************************************************************/
#define OSC_FREQ 20000000L   // 20MHz (external oscillator)
// Fuse CKDIV MUST be 1

#define OSC_DIV_1     (0<<CLKPS3)|(0<<CLKPS2)|(0<<CLKPS1)|(0<<CLKPS0)
#define OSC_DIV_2     (0<<CLKPS3)|(0<<CLKPS2)|(0<<CLKPS1)|(1<<CLKPS0)
#define OSC_DIV_4     (0<<CLKPS3)|(0<<CLKPS2)|(1<<CLKPS1)|(0<<CLKPS0)
#define OSC_DIV_8     (0<<CLKPS3)|(0<<CLKPS2)|(1<<CLKPS1)|(1<<CLKPS0)
#define OSC_DIV_16    (0<<CLKPS3)|(1<<CLKPS2)|(0<<CLKPS1)|(0<<CLKPS0)
#define OSC_DIV_32    (0<<CLKPS3)|(1<<CLKPS2)|(0<<CLKPS1)|(1<<CLKPS0)
#define OSC_DIV_64    (0<<CLKPS3)|(1<<CLKPS2)|(1<<CLKPS1)|(0<<CLKPS0)
#define OSC_DIV_128   (0<<CLKPS3)|(1<<CLKPS2)|(1<<CLKPS1)|(1<<CLKPS0)
#define OSC_DIV_256   (1<<CLKPS3)|(0<<CLKPS2)|(0<<CLKPS1)|(0<<CLKPS0)

#define CLKPR_CFG OSC_DIV_2     // Prescaler = 2

#define SYS_CLK       OSC_FREQ / 2
/**************************************************************/
//    PINS DEFINITIONS
/**************************************************************/
// Keyboard driver
#define KBRD_DRV	        1
#define KBRD_DRV_PORT		PORTB
#define KBRD_DRV_DIR		DDRB
#define KBRD_DRV_PIN		PINB

/**************************************************************/
//    PORTS CONFIGURATION
/**************************************************************/
#define DDRB_CFG  (1<<KBRD_DRV) 
#define PORTB_CFG (1<<KBRD_DRV)
/**************************************************************/
//    USART CONFIGURATION
/**************************************************************/
#define USART_BAUD	1200
#define DOUBLE_SPEED
#define UCSR0B_CFG (1<<RXCIE0)| /*       Enable Receiver interrupt */ \
                   (0<<UDRIE0)| /*       Disable Data Register Empty interrupt */ \
                   (1<<RXEN0)|  /*       Enable Receiver */ \
                   (1<<TXEN0)   /*       Enable Transmitter */

#define UCSR0C_CFG (1<<UCSZ01)|(1<<UCSZ00) /* Character Size = 8 bit
                                              Asynchronous USART, 
         Parity Mode disabled, One stop-bit, Character Size = 8 bit  */

#ifdef	DOUBLE_SPEED
#define UCSR0A_CFG  (1<<U2X0) // Double the USART Transmission Speed enable
#define BAUD(x)	((SYS_CLK/8)/x - 1)
#else
#define UCSR0A_CFG  (0<<U2X0) // Double the USART Transmission Speed disable
#define BAUD(x)	((SYS_CLK/16)/x - 1)
#endif

#endif
Потом шли файлы с периферией на уровне послать/принять байт, положить в буфер/забрать из буфера. Прерывания там же описывались. То есть. Есть таймер, вот тебе файло с работой таймера. Есть уарт - вот файл с фунциями. А вот потом, всё что сверху надо, уже крути-верти, пиши что хочу. У второго программера, назовём его "Писюшкин", идеология другая. У него файлы не имеют никаких архитектурных уровней. Есть задача принимать данные от АЦП, так у него и будет файл типа VoltageMeasure.c и в нём будет всё, что связано с измерением напряжения: какие ноги АЦП используются, инициализация и работа с АЦП, таймеры всякие, преобразования, фильтрация и прочее. Об чём был спор. А спор был о том, что удобнее и правильнее, если придётся переезжать на другой камень. Железкин грит, что проще в одном файле всё исправить и готово. А Писюшкин говорит, что один фиг придётся частично переписывать остальной код, потому как архитектура может другая даже в пределах семейства. Зато открываешь о дин файл и видишь, где чем управляется и что используется. В общем я попробовал и так и эдак писать, и однозначно сказать не могу ничего. Может кто из маститых да продвинутых скажет, как оно вернее-то?