2009/06/29 10:27
http://www.eclipse.org/galileo
이클립스의 새로운 버전이 릴리즈되었다. 마무리 임박한 프로젝트에 다른 일들이 끝도없이 밀려 있는 상황에서 이클립스 릴리즈까지 신경쓰는것은 무리. 프로젝트 끝난 후에 서둘러 정리하겠다는 마음가짐으로 간단히 뉴스 페이지 링크만 남긴다.
2009/05/16 21:12
[냉수한잔]
LMI가 TI에게 인수합병되었단다. http://www.ti.com/luminarymicro
뜬금없이 들려온 소식에 무슨일이 벌어졌나 싶어서 몇몇 체널을 통해 알아본 결과, 약간쯤 반겨도 괜찮은 상황인듯 하다.
처음에는 LMI의 장점들이 TI 스타일에 뭍혀버리게 되는것이 아닐까 걱정했다. 기술 주도의 작은 회사라는 이미지가 강점이었는데, TI가 인수해버리면 어떻게 될지 말이다. 현재까지 파악하기로는 TI에서 LMI 파트 운영에 아주 많은 자유도를 부여하고 있다고 한다. 고로 당분간은 기존 라인업도 계속 유지될 것이고, 제품 퀄러티 역시 예전과 비슷하게 나오면서 제품 수급이나 가격측면에서 좀 수월하게 될 것으로 예상된다.
그런데 왜 인수했을까? TI의 라인업은 업계 최강인데... MSP430에서부터 DSP/high-end processor까지 어디하나 빠지는 구석 없이 빈틈없는 라인업을 구축하고 있는데, cortex-M3 제품군을 왜 추가한 것일까?
아직 해결되지 않은 궁금점: 국내 딜러망은 어떻게 되는걸까;;; 분위기로 봐서는 딜러쪽에서도 공식발표난 이후에나 알게된것 같다.
2009/05/03 11:43
[myCortex]
실험환경
- myCortex-LM8962의 SPI 버스에 SD card를 연결. SPI클럭=12.5Mbps
- FatFs 파일시스템 적용. SD card는 FAT32로 포맷.
- 하나의 파일을 열어두고 특정 사이즈의 데이터를 연속해서 계속 write.
- 전체 소요시간 등을 비교한다.
- 단일 파일의 최대 사이즈를 확인한다.
실험결과
- Case 1
- write size = 128 byte
- write cnt = 1024
- 소요시간 = 1.29 sec
- 쓰기속도 = 99 KB/s
- Case 2
- write size = 128 byte
- write cnt = 2048
- 소요시간 = 2.56 sec
- 쓰기속도 = 100 KB/s
- Case 3
- write size = 128 byte
- write cnt = 4096
- 소요시간 = 5.18 sec
- 쓰기속도 = 98 KB/s
- Case 4
- write size = 256 byte
- write cnt = 1024
- 소요시간 = 2.56 sec
- 쓰기속도 = 100 KB/s
- Case 5
- write size = 512 byte
- write cnt = 1024
- 소요시간 = 5.15 sec
- 쓰기속도 = 99 KB/s
- Case 6
- write size = 1024 byte
- write cnt = 1024
- 소요시간 = 6.61 sec
- 쓰기속도 = 154 KB/s
- Case 7
- write size = 2048 byte
- write cnt = 1024
- 소요시간 = 8.81 sec
- 쓰기속도 = 232 KB/s
- Case 8
- write size = 4096 byte
- write cnt = 1024
- 소요시간 = 12.21 sec
- 쓰기속도 = 335 KB/s
- Case 9
- write size = 8192 byte
- write cnt = 1024
- 소요시간 = 19.46 sec
- 쓰기속도 = 420 KB/s
- Case 10
- write size = 16384 byte
- write cnt = 1024
- 소요시간 = 33.50 sec
- 쓰기속도 = 489 KB/s
- Case 11
- write size = 32768 byte
-
write cnt = 1024
-
소요시간 = 81.72 sec
- 쓰기속도 = 400 KB/s
- Case 12
- write size = 16384 byte
- write cnt = 8192
- 소요시간 = 332.14 sec
- 쓰기속도 = 394 KB/s
- Case 13
- write size = 16384 byte
- write cnt = 16384
- 소요시간 = 658.85 sec
- 쓰기속도 = 397 KB/s
- Case 14
- write size = 1638 byte
- write cnt = 16384
- 소요시간 = 658.85 sec
- 쓰기속도 = 397 KB/s
- Case 15
- write size = 16384 byte
- write cnt = 32768
- 소요시간 = 1318.61 sec
- 쓰기속도 = 397 KB/s
- Case 16
- write size = 16384 byte
- write cnt = 65536
- 소요시간 = 2629.59 sec
- 쓰기속도 = 398 KB/s
2009/03/18 11:47
[분류없음]
통신 패킷을 다이어트 해야한다.
1. packed structure의 사용
padding으로 낭비되는 공간을 줄일수 있다. 네트워킹에서는 기본/필수
2. bit-packing
예를들어 24비트로 표현되는 데이터를 4바이트 변수에 담아 전송하고 있었다면 이를 3바이트로 다이어트.
이 과정을 bit 연산을 통해 "수동"으로 해 줘도 되지만, structure의 bit-field를 쓰면 편하다. 이렇게...
그런데 이 bit-field가 gcc 4.2에서는 "척결해야할 대상"으로 되었나보다.
그냥 쓰면 warning이 발생
컴파일러님 한번만 봐주세요. 딱 요기서만 쓸께요. 굽신굽신...
근데 뒤져보니 막강파워 매직워드 "닥쳐"가 있네.
컴파일러님께서는 깨갱하십니다.
1. packed structure의 사용
padding으로 낭비되는 공간을 줄일수 있다. 네트워킹에서는 기본/필수
2. bit-packing
예를들어 24비트로 표현되는 데이터를 4바이트 변수에 담아 전송하고 있었다면 이를 3바이트로 다이어트.
이 과정을 bit 연산을 통해 "수동"으로 해 줘도 되지만, structure의 bit-field를 쓰면 편하다. 이렇게...
typedef struct __attribute__((packed))
{
unsigned long timestamp:24;
unsigned short acc_x;
unsigned short acc_y;
unsigned short acc_z;
unsigned char checksum;
} MyStruct;
그런데 이 bit-field가 gcc 4.2에서는 "척결해야할 대상"으로 되었나보다.
그냥 쓰면 warning이 발생
main.c:37: warning: type of bit-field 'timestamp' is a GCC extension
컴파일러님 한번만 봐주세요. 딱 요기서만 쓸께요. 굽신굽신...
근데 뒤져보니 막강파워 매직워드 "닥쳐"가 있네.
typedef struct __attribute__((packed))
{
__extension__ unsigned long timestamp:24;
unsigned short acc_x;
unsigned short acc_y;
unsigned short acc_z;
unsigned char checksum;
} MyStruct;
컴파일러님께서는 깨갱하십니다.
2009/02/15 18:53
[MISC.]
실험실에 있는지도 몰랐었던 16bit DAQ를 발견한 기념. 실험에 사용하는 전원의 노이즈 분석 특집.
실험에 사용된 장비들
실험 개요
33220A의 DC output에서 나오는 DC 전원과 REF5030A로 만든 전원의 노이즈 정도를 비교해본다.
두 전원 모두 오실로스코프의 해상도 범위를 넘어서는 깨끗한 전원을 보여주고 있기 때문에 이 실험의 목적은 "전원의 노이즈를 본다" 보다는 "전원의 노이즈를 볼 정도로 정밀한 ADC를 수행한다"에 가깝겠다.
U2352A는 250kSa/s의 16bit ADC를 가지고 있지만 16bit 정도 되면 온갓 노이즈 소스에 무방비로 노출되는 수준이기 때문에 신호원을 단순히 ADC했을 경우에는 아주 노이지한 결과를 볼 수 있다.
위 그래프를 보면 1.5V 기준 대략 15mV p2p로 노이즈가 끼어 있다. sampling frequency를 바꿔가며 실험한 이유는 oversampling을 하기 위해서이다. 각각 8배, 64배 oversampling한 결과는 아래에서 볼 수 있다.
당연한 이야기이겠지만 oversampling한 만큼 SNR이 감소하는 것을 볼 수 있다.
다음은 REF5030A로 만든 3.0V 전원에 대한 실험.
실험방법은 동일하다. 그런데 oversampling한 결과를 보면 아주 큰 노이즈가 하나 보인다. 뭘까 싶어 FFT를 해 봤더니...
120Hz 노이즈다. REF5030A의 공급전원을 저렴한 power supply에서 받아왔더니 AC 노이즈가 끼여든것으로 추정. 그래서 베터리 전원으로 바꿔서 동일한 실험을 다시 해 봤다.
실험의 목적아닌 목적인 DAQ 사용법 배우기는 성공이고...
결과를 해석해 보면
그리고 low-noise 실험할 때에는 power supply를 쓰지 말자.
실험에 사용된 장비들
- Agilent 33220A Function Generator
- Agilent U2352A USB DAQ device
- Agilent 34401A DMM
- REF5030A voltage reference
실험 개요
33220A의 DC output에서 나오는 DC 전원과 REF5030A로 만든 전원의 노이즈 정도를 비교해본다.
두 전원 모두 오실로스코프의 해상도 범위를 넘어서는 깨끗한 전원을 보여주고 있기 때문에 이 실험의 목적은 "전원의 노이즈를 본다" 보다는 "전원의 노이즈를 볼 정도로 정밀한 ADC를 수행한다"에 가깝겠다.
U2352A는 250kSa/s의 16bit ADC를 가지고 있지만 16bit 정도 되면 온갓 노이즈 소스에 무방비로 노출되는 수준이기 때문에 신호원을 단순히 ADC했을 경우에는 아주 노이지한 결과를 볼 수 있다.
위 그래프를 보면 1.5V 기준 대략 15mV p2p로 노이즈가 끼어 있다. sampling frequency를 바꿔가며 실험한 이유는 oversampling을 하기 위해서이다. 각각 8배, 64배 oversampling한 결과는 아래에서 볼 수 있다.
당연한 이야기이겠지만 oversampling한 만큼 SNR이 감소하는 것을 볼 수 있다.
다음은 REF5030A로 만든 3.0V 전원에 대한 실험.
REF5030A 출력전원 oversampling 결과. 1) 1kHz raw signal. 2) 8kHz oversampling(x8). 3) 64kHz oversampling(x64)
120Hz 노이즈다. REF5030A의 공급전원을 저렴한 power supply에서 받아왔더니 AC 노이즈가 끼여든것으로 추정. 그래서 베터리 전원으로 바꿔서 동일한 실험을 다시 해 봤다.
실험의 목적아닌 목적인 DAQ 사용법 배우기는 성공이고...
결과를 해석해 보면
- 33220A function generator의 DC output : 1.5V 출력에서 700uV p2p의 노이즈.
- REF5030A의 출력전원: 3.0V 출력에서 2.2mV p2p의 노이즈.
그리고 low-noise 실험할 때에는 power supply를 쓰지 말자.
2008/10/18 18:10
[myCortex]
마이크로프로세서에서의 실수 연산에 대해 잠깐 살펴보자.
꼭 Cortex-M3에만 적용되는 것이 아니라 모든 마이크로프로세서에 적용 될 내용이다.
정수 연산은 간단하다. CPU에서 아주 빠르게 처리할 수 있다. 그렇지만 실수 연산은 그렇게 간단하지가 않다. 그래서 요즘 PC의 CPU에는 별도의 실수 연산기 하드웨어가 포함되어있다. 참고로 386 시절까지만 해도 CPU에 이 실수 연산기가 없었기 때문에 별도의 math coprocessor를 사서 메인보드에 끼워 써야 했었다. 그런데 마이크로프로세서에는 요즘에도 실수 연산기가 안들어있는 경우가 대부분이다. 마이크로프로세서가 아니라 꽤나 성능좋은 ARM9 CPU에도 없는 경우가 많다. 실수 연산기 하드웨어는 비싸고, 웨이퍼 면적이나 전력도 많이 잡아먹는 녀석이기 때문이다.
그러면 이처럼 실수 연산기가 없는 CPU에서는 float나 double 같은 데이터 형을 쓸 수 없는것인가? 하면 또 그렇지 않다. 이가 없으면 잇몸으로 씹는다고, 하드웨어가 없으니 소프트웨어적으로 실수 연산을 처리한다. 이 과정은 똑똑한 컴파일러가 알아서 다 해주기 때문에 프로그램 개발자는 자신의 CPU에 실수 연산기가 있는지 없는지 전혀 신경쓰지 않아도 된다.
그런에 이 말은 절반만 맞다고 해야 할 것이다. 하드웨어적으로 실수 연산을 해 주는 경우와 이를 소프트웨적으로 처리하는 경우는 분명 차이가 있다. 엄청난 속도 차이 말이다. 당연히 하드웨어적인 실수 연산기를 사용하는 경우가 훨씬 더 빠르다.
예전에 실수와 정수 연산 속도를 비교해 보는 간단한 실험을 한 적이 있었는데, 다음 링크를 잠깐 살펴보자.
휴대용 게임기 NDS는 실수 연산기가 없는 ARM9 코어를 사용하고 있다. 메인 클럭은 67MHz. 실험1과 실험3을 비교해 보면 덧셈에 있어 실수 연산이 정수 연산에 비해 60배 가량 느리다는 것을 알 수 있다.
더불어 정수 덧셈은 1클럭, 정수 곱셈은 4클럭 정도를 사용하는 것을 알 수 있다. 그러니 실수 덧셈이나 곱셈은 대략 60클럭정도를 사용하는 샘이다.
myCortex 시리즈에서 사용하고 있는 Luminary micro의 Stellaris 칩셋에도 실수 연산기가 들어있지 않다. Stellaris 칩셋은 Cortex-M3 아키텍쳐를 이용하고 있고, 이는 ARM9과 비슷한 아키텍쳐이다. 따라서 각 연산에 소요되는 시간은 비슷하다고 생각할 수 있으니 저 실험 결과가 거의 비슷하게 적용된다고 볼 수 있을 것이다.
만약 아주 빠르게 동작하는 시스템을 만들고 있다면 어떤 코드가 얼마나 많은 클럭을 잡아먹는지 머리속에서 대충이나마 그림을 그려가면서 디자인 해야 한다. 예를 들어 메인 클럭이 50MHz일때 10KHz의 컨트롤 루프를 가지는 PID 모터 제어 시스템을 만든다면 1 루프는 겨우 5000 클럭밖에 안된다. 정수 덧셈만 한다면 5000번, 실수 곱셈을 한다면 100번도 하지 못하는 시간이다. 이런 시스템에서 아무 생각없이 실수 연산을 썼다가는 머리가 하얗게 새는 경험을 할 수 있다. 그래도 Stellaris는 50MHz나 되기라도 하지, AVR이나 PIC으로는 꿈도 못꿀 일이다.
마이크로프로세서에서 실수 연산을 사용할 때 또한가지 염두에 둬야 하는 것이 있다. 바로 실수 표현. PC에서처럼 printf()함수가 잘 되어 있는 경우가 거의 없기 때문이다. printf()에서 %f를 지원하지 않는 것은 이것 자체가 실수 연산이 되기 때문이다. 속도 때문에 도저히 쓸 수 없는 샘.
이러저러한 이유로 마이크로프로세서에서는 실수 연산을 잘 하지 않는다. 정수로 치환해서 연산하는 방식을 많이 쓰며 많이 쓰이는 방법이 고정 소숫점(Fixed point) 연산이다. 연산 할 때에도, 그 값을 UART로 출력할 때에도 많이 사용한다.
myAccel-3 모듈 같은 경우에는 25MHz 클럭으로 1KHz의 내부 컨트롤 루프를 돌리며 매 루프마다 IIR 필터 3개를 돌린다. 실수 연산을 사용한다면 도저히 구현 불가능한 연산이지만, fixed point 연산을 통해 아주 여유롭게 돌아가는 시스템을 만들 수 있었다.
2008/10/16 14:55
[myCortex]
Luminary Micro에서도 강조하고 있고, 칩셋 data sheet에도 몇번에 걸쳐 나오는 내용이기는 하지만, 한번 더 강조해도 빠질것 아닌 내용이기에 한번 정리해보도록 하자.
Stellaris 칩에 있는 다섯개의 JTAG 관련 신호와 multiplexing 되어있는 GPIO를 사용할 때에는 주의해야 한다.
다섯개의 JTAG 신호는 TRST, TCK, TMS, TDI, TDO를 말하며, PC0~PC3, PB7 핀을 사용하고 있다. 이들 핀을 사용할 때에는 lock-up에 빠졌을 때 복구할 수 있는 안전장치 혹은 리셋 시점으로부터 시간 딜레이를 필요로 한다. 전원 리셋이후 Cortex-M3 코어는 플래쉬 메모리에 저장된 프로그램을 읽어 실행한다. 그와 동시에 JTAG 관련 초기화 작업이 일어난다. 만일 플래쉬 메모리에 저장된 프로그램의 처음 앞부분에서 이들 다섯 핀의 설정을 바꾸는 작업을 하게 된다면 JTAG이 초기화 되지 못하는 상황에 빠지게 된다. 이를 JTAG lock-up이라 부르고 있다.
특히 PB7은 온전한 8비트 버스 형태로 디자인 하기 위해 사용하는 경우가 종종 있는것 같다.
간단하게 생각하면 하나의 핀을 JTAG목적으로도 쓰고 사용자가 쓰고싶은 다른 목적으로도 쓸려고 할 때 쫑나는 상황에서 사용자가 프로그래밍 해 놓은 코드 때문에 JTAG 초기화가 안되는 문제이다. 궁극적인 내장 플래쉬 메모리 퓨징 수단인 JTAG이 사용불가능하게 되므로 더이상 프로그램을 퓨징할 수 없는, 즉 프로세서 칩을 버려야 하는 상황이 되어 버린다.
이를 방지하기 위해서는 PC0~PC3이나 PB7을 가급적 사용하지 않는 것이 가장 안전하다. 물론 이 경우에도 Port B와 Port C의 레지스터들을 직접 write하다가 잘못해서 해당 핀의 direction 같은 설정값들을 건드려버리면 문제는 똑같이 발생한다. 그러니 이 문제를 피하고 싶다면 해당 핀을 사용하지 말것과 레지스터에 직접 접근하는 대신 DriverLib 함수들을 사용하는 것이 같이 이루어 져야 한다.
하지만 한두개도 아니고 무려 다섯개나 되는 IO를 포기하는 것은 문제가 있다. IO가 모자란 경우와 같이 해당 핀들을 꼭 사용해야 하는 경우라면 다음 내용들을 지키도록 하자.
만약 자신의 보드가 이미 lock-up 되었다면 어떻게 해야 하는가?
자세한 unlock 방법은 myCortex FAQ 참조.
Stellaris 칩에 있는 다섯개의 JTAG 관련 신호와 multiplexing 되어있는 GPIO를 사용할 때에는 주의해야 한다.
다섯개의 JTAG 신호는 TRST, TCK, TMS, TDI, TDO를 말하며, PC0~PC3, PB7 핀을 사용하고 있다. 이들 핀을 사용할 때에는 lock-up에 빠졌을 때 복구할 수 있는 안전장치 혹은 리셋 시점으로부터 시간 딜레이를 필요로 한다. 전원 리셋이후 Cortex-M3 코어는 플래쉬 메모리에 저장된 프로그램을 읽어 실행한다. 그와 동시에 JTAG 관련 초기화 작업이 일어난다. 만일 플래쉬 메모리에 저장된 프로그램의 처음 앞부분에서 이들 다섯 핀의 설정을 바꾸는 작업을 하게 된다면 JTAG이 초기화 되지 못하는 상황에 빠지게 된다. 이를 JTAG lock-up이라 부르고 있다.
특히 PB7은 온전한 8비트 버스 형태로 디자인 하기 위해 사용하는 경우가 종종 있는것 같다.
간단하게 생각하면 하나의 핀을 JTAG목적으로도 쓰고 사용자가 쓰고싶은 다른 목적으로도 쓸려고 할 때 쫑나는 상황에서 사용자가 프로그래밍 해 놓은 코드 때문에 JTAG 초기화가 안되는 문제이다. 궁극적인 내장 플래쉬 메모리 퓨징 수단인 JTAG이 사용불가능하게 되므로 더이상 프로그램을 퓨징할 수 없는, 즉 프로세서 칩을 버려야 하는 상황이 되어 버린다.
이를 방지하기 위해서는 PC0~PC3이나 PB7을 가급적 사용하지 않는 것이 가장 안전하다. 물론 이 경우에도 Port B와 Port C의 레지스터들을 직접 write하다가 잘못해서 해당 핀의 direction 같은 설정값들을 건드려버리면 문제는 똑같이 발생한다. 그러니 이 문제를 피하고 싶다면 해당 핀을 사용하지 말것과 레지스터에 직접 접근하는 대신 DriverLib 함수들을 사용하는 것이 같이 이루어 져야 한다.
하지만 한두개도 아니고 무려 다섯개나 되는 IO를 포기하는 것은 문제가 있다. IO가 모자란 경우와 같이 해당 핀들을 꼭 사용해야 하는 경우라면 다음 내용들을 지키도록 하자.
- H/W적으로 pull-down 시키지 않는다. JTAG이동작하기 위해서는 해당 핀들이 pull-up 되어 있어야 할 필요가 있다. 실제로 myCortex 보드들에는 내장 pull-up resistor 외에도 외부에 별도의 저항을 달아둬서 안정성을 좀 더 높이고 있다. 만일 직접 PCB를 떠서 사용하는 경우에는 외부 풀다운 저항이 없어야 할 것이다.
- 리셋 후 JTAG이 초기화 될 때 까지는 해당 핀들의 설정을 건드리지 않는다. 리셋 후 약간의 딜레이가 있고 그동안 JTAG이 정상적으로 초기화 된다면 그 후에는 JTAG이 우선권을 잡으면서 플래쉬에 퓨징된 프로그램(다섯 핀들을 다른 용도로 사용하기 위해 설정을 바꾸는 코드가 들어있는)이 실행되는 것을 멈출 수 있다. 하지만 시간이 얼마나 필요한지는 미지수.
- 혹시 모를 lock-up 상황에 대비해 탈출 코드를 넣어둔다. 예를 들어 마치 부트로더에서 그러는 것 처럼 부팅 시 어떤 핀의 상태를 확인해서 일반 동작모드로 갈 것인지, JTAG 대기 모드로 갈 것인지 선택하는 것 같은 탈출 코드가 있으면 안심할 수 있다.
만약 자신의 보드가 이미 lock-up 되었다면 어떻게 해야 하는가?
- Fury class라면 LM Flash Programmer의 unlock utility를 이용해서 lock-up을 풀 수 있다.
- Sandstorm class라면 revision C인 경우에 한해서 같은 방법으로 풀 수 있다.
자세한 unlock 방법은 myCortex FAQ 참조.
2008/10/10 07:47
[myCortex]
CodeSourcery의 메일링 리스트에 가입해 놨었나 보다. 까먹고 있었는데, 이번에 2008 가을 버젼이 릴리즈 되었다고 메일이 날아왔다.
LM3S 관련해서는 GCC 버젼 업글에 따른 최적화 개선 정도가 관심있게 볼 피쳐인듯하고, 어쨌든 새 버젼이 나왔으니 얼른 깔아서 써 보고 myCortex 예제들에도 적용해야 하는데... 뒤져보니 eclipse도 ganymede SR1 릴리즈 되었네 -_-
CodeSourcery is pleased to announce the availability of the 2008q1
Sourcery G++ Lite Edition release for ARM processors. This is
available for download from:
http://www.codesourcery.com/gnu_toolchains/arm
New features in this release include:
* GCC has been upgraded from GCC 4.2.3 to GCC 4.3.2. This upgrade
provides improved optimization, as well as a number of new features and
quality improvements. Other components, including GDB, Binutils, and
GLIBC have also been upgraded.
* Improved optimization for Cortex-A8 and other ARM CPUs.
* Improved support for NEON and, in particular, auto-vectorization using
NEON.
* Half-precision (16-bit) floating-point support for Cortex-A9 CPUs.
Enjoy!
LM3S 관련해서는 GCC 버젼 업글에 따른 최적화 개선 정도가 관심있게 볼 피쳐인듯하고, 어쨌든 새 버젼이 나왔으니 얼른 깔아서 써 보고 myCortex 예제들에도 적용해야 하는데... 뒤져보니 eclipse도 ganymede SR1 릴리즈 되었네 -_-
2008/10/05 15:21
[냉수한잔]
myCortex-LM8962 제품을 위한 메일링 리스트입니다.
이 메일링 리스트에 가입하시면 예제, 사용자 설명서 및 기타 자료들이 업데이트 되었을 때 관련 안내 메일을 받으실 수 있습니다.
아래 가입폼에 이름과 메일을 수신 할 이메일 주소를 입력하시고 GO 버튼을 클릭하면 가입 신청이 접수되고, 가입 확인 요청 메일을 수신하게 됩니다. 이 가입 확인 요청 메일에 있는 링크를 클릭해서 가입을 확인해 주시면 최종적으로 메일링 리스트에 가입되어 정보 메일을 수신할 수 있습니다.
메일링 리스트에서 탈퇴하려면 아래 폼을 이용하거나 수신한 정보 메일에 포함되어 있는 탈퇴 링크를 클릭하시면 됩니다.
이 메일링 리스트에 가입하시면 예제, 사용자 설명서 및 기타 자료들이 업데이트 되었을 때 관련 안내 메일을 받으실 수 있습니다.
아래 가입폼에 이름과 메일을 수신 할 이메일 주소를 입력하시고 GO 버튼을 클릭하면 가입 신청이 접수되고, 가입 확인 요청 메일을 수신하게 됩니다. 이 가입 확인 요청 메일에 있는 링크를 클릭해서 가입을 확인해 주시면 최종적으로 메일링 리스트에 가입되어 정보 메일을 수신할 수 있습니다.
메일링 리스트에서 탈퇴하려면 아래 폼을 이용하거나 수신한 정보 메일에 포함되어 있는 탈퇴 링크를 클릭하시면 됩니다.
2008/09/25 09:31
[냉수한잔]
요즘 하루일과중 상당시간을 질문에 대한 답변에 할애하는 중이다. 질문과 답변이 쌓이는건 좋은데, 지금 질문게시판은 검색이 안된다. 서버 호스팅해서 제로보드같은걸 깔아서 쓸까? 귀찮은데 카페를 하나 만들까? 이런 목적에는 위키가 딱인데... 고민하다가 결국 스프링노트에 FAQ 페이지를 만들기로 결정하고 작성중에 있다.
시작은 나 혼자 하는거지만 앞으로 여러사람이 함께 작업하게 될 지도 모르고, 한 페이지에 몰아넣어놨으니 검색도 편할 것이고, 관심있게 지켜보고 싶은 사람은 RSS 피드도 받아볼 수 있으니 그리 나쁜 선택은 아닐것 같아서 내린 결정이다.
어제부터 만들기 시작한 거라 아직은 내용이 빈약하지만, 계속 추가해 나갈 계획이다.
시작은 나 혼자 하는거지만 앞으로 여러사람이 함께 작업하게 될 지도 모르고, 한 페이지에 몰아넣어놨으니 검색도 편할 것이고, 관심있게 지켜보고 싶은 사람은 RSS 피드도 받아볼 수 있으니 그리 나쁜 선택은 아닐것 같아서 내린 결정이다.
어제부터 만들기 시작한 거라 아직은 내용이 빈약하지만, 계속 추가해 나갈 계획이다.



이올린에 북마크하기
이올린에 추천하기