2011년 5월 16일 월요일

VxWorks TCP socket ref.

http://www.ee.usyd.edu.au/tutorials/tornado/vxworks/netguide/c-sockets.html

Although the socket interface is compatible with VxWorks, the environment does affect how you use sockets. Specifically, the globally accessible file descriptors available in the task-independent address space of VxWorks require that you take extra precautions when closing a file descriptor.



You must make sure that one task does not close the file descriptor on which another task is pending during an accept( ). Although the accept( ) on the closed file descriptor sometimes returns with an error, the accept( ) can also fail to return at all. Thus, if you need to be able to close a socket connection's file descriptor asynchronously, you may need to set up a semaphore-based locking mechanism that prevents the close while an accept( ) is pending on the file descriptor.



>> TCP  소켓과 파일 디스크립터가 공유된다는 언급.  따라서 주의해서 사용해야 할 것을 말함.
 TCP 소켓과 파일 IO가 RT 연결끊김에 연관관계가 있음을 의미

2011년 5월 13일 금요일

[Labview 8.6] sbRIO TCP/IP 연결끊김 문제




TCP 연결 사용시 cRIO 다운
http://forums.ni.com/t5/LabVIEW/Crio-Ethernet-Port-Crashes-Error-42/td-p/961070
 - 2009.08.10, LV861

1. cRIO9014가 TCP 연결에서 42번 에러를 발생하는 경우에 대한 실험
  1) TCP open과 TCP close를 연속으로 두고 100ms 주기로 실행시킨 후
  2) 케이블을 빼고 5초후 다시 연결하면 42번 에러 발생

2. CAR #141011으로 NI에서 대응중
  - ping.vi를 사용해보라고 하지만 잘 되지 않음

3. (간단 해결책) Timed Loop 안에 TCP 함수를 두지 말 것



TCP 연결 사용시 cRIO 다운(2)
http://forums.ni.com/t5/LabVIEW/cRIO-disconnects-from-Ethernet-network-and-stops-responding-to/m-p/754839
 - 2008.08.06

1. cRIO 9014 프로그램 로직 설명
 FPGA로 데이터를 수집하는 루프와 전송을 TCP 루프(5초 주기 재시도)가 있음
 cRIO는 주기적으로 이더넷 연결을 끊음
 56번 timeout 에러를 보이다가 어떤 경우에 TCP 복구가 되지않음
 랩탑에 직접 연결하여 실험할때는 수분내에 확인되나
 이더넷 스위치를 통해 다른 서버에 연결될때에는 수시간이 소요됨
 TCP 에러가 발생한 시점에도 이더넷 포트의 LED는 연결되었음을 보여줌(오렌지색, 녹색LED)
 CPU나 메모리 문제는 아님


2. RT 플랫폼(Pharlap, VxWorks) 최대 64개의 TCP/IP 소켓 연결만 가능함.
 소켓이 닫힌 이후 60초간 TCP/IP 스택이 대기하는 상황에서 문제 발생됨
 재접속 주기를 60초로 변경하면 어느정도 문제를 해결할 수 있음
 UDP socket-less 통신을 사용하는 것이 가장 나은 해결책

After a lot of pain and talks with NI Platinum support we found that the issue was caused by running out of tcp/ip sockets. The RT platforms, both Pharlap and VxWorks, have a limit of 64 simultaneous tcp/ip sockets. The problem is compounded by the tcp/ip stack holding on to any closed socket for 60 sec after closure.


In our application we had an RT PXI chassis with 14 simultaneous tcp/ip connections. We worked around the issue by limiting reconnect attempts only after a 60 sec delay. This solved the issue in the short term, but for the long term we had to move to UDP socket-less communication to our distributed cRIO targets.


3. 다른 경험적 해결책
 1) Timed Loop 내에 TCP/IP 루프를 두지 말 것
 2) Timed Loop 내에 File io를 두지 말 것
 3) Timed Loop 내에 공유 변수를 두지 말 것(FIFO, 글로벌 변수가 나은 방안)



<<가능한 해결책>
 1. TCP 루프의 재접속 주기를 60초로 변경
    -> 이미 120초로 사용 중임에도 연결끊김 발생
    -> 공유기나 스위치없이 사용시 발생빈도가 많아지고 주기가 짧아짐


 2. TCP 루프중 일부를 UDP로 변경
    -> 운전프로그램 연결을 UDP로 변경하는 안을 검토
    -> 공유기 아래에 있을 경우 포트 포워딩 등을 해주어야 하고, 방화벽 통과 못함
    -> UDP는 송 수신 모두 IP와 Port 에 의해 매번 새로 보내지므로 IP가 외부에서
      접근 불가하면 연결되지 않음
  



2010년 1월 1일 금요일

JSF 코딩룰

자동차 업계의 코딩룰인 MISRA 에 이어 전투기용 항공프로그램을 위한 코딩룰이 존재한다는 사실
아래 링크의 중간쯤에 있는 Coding Standard를 확인해볼 것.

스캇 마이어스의 Effective C++,  More Effective C++이 참고문서로 들어가 있다.



http://www.jsf.mil/downloads/down_documentation.htm

시간날 때 공부해야 겠다.

