구차니의 잡동사니 모음

표로는 감이 안오는데

[링크 : http://www.atmel.com/images/doc2467.pdf]

파형으로 보니 조금 감이 오는 기분?

[링크 : http://www.robotroom.com/Asynchronous-Serial-Communication-2.html]

[링크 : http://web.engr.oregonstate.edu/~traylor/ece473/lectures/uart.pdf]

심심해서 계산해보니...

56kbps / 16M 에서

8바이트 연속으로 보내면 0.5 비트 가 부족해서 최악의 경우 인식을 못할 수도 있겠으나

아마도 UART로 사용시 start bit를 trigger 삼아 그 이후로

클럭을 맞추는 것으로 추측되니 웬만해서는 문제가 안 될지도..

한번 시도는 해봐야겠다.

g++ -Wall -fexceptions -H  -g     -c main.cpp -o obj/Debug/main.o

! /usr/local/include/boost/xpressive/xpressive.hpp.gch

main.cpp

. /usr/include/c++/4.4/iostream

.. /usr/include/c++/4.4/x86_64-linux-gnu/bits/c++config.h

.. /usr/include/c++/4.4/ostream

.. /usr/include/c++/4.4/istream

main.cpp

The ! means that the compiler was able to use the precompiled header. An x means it was not able to use it. Using the appropriate compiler flags is crucial. I took off the -H and ran some speed tests. The precompiled header had an improvement from 14 seconds to 11 seconds. Not bad but not great.

Note: Here's the link to the example: http://www.boost.org/doc/libs/1_43_0/doc/html/xpressive/user_s_guide.html#boost_xpressive.user_s_guide.examples I couldn't get it to work in the post.

[링크 : http://stackoverflow.com/questions/58841/precompiled-headers-with-gcc]

Caution: There are a few known situations where GCC will crash when trying to use a precompiled header. If you have trouble with a precompiled header, you should remove the precompiled header and compile without it.

To create a precompiled header file, simply compile it as you would any other file, if necessary using the -x option to make the driver treat it as a C or C++ header file.

Each of the following options must be the same when building and using the precompiled header:

          -fexceptions -funit-at-a-time

[링크 : https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Precompiled-Headers.html]

아래는 cpp 의 경우,

g++ -x c++-header stdafx.h -o stdafx.h.gch

아래는 c 의 경우,

gcc -x c-header stdafx.h -o stdafx.h.gch

[링크 : https://kldp.org/node/22714]

Precompiled headers are supported in GCC (3.4 and newer).

[링크 : http://softwareji.tistory.com/65]

일단은 yocto 프로젝트의 코어인 poky를 받고(빌드 환경 구성 + 커널 등등?)

하드웨어 의존적인 metadata layer를 다운로드 받는다(meta-raspberrypi)

1.     Clone the Yocto Project Git repo

2.     Get the meta-raspberrypi layer

3.     Setup the build environment

4.     Configure the build

5.     Next up, we need to add the meta-rasperrypi layer we cloned earlier to the file conf/bblayers.conf.

6.     Build a minimal distribution

[링크 : http://ric96.blogspot.in/2014/09/yocto-for-raspberry-pi-build-guide.html]

[링크 : http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/about/]

Poky is a reference system of the Yocto Project - a collection of Yocto Project tools and metadata that serves as a set of working examples. To use the Yocto Project tools, you can download Poky and use it to bootstrap your own distribution.

Poky is the platform-independent, cross-compiling integration layer that utilizes OpenEmbedded Core. It provides the mechanism to build and combine thousands of distributed open source projects together to form a fully customizable, complete, coherent Linux software stack.

[링크 : https://www.yoctoproject.org/tools-resources/projects/poky]

[링크 : http://git.yoctoproject.org/]

[링크 : http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html]

도움말 만드는 툴

출력포맷으로

html / chm / pdf / word를 지원한다.

[링크 : http://www.helpndoc.com/]

개인적인 사용은 무료로 가능(물론 배너가 들어감)

그나저나 유료버전은 은근 비싸네..

[링크 : http://www.helpndoc.com/store]

CPU 패밀리(?)는 EJ

아키텍쳐는 TE

ARM926EJ-S

Architecture ARMv5TE

The ARM926EJ-S processor implements the ARMv5TEJ instruction set 

[링크 : http://www.arm.com/products/processors/classic/arm9/arm926.php]

[링크 : https://en.wikipedia.org/wiki/ARM9]

근데 ARM 홈페이지에서도 페이지 별로 ARMv5TE와 ARMv5TEJ 를 섞어 쓰는건 함정.. ㄷㄷㄷ

TEJ라는 녀석도 구글에서 검색은 되는데 레퍼런스로 쓸만한건 안보이는 듯..

Integrated Modem + Applications

OMAP710 ‐ ARM925 + GSM/GPRS

OMAP730 ‐ ARM926TEJ + GSM/GPRS

OMAP733 ‐ ARM926TEJ + GSM/GPRS

OMAP750 ‐ ARM926TEJ + GSM/GPRS

OMAP850 ‐ ARM926TEJ + EDGE

OMAPV1030 ‐ ARM926TEJ + GSM/GPRS/EDGE

OMAPV1035 ‐ ARM926EJ + GSM/GPRS/EDGE

[링크 : http://www.wdic.org/w/WDIC/OMAP]

메이트라고 해야하나.. 마테라고 해야하나?

일종의 데스크탑 환경이라 페도라에서도 우분투에서도 패키지 설치로 변경이 가능하다고 한다.

[링크 : http://sergeswin.com/1062]

어? 라즈베리 파이도 지원 ㅋㅋ 호감도 상승중

Ubuntu MATE 15.04 is also available for the Raspberry Pi 2.

[링크 : https://ubuntu-mate.org/raspberry-pi/]

[링크 : https://ubuntu-mate.org/]

MMIO 반대말이 안떠올라서 저장 ㅋ

Memory-mapped I/O (not to be confused with memory-mapped file I/O) uses the same address bus to address both memory and I/O devices – the memory and registers of the I/O devices are mapped to (associated with) address values. So when an address is accessed by the CPU, it may refer to a portion of physical RAM, but it can also refer to memory of the I/O device. Thus, the CPU instructions used to access the memory can also be used for accessing devices. Each I/O device monitors the CPU's address bus and responds to any CPU access of an address assigned to that device, connecting the data bus to the desired device's hardware register. To accommodate the I/O devices, areas of the addresses used by the CPU must be reserved for I/O and must not be available for normal physical memory. The reservation might be temporary, such as with the Commodore 64 that does bank switching between its I/O devices and regular memory, or permanent.

Port-mapped I/O often uses a special class of CPU instructions designed specifically for performing I/O, such as the in and out instructions found on microprocessors based on the x86 and x86-64 architectures. Different forms of these two instructions can copy one, two or four bytes (outb, outw and outl, respectively) between the EAX register or one of that register's subdivisions on the CPU and a specified I/O port which is assigned to an I/O device. I/O devices have a separate address space from general memory, either accomplished by an extra "I/O" pin on the CPU's physical interface, or an entire bus dedicated to I/O. Because the address space for I/O is isolated from that for main memory, this is sometimes referred to as isolated I/O.

[링크 : https://en.wikipedia.org/wiki/Memory-mapped_I/O]

ㄷㄷㄷ 한번 돌려볼까?

Can I use C++ on the AVR?

Basically yes, C++ is supported (assuming your compiler has been configured and compiled to support it, of course). Source files ending in .cc, .cpp or .C will automatically cause the compiler frontend to invoke the C++ compiler. Alternatively, the C++ compiler could be explicitly called by the name avr-c++.

However, there's currently no support for libstdc++, the standard support library needed for a complete C++ implementation. This imposes a number of restrictions on the C++ programs that can be compiled. Among them are:

Obviously, none of the C++ related standard functions, classes, and template classes are available.

The operators new and delete are not implemented, attempting to use them will cause the linker to complain about undefined external references. (This could perhaps be fixed.)

Some of the supplied include files are not C++ safe, i. e. they need to be wrapped into

extern"C" { . . . } 

(This could certainly be fixed, too.)

Exceptions are not supported. Since exceptions are enabled by default in the C++ frontend, they explicitly need to be turned off using -fno-exceptions in the compiler options. Failing this, the linker will complain about an undefined external reference to __gxx_personality_sj0.

Constructors and destructors are supported though, including global ones.

When programming C++ in space- and runtime-sensitive environments like microcontrollers, extra care should be taken to avoid unwanted side effects of the C++ calling conventions like implied copy constructors that could be called upon function invocation etc. These things could easily add up into a considerable amount of time and program memory wasted. Thus, casual inspection of the generated assembler code (using the -S compiler option) seems to be warranted.

[링크 : http://www.atmel.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_cplusplus.html]

AVR용 STL ㄷㄷㄷ

[링크 : http://andybrown.me.uk/wk/2011/01/15/the-standard-template-library-stl-for-avr-with-c-streams/]

lighttpd 설정관련해서 epoll이 먼지 조사...

읽어봐도 모르겠다.. -_-

현재 epoll은 realtime signal과 함께 가장 빠른 입출력 처리 방식 중 하나로 알려져 있습니다.

[링크 : http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Network_Programing/AdvancedComm/epoll24]

리얼타임 시그날 (RealTime Sinal)의 대안으로 제안

[링크 : http://www.xevious7.com/52]

epoll은 '한 대의 서버에서 아주많은 동시접속자를 처리하기 위한 수단'이다.

M$ window$ 환경의 개발자라면 이미 iocp 라는 훌륭한 도구가 있고 ?FreeBSD라면 kqueue라는 도구가 있다.

[링크 : http://biscuit.cafe24.com/moniwiki/wiki.php/epoll]

Event Handlers

--------------

The first one is the Event Handler which takes care of notifying the server

that one of the connections is ready to send or receive. As you can see,

every OS has at least the select() call which has some limitations.

============ ========== ===============

OS           Method     Config Value

============ ========== ===============

all          select     select

Unix         poll       poll

Linux 2.4+   rt-signals linux-rtsig

Linux 2.6+   epoll      linux-sysepoll

Solaris      /dev/poll  solaris-devpoll

FreeBSD, ... kqueue     freebsd-kqueue

NetBSD       kqueue     kqueue

============ ========== ===============

For more information on this topic take a look at http://www.kegel.com/c10k.html

[링크 : http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_Performance/16]

[링크 : http://redmine.lighttpd.net/projects/1/wiki/Server_event-handlerDetails]

epoll

This is the recommended edge-triggered poll replacement for the 2.6 Linux kernel.

On 11 July 2001, Davide Libenzi proposed an alternative to realtime signals; his patch provides what he now calls /dev/epoll www.xmailserver.org/linux-patches/nio-improve.html. This is just like the realtime signal readiness notification, but it coalesces redundant events, and has a more efficient scheme for bulk event retrieval.

Epoll was merged into the 2.5 kernel tree as of 2.5.46 after its interface was changed from a special file in /dev to a system call, sys_epoll. A patch for the older version of epoll is available for the 2.4 kernel.

There was a lengthy debate about unifying epoll, aio, and other event sources on the linux-kernel mailing list around Halloween 2002. It may yet happen, but Davide is concentrating on firming up epoll in general first.

[링크 : http://www.kegel.com/c10k.html]

요즘 핸드폰 카메라로 차를 타고 가면서 옆을 찍으면

도로분리대 라던가 이런게 비스듬 하게 나온다.

이게 CMOS 센서의 특징(?)인 롤링셔터 이펙트로 일종의 주사선 스캔 속도의 한계로 인해

위에서 부터 아래로 한줄씩 읽어 오면서 시간 차이가 생겨 이미지가 왜곡되는 현상이다.

그래서 이걸 줄이기 위해서는 센서 전체를 선이 아닌 면 단위로 한번에 스캔을 해야 하는데

이걸 글로벌 셔터라고 하지만, 스캔 속도가 느려지는 듯 하다.

---

*롤링 셔터 : 화면의 좌우, 또는 위아래로 스캔하여 캡쳐하는 방식으로 프레임의 속도를 높일 수 있지만 센서의 주사선 위치마다 노출의 타이밍이 다르기 때문에 왜곡 현상이 발생할 수 있다. [롤링 셔터 이펙트]

*글로벌 셔터 : 전체를 한번에 잡아 캡쳐하는 방식으로 왜곡이 발생하지는 않지만 전 화소 노출 후 모든 화소를 읽어내야 하기 때문에 프레임을 빠르게 할 수 없다.

[링크 : http://www.popco.net/zboard/zboard.php?id=dica_news&no=10796]

[링크 : http://dicahub.com/2015/02/28/소니의-저가형-글로벌-셔터-센서와-포인트-그레이-카메라]