uVision&J-Link를 이용한 디버깅

  1. Options for Target 윈도우에 들어가서 Debug Tab으로 간다

스크린샷 2016-07-25 오후 5.56.07.png

Use : J-Link / J-TRACE Cortex를 선택

  1. 오른쪽에 있는 Setting을 누른다

스크린샷 2016-07-25 오후 5.57.31.png

Port : SWD 로 변경

Max Clock : 50Mhz로 변경 ( 이건 좀 확인해봐야 할듯..)

  1. Flash Download Tab으로 이동한다

스크린샷 2016-07-25 오후 5.59.27.png

위 그림처럼 설정한다

확인 누르고 나온다

  1. 다시 옵션 화면으로 나왔다면, Utilities 탭으로 이동한다

스크린샷 2016-07-25 오후 6.01.19.png

Use External Tool for Flash Programming 선택

Run Independent 체크

Advertisements

concurrently, parallelism, asynchronous

concurrently(동시성), parallelism(병렬화), asynchronous(비동기)

이름부터 어렵다

비슷한것 같으면서도 다르기 때문에 혼란을 야기하는데, 여기에 정리해놓고 리마인드 해야지

다만, 이 내용이 정확한 내용인지는 나도 장담 못함…

concurrently(동시성)

여러 작업이 번갈아 가면서 동시에 실행되는 것을 말한다

동시라고는 하지만 실제로는 Context Switching에 가깝다

따라서 Single core에서도 동시성이 있는 프로그래밍을 하고 수행할 수 있다.

thread 기반 프로그래밍이 동시성 프로그래밍의  좋은 예이다.

single core에서도 다수의 thread를 만들어서 수행할 수 있으며, 사용자가 보기에 동시에 실행되는 것처럼 빠르게 번갈아 가면서 수행된다

concurrently 프로그래밍은 태생적으로 resource에 대한 race condition이 발생 한다.

예를 들어서 전역 변수를 접근하는 concurrently 프로그램을 짠다면 하이젠버그를 만나게 될 것이다.

parallelism (병렬화)

여러 작업이 다수의 core에서 동시에 수행되는 것을 말한다.

병렬화 프로그래밍은 single core에서는 불가능하다. 반드시 다수의 코어가 실제적으로도 동시에 일을 해야 하는 것을 말한다.

이런 의미에서 보면 동시성 프로그래밍을 한 후에, multicore에서 실행하면

“야호~ 나 프로그램을 병렬화 했어” 라고 말할 수 있을까?

OS가 알아서 작업을 각각의 core에 알아서 스케쥴일 해줄테니 말이다.

잘 모르겠지만, 아닌것 같다.

병렬화는 프로그래머가 명시적으로 해당 부분을 강제로 다수의 코어가 나누어서 수행한다는 의미가 강하다.

예를 들어서 1에서 100까지 더해서 합하는 프로그래밍을 한다고 해보자.

이때 병렬화 프로그래밍을 한다는 것은, 1~50까지는 1번 코어가 계산하도록 하고, 51~100까지는 2번 코어가 계산을 하도록 한후에 나중에 합치는 프로그래밍을 할 것이다.

보통 동시성 프로그래밍을 한다고 하면, 위 작업같은 조치를 취하지 않는다.

병렬화 프로그래밍은 대부분이 프로세서가 시간이 오래 걸리는 연산 작업을 다수의 코어가 나눠서 같이 계산을 한다는 의미로 많이 쓰인다.

이런 용도로 병렬화 라이브러리가 OpenMP이다. OpenMP를 쓰는 프로그래밍은 병렬화 프로그래밍이라고 할 수 있다.

병렬화도 잘못 짜게 되면 resource에 대한 race condition을 유발 할 수도 있지만, OpenMP같은 라이브러리만을 이용해서 활용한다면, 그 문제가 거의 발생하지 않는다.

con_and_par.jpg

위 그림은 concurrent 와 parallelism 의 차이를 보여준다

asynchronous (비동기)

비동기 프로그래밍은 하나의 작업의 흐름에서 프로그램의 수행이  블록되지 않고, 계속 실행하게 만드는 기법이다.