점점 안정성 있는 코드에 대한 요구사항이 늘고 있고, 자유로운 코딩은 옛말이 되어간다.

2009년 12월 31일 목요일

프로그래머의 생산성

IBM 소프트웨어 개발팀에서 조사한 월간 1인당 작성한 코드 수
 
  • 1     M/M의 경우  439라인
  • 10   M/M의 경우  220라인
  • 100  M/M의 경우  110라인
  • 1000M/M의 경우  55라인
 사람이 많이 투입된 큰프로젝트일 수록 개발자간의 의사소통경로가 많아져서 일이 지연된다는 의미. 이를 해결하기 위해서는 작은 팀 단위로 나누어야 한다.
 임베디드 시스템에 적용할때는 하나의 고성능 CPU에 온갖 프로그램을 전부 올리려 하지 말고, 작은 CPU로 분할된 개별 시스템을 각 소규모 팀에 할당해서 개발하라. 칩은 싸고 인건비는 비싸다.


  KLOC(Kilo Line of Code)로 구분된 프로젝트의 규모에 따라 숙련된 프로그래머(Best programmer)와 비숙련된 프로그래머의 생산성을 비교한 결과. 큰 프로젝트 일수록 수퍼스타들을 잠식해버린다. 끝없이 이어지는 회의와 메모들이 그들의 창조성을 위협한다.

프로그램의 크기(KLOC)
숙련된  프로그래머(월/KLOC)
비숙련된 프로그래머(월/KLOC)
1
1
6
8
2.5
7
64
6.5
11
512
17.5
21
2048
30
32

결론은 똑똑한 개발자들에게 작고 아주 중요한 일을 주라는 것.



(출처: The Art of Designing Embedded Systems 2nd Ed.)

2009년 2월 6일 금요일

컴퓨터 공학자의 미래

Computer Science Education: Where Are the Software Engineers of Tomorrow?

컴퓨터 공학의 미래가 어둡다라는 요지의 글.

배우기 쉬운 언어(JAVA) 사용 및 라이브러리 패키지를 사용, 그래픽 인터페이스에 길들여진 프로그래머들이 늘고 있는 것이 앞으로 문제가 될 것이다. 이러한 문제점을 인식하게 된 몇몇 대학에서는 JAVA를 수업용 언어로 사용하는 것을 제고하고 있다.


제대로 된 프로그래머는 언어에 구애받지 않는다.

ㅁ C언어가 중요한 이유 : C언어는 로우레벨 언어로써 모두가 알아야만 한다. C 언어는 어셈블리와 비슷하며, 하드웨어와 소프트웨어간의 관계를 명확히 이해하는 데 도움을 준다. 구문에 소요되는 자원비용이 명확해서 성능분석하기도 쉽다.

ㅁ C++이 중요한 이유 : C++은 C언어에 현대적인 소프트웨어 공학 개념을 추가했다(클래스와 네임스페이스의 캡슐화, protected 및 private 조작을 통한 데이터 은닉, 가상 method 및 클래스 상속을 통한 확장 등) 그리고 생성자와 파괴자를 사용한 메모리 관리방법을 적용했다.

ㅁ LISP가 중요한 이유 : LISP에서 작성되는 프로그램은 추상적인 문법을 사용하고, internal representation이라고 불리는 이 방법은 대부분의 컴파일러에서 구문해석 및 코드생성을 위해 사용하는 것이다. 따라서 LISP를 이해하는 것은 언어처리에 관련된 소프트웨어들이 어떻게 동작하는 지를 이해할 수 있는 탄탄한 기반이 된다.

ㅁ JAVA가 중요한 이유 : 첫 언어로써의 몇가지 단점에도 불구하고 자바는 컴퓨터 공학 교육에 있어 중요하다. 첫째는 쓰레드를 사용한 병렬처리에 대한 이해를 증진시킬 수 있고, 둘째는 동적으로 변화하는 환경에서 프로그램의 동작이 결정되어야 하고, 프로그램의 상태를 파악할 수 있도록 만들어 져야한다는 것을 알게 해준다.

using Excel

[엑셀 프로그램 열어서 값 넣기]

>>> import win32com.client
>>> xl = win32com.client.Dispatch("Excel.Application")
>>> xl.Visible = True
>>> xl.Workbooks.Add()

>>> exl = xl.ActiveWorkbook.ActiveSheet

>>> exl.Cells(1,1).Value = 'abc'


[엑셀의 레인지 설정]

>>> import win32com.client
>>> xl = win32com.client.Dispatch("Excel.Application")
>>> exl = xl.ActiveWorkbook.ActiveSheet

>>> print exl.Range("B2:D2")
((1.0, 2.0, 3.0),)
>>> print exl.Range("B2:F3")
((1.0, 2.0, 3.0, 4.0, 5.0), (u'a', u'b', u'c', u'd', u'e'))
>>> print exl.Range(exl.cells(2,2), exl.cells(2,5))
((1.0, 2.0, 3.0, 4.0),)


[셀 병합 하기]

>>> print exl.Range(exl.cells(4,2), exl.cells(4,5)).Merge()

wxPython

Best GUI toolkit for Python

http://www.wxpython.org/