2012-01-07 12 views
1

MCB1700 평가 보드 용 프로그램을 개발하고 싶습니다. PC의 클라이언트 소프트웨어가 HDD에서 사진을 읽습니다. 그런 다음 소켓 (이더넷)을 통해 MCB1700 평가 보드로 사진을 전송합니다. MCB1700의 서버는 소켓 연결을 통해 PC에서 사진을 수신하고 LCD에 표시합니다.Keil MCB1700 평가 보드를위한 내 프로그램을 구현하는 가장 좋은 방법은 무엇입니까?

또한 서버가 이러한 작업을 수행해야합니다

  • 는 USB 스틱에 사진을 저장하려면를;
  • USB 스틱에서 그림을 읽고 소켓을 통해 클라이언트에게 보내려면 다음을 수행하십시오.
  • CAN을 통해 정보를 보내고 받으려면
  • COM 로깅.

소켓 연결이 CMSIS 및 RL-ARM 라이브러리의 도움으로 구현 될 수있다.

그러나 이해할 수 있듯이, 두 가지 경우 모두에서 sofrware는 들어오는 TCP 연결을 수신하고 네트워크의 이벤트를 무한 루프로 처리해야합니다. Keil의 모든 사례는 이러한 원칙을 기반으로합니다.

저는 항상 임베디드 프로그래밍이 무한 루프를 사용하는 것은 좋지 않다고 생각했습니다. 은 또한, 나는

  • "(루프에서 하나 이상의 작업을 실행하여) RTOS 없이 실시간으로 프로그램을 만들 확실히 가능하다"

    는 흥미로운 말씀을 읽게 http://www.keil.com/support/man/docs/rlarm/rlarm_ar_artxarm.htm 내가 이해 한대로 루프에서 많은 작업을 실행하는 것은 일반적인 습관입니까?

    while (1) { task1(); task2(); ... taskN(); }

모든 이벤트를 인터럽트로 처리하는 것이 더 좋습니다.

CMSIS 및 RL-ARM 라이브러리의 소켓 연결을 사용하고 인터럽트를 처리하여 모든 소프트웨어를 구성 할 수 있습니까? 내 서버 (MCB1700)는 많은 작업을 수행해야합니다. 내 소프트웨어에서 RTOS RTX를 사용해야합니다. 그렇지 않니? RTX없이 소프트웨어를 구현하는 것이 더 좋습니까?

답변

3

간단한 실시간 시스템은 종종 "큰 루프"아키텍처에서 작동하며 일부 중요한 이벤트는 인터럽트로 처리됩니다. 이는 "나쁜"아키텍처가 아니며 약간 융통성이없고 가늠할 수 없으며 변경 사항은 시스템의 모든 부분 또는 모든 부분에 영향을 미칠 수 있습니다.

RL-TCPnet이 이런 방식으로 작동해야한다는 것은 사실이 아니지만 독립 실행 형으로 실행되도록 설계되었으며 예제는 그런 방식으로 작동하므로 가장 넓은 적용 가능성을 위해 다른 라이브러리에 의존하지 않습니다. 이것들은 단지 예일 뿐이며 RL-TCPnet과 다른 것을 보여주기위한 것입니다. 그러한 의미에서 예제는 현실적이지 않고 요구 사항에 맞게 조정되어야합니다.

모든 응용 프로그램 코드가 인터럽트 처리기에서 실행되고 네트워크 스택이 스레드 컨텍스트에서 무한 루프의 서비스 인 시스템을 개발할 수도 있지만 구조적으로 이는 "빅 루프"아키텍처보다 훨씬 나빠질 수 있습니다. 우선 순위가 높은 인터럽트 처리기로 끝나고 우선 순위가 낮은 인터럽트 핸들러로 인해 우선 순위가 낮은 인터럽트 처리기가 우선 순위가 낮은 인터럽트 처리기의 실시간 응답에 영향을 미칠 수 있기 때문입니다. 만족스럽게 일정 잡기가 어려운 시스템으로 귀결됩니다. 또한 모든 라이브러리 루틴이 인터럽트 핸들러에서 실행하기에 적합하지 않으므로 다소 제한적입니다.

RTOS에서 우선 순위가 낮은 스레드에서 네트워크 스택을 서비스 할 수 있습니다. 이러한 작업을위한 프레임 워크는 Using RL-TCPnet with RTX kernel. 섹션의 설명서에 설명되어 있습니다. 이를 위해서는 RL-RTX 커널 라이브러리를 이해하고 사용해야합니다.하지만 "큰 루프"코드에 대한 예약과 시스템에서 수행해야하는 작업에 대한 설명이 있다면 원하는 것처럼 들릴 것입니다. 다른 RTOS를 사용하도록 선택한 경우 RL-TCPnet은 모든 RTOS와 비슷한 방식으로 작동 할 수 있습니다.

+0

내 작업은 다음과 같습니다. 1) 서버 (MCB1700에서)가 데이터 패키지를 읽습니다. 2) 서버가 명령을 수행하지 않으면 특수 기능이이 패키지를 구문 분석하고 (char 기호 배열과 같이) 어떤 명령을 수행해야하는지 정의합니다. 다른 경우 프로그램은 특정 명령 내에서 패키지를 읽고 그 명령으로 수행 할 작업을 정의합니다. 3) 명령이 완료됩니다. (1)로 돌아 가기. 다른 작업 : CAN의 이벤트, ADC가 인터럽트로 처리 될 수 있습니다 (처리기에 코드 줄이 거의 없음). 그림을 USB 스틱에 저장하고 LCD에 표시하면 패키지를 읽은 직후에 수행됩니다. 태스크). –

+0

두 작업을 동시에 수행하는 것은 배제됩니다. "큰 루프"아키텍처가 내 경우에는 받아 들여질 수 있다는 것을 알았습니까? 다른 유형의 임베디드 소프트웨어 아키텍처가 있습니까? "큰 루프"아키텍처가 제 경우에 가장 적합합니까? –

+1

@Lucky Man : 아니오, RTOS가 가장 적합한 아키텍처 IMO입니다. 당신은 RL-ARM 라이브러리를 사용할 수 있다고 했지요. 왜 당신은 지금 그것을 배제하고 있습니까? 목표 지점을 다소 옮겼습니다! 요구 사항을 살펴보면 최소한 4 ~ 5 가지 작업이 있음을 제안합니다. CAN 및 USB 스택에도 정기적 인 서비스가 필요합니다. 어떤 종류의 멀티 태스킹 커널이 없다면, main()이 종료되면 시스템이 멈출 것이므로 어떤 종류의 루프가 끝나지 않아야합니다. RTOS 작업은 일반적으로 경영진이 운영하도록 예정된 개별적인 무한 루프입니다. – Clifford