프로그램이 블록 되는 이유는 대부분이 I/O 처리때문이다. (HDD, Network, Display, Mouse, …)

예를 들어서 아래와 같은 코드를 보자.

read_storage(buffer, 2000);

위 코드는 저장장치에서 2000바이트를 읽어서 buffer에 저장하라는 코드이다. (pseudo code임)

위 코드는 2000바이트를 읽을 때 까지 해당 코드가 멈추게 된다. 그냥 하릴없이 멈춘다. 저장장치가 2000바이트를 다 줄때까지…

그런데 해당 함수를 호출한 thread만 멈춘다. 다른 thread는 안 멈춘다.

다른 thread에는 영향을 안주고 자신만 멈추니까 비동기 프로그래밍의 매력이 별로 없어보인다.

GUI 프로그래밍을 생각해보자. 위 read_storage 처리 함수와 GUI 의 다양한 처리를 하는 함수들이 같은 thread에서 동작한다고 생각해보자. 그러면 저 함수가 리턴될 때 까지 화면은 멈추게 되고, 응답없음 이란 글자를 보게될 것이다.

그래서 과거에는 GUI 프로그래밍을 할  때 GUI 를 처리하는 thread에서는 저런 block이 발생하는 작업을 안하고 다른 thread에게 시키던지, non-block 함수를 써서 계속 polling으로 I/O 처리가 끝났는지 확인하곤 했다.

figure1.gif

위 그림은 동기,비동기 / 블럭,논블럭 차이에 대한 설명이다.

사실 비동기 프로그래밍은 병렬화, 동시성 프로그래밍 하고는 같은 층위의 개념은 아니다. 병렬화, 동시성 개념은 다수의 작업을 코어에 어떻게 할당하는가에 대한 논의라면, 비동기 프로그래밍은 하나의 작업이 멈출지, 말지에 대한 논의이다. 좀 더 하위 개념에 가까운것 같다.

그럼에도 불구하고  비동기 프로그래밍은 multi-thread 프로그래밍에 좋은 대안이다. 실제로 multi-thread 프로그래밍보다 비동기 프로그래밍이 성능이 좋다. (정말?)

그 예시가 바로 node.js 이다.  참조( http://www.nextree.co.kr/p7292/ )

비동기 프로그래밍의 가장 큰 예시는 callback, EventEmitter 이다.

2018년 6월 스크랩✭

c++ 에서 static library 와 template

c++에서 템플릿의 구현체는 기본적으로 해더파일에 구현해야 한다.
템플릿의 내용을 cpp안에 넣어도 해당 코드를 라이브러리 형태로 다른곳에서 참조하지만 않으면 문제가 없다.
문제는 해당 cpp파일을 라이브러리(.a)로 만든다음에, 다른 프로그램이 링킹하려고 한다면 심볼을 찾을 수 없다는 오류가 발생한다.

예를 들어 아래와 같은 경우다.

//template.h
class NSFinder {
public:
    template <typename T>
    static T getParam(T val);
};

//template.cpp
template <typename T>
T NSFinder::getParam(T val) {
    return val
}

//other program
int main() {
    //에러, 함수를 찾을 수 없다
    int temp = NSFinder::getParam<int>(1);
}

가장 올바른 해결책은 h에 템플릿 코드를 넣는것이다. 하지만 이 방법말고도 가능한 방법이 있다.

1.라이브러리 코드 안에서 컴파일시에 필요한 템플릿 객체 강재로 생성하기.

아래 코드 처럼 템플릿이 존재하는 cpp안에서 필요한 타입의 템플릿 객체를 이용하면, 라이브러리안에 실체가 만들어지기 때문에 링크 에러가 발생하지 않는다. 단점은, 명시적으로 어떤 객체를 사용할지 선언해준 범위에서만 사용가능 하다.

//template.h
class NSFinder {
public:
    NSFinder();
    template <typename T>
    static T getParam(T val);
};

//template.cpp
template <typename T>
T NSFinder::getParam(T val) {
    return val
}

NSFinder::NSFinder() {
    //라이브러리 코드 안에서 한번 사용한다.
    int temp = NSFinder::getParam<int>(1);
}

//other program
int main() {
    //빌드 성공
    int temp = NSFinder::getParam<int>(1);
    //이건 실패한다
    double temp = NSFinder::getParam<double>(1.0);
}

2.템플릿 특수화를 이용해서 만들어준다. 이 방법은 코드가 중복되는 단점과, 명시적으로 어떤 객체를 사용할지 선언해준 범위에서만 사용 가능하다.

//template.h
class NSFinder {
public:
    NSFinder();
    template <typename T>
    static T getParam(T val);
};

//template.cpp
//템플릿 특수화
template <> 
int NSFinder::getParam(int val) {
    return val
}

template <typename T>
T NSFinder::getParam(T val) {
    return val
}

//other program
int main() {
    //빌드 성공
    int temp = NSFinder::getParam<int>(1);
    //이건 실패한다
    double temp = NSFinder::getParam<double>(1.0);
}

여러모로 불편하니, 그냥 해더파일에 템플릿을 구현하는게 정답이다

11월 스크랩

ARM Ubuntu 14.04에 최신 docker 설치기

회사 타켓보드에 개발 용이성을 위해서 ARM Ubuntu14.04에 docker를 올리는 시도를 했다

그냥 간단하게는 아래 명령으로 되는데,

$ sudo apt-get install docker.io

Ubuntu 14.04는 너무 오래되서, docker 버전이 너무 낮아서 시도를 하지 않았다. (실제로 저 명령으로 docker 설치가 잘 되는지 모른다는 이야기다)

처음부터 바로 docker ppa에서 바로 최신 버전을 받아서 설치를 진행했다.

https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/#upgrade-docker-after-using-the-convenience-script

그리고 실행하니까 커널에 필요한 기능이 추가되어 있지 않아서 데몬이 동작하지 않는다.

첫번째 이슈는 cgroup이었다. 커널에 cgroup 자체는 활성화되어 있었지만, blkio같은 서브모듈이 비활성이어서 전부 활성화 처리 해주었다.

두번째는 network nat기능이었다. 이 부분은 너무 옵션이 많이 필요해서 관련 자료를 참고했다.

스크린샷 2017-11-03 오전 10.49.09.png스크린샷 2017-11-03 오전 10.49.17.png스크린샷 2017-11-03 오전 10.49.23.png

위에는 falinux에서 진행한 docker세미나 자료이다.

https://wiki.gentoo.org/wiki/Docker

위는 gentoo에서 제공하는 docker 커널 옵션이다. 나는 잘 안되서 2개를 다 시도 했다. 따라서 위 2개중에 어떤게 맞는지는 알수없다. 나는 그냥 2가지를 다 활성화시켰다.

그래도 네트워크쪽에서 아래와 같은 오류가 발생했다.

failed to create endpoint vigilant_varahamihira on network bridge: failed to add the host (vethadd7f95)  sandbox (veth63708ff) pair interfaces: operation not supported"

해결책은 아래 커널 옵션을 활성화 해준다

device driver -> network device support -> network core driver support -> virtual ethernet pair device

그래도 아래와 같은 오류가 발생했다.

starting container process caused "process_linux.go:368: container init caused \"rootfs_linux.go:57: mounting \\\"mqueue\\\" to rootfs \\\"/var/lib/docker/devicemapper/mnt/e8d53dff710da9a18279cec3db4fb324ecc1874b5f3fa2e4496b94c31938d715/rootfs\\\" at \\\"/dev/mqueue\\\" caused \\\"no such device\\\"\"".

해결책으로 CONFIG_POSIX_MQUEUE 커널 옵션을 활성화 했다

그래도 아래와 같은 오류가 발생했다.

oci runtime error: container_linux.go:265: starting container process caused \"process_linux.go:368: container init caused \\"open /dev/ptmx: no such file or directory\\"\"

해결책으로 아래와 같이 -v 옵션을 추가해서 실행했다.

$ sudo docker run --rm -it -v "/dev:/dev" arm32v7/ros:kinetic-ros-base /bin/bash

2017년 10월 스크랩✭

2017년 6월 2차 스크랩✭

Device Tree Overlay Notes

원문 : http://lxr.free-electrons.com/source/Documentation/devicetree/overlay-notes.txt

디바이스 트리 오버레이 노트

이 문서는 drivers/of/overlay.c 에 구현된 커널 디바이스 트리 오버레이 기능의 구현에 대해 설명합니다. 이 문서는 Documentation/devicetree/dt-object-internal.txt & Documentation/devicetree/dynamic-resolution-notes.txt 와 같이 보면 좋습니다.

오버레이는 어떻게 동작하는가

디바이스 트리 오버레이의 목적은 커널의 라이브 트리를 수정하기 위함입니다. 또한 커널 상태에 영향을 주는 수정을 반영하고 있습니다. 커널은 주로 장치를 다루기 때문에, 활성화된 장치는 새로운 디바이스 노드를 생성해야 합니다. 비활성화 되었거나 제거된 장치는 등록이 취소되어야 합니다.

아래 예제는 베이스 트리에 있는 foo board 입니다.

---- foo.dts ----------------------
    /* FOO platform */
    / {
        compatible = "corp,foo";

        /* shared resources */
        res: res {
        };

        /* On chip peripherals */
        ocp: ocp {
            /* peripherals that are always instantiated */
            peripheral1 { ... };
        }
    };
---- foo.dts ------------------------

bat.dts 오버레이가 아래와 같이 로딩되었습니다.

---- bar.dts -------------------------
/plugin/;   /* allow undefined label references and record them */
/ {
    ....    /* various properties for loader use; i.e. part id etc. */
    fragment@0 {
        target = ;
        __overlay__ {
            /* bar peripheral */
            bar {
                compatible = "corp,bar";
                ... /* various properties and child nodes */
            }
        };
    };
};
---- bar.dts ---------------------------

결과적으로 foo + bar.dts는 아래와 같습니다.

---- foo+bar.dts ----------------------
    /* FOO platform + bar peripheral */
    / {
        compatible = "corp,foo";

        /* shared resources */
        res: res {
        };

        /* On chip peripherals */
        ocp: ocp {
            /* peripherals that are always instantiated */
            peripheral1 { ... };

            /* bar peripheral */
            bar {
                compatible = "corp,bar";
                ... /* various properties and child nodes */
            }
        }
    };
---- foo+bar.dts -------------------------

오버레이의 결과로, 새로운 장치 노드(bar)가 생성되었습니다. 따라서 bar 플랫폼 장치가 등록되고, 일치하는 디바이스 드라이버가 로드되면 예상되로 생성됩니다.

오버레이 Kernel API

API는 사용하기 매우 쉽습니다.

  1. of_overlay_create ()를 호출하여 오버레이를 만들고 적용합니다. 반환 값 이 오버레이를 식별하는 쿠키입니다.

  2. 이전에 오버레이를 제거하고 정리하는 of_overlay_destroy ()를 호출합니다. of_overlay_create ()에 대한 호출을 통해 생성됩니다. 다른것에 의해 겹쳐진 오버레이를 제거하는 것은 허용되지 않습니다.

마지막으로 한 번에 모든 오버레이를 제거해야하는 경우 of_overlay_destroy_all () : 올바른 순서로 모든 단일 항목을 제거합니다.

오버레이 DTS 포맷

DTS 오버레이는 아래와 같은 형식을 가져야 합니다.

{
    /* ignored properties by the overlay */

    fragment@0 {    /* first child node */

        target=;    /* phandle target of the overlay */
    or
        target-path="/path";    /* target path of the overlay */

        __overlay__ {
            property-a; /* add property-a to the target */
            node-a {/* add to an existing, or create a node-a */
                ...
            };
        };
    }
    fragment@1 {    /* second child node */
        ...
    };
    /* more fragments follow */
}

Using the non-phandle based target method allows one to use a base DT which does
not contain a symbols node, i.e. it was not compiled with the -@ option.
The symbols node is only required for the target= method, since it
contains the information required to map from a phandle to a tree location.