:::: MENU ::::
Browsing posts in: Network

Gmail의 메일을 확인해 주는 파이썬 스크립트

Gmail 계정에 새로운 메일이 있는지 확인해 주는 파이썬 스크립트이다.

Feedpaeser라이브러리가 필요하다. http://code.google.com/p/feedparser/

파이썬에서 시리얼을 쓰러면 Pyserial도 필요하다. http://pyserial.sourceforge.net/

import serial, sys, feedparser

#Settings - Change these to match your account details
USERNAME="[email protected]"
PASSWORD="yourpassword"
PROTO="https://"
SERVER="mail.google.com"
PATH="/gmail/feed/atom"

SERIALPORT = "/dev/tty.usbserial-FTDK0P3M" # Change this to your serial port!

# Set up serial port
try:
    ser = serial.Serial(SERIALPORT, 9600)
except serial.SerialException:
    sys.exit()

newmails = int(feedparser.parse(
    PROTO + USERNAME + ":" + PASSWORD + "@" + SERVER + PATH
)["feed"]["fullcount"])

# Output data to serial port
if newmails > 0: ser.write('M')
else: ser.write('N')

# Close serial port
ser.close()

이 코드를 일정한 시간 간격 주기적으로 실행을 하려면, Mac OS X에서는 Launchd가 필요.

Launchd관련 정보 http://zcode.sunji.net/groups/zcode/wiki/4c5b5/launchd__lingon.html

Arduino + Ethernet shield로도 가능할 듯..


Wake on LAN

Wake on LAN은 네트워크 패킷(매직 패킷)으로 컴퓨터를 켜거나, 깨우는 기능을 하는 AMD와 HP에서 만든 표준이다.

요즘 PC들은 전원을 꺼도 이더넷 잭에 연결된 LED가 깜박이는 것을 볼 수 있는데, 즉 LAN은 패킷을 받을 수 있는 모드에 있다. 

AMD의 White paper

cfile26.uf.1225CD3F5022E8BF13F2F0.pdf

매직 패킷의 구성

매직 패킷은 2가 있는데, ether-wakeUDP상에서 구현하는 패킷이 있다. 대부분의 PC 프로그램이 보내는 패킷은 후자이다.

아래 내용은 ether-wake패킷의 구성이다. 출처) http://wiki.wireshark.org/WakeOnLAN

이 사이트에서 관련 패킷 샘플도 다운로드 가능하다.

Synchronization Stream

Target MAC

Password (optional)

6

96

0, 4 or 6

-. Synchronization Stream : FF FF FF FF FF FF

-. Target MAC: 깨울 상대의 맥 어드레스

-. Password: 옵션

즉 옵션이 없고 맥 어드레스가 01:02:03:04:05:06 이면 패킷의 형태는 다음과 같다.

FFFFFFFFFFFF010203040506010203040506010203040506010203040506 010203040506010203040506010203040506010203040506010203040506 010203040506010203040506010203040506010203040506010203040506 010203040506010203040506



아래 첨부 파일은 매직 패킷을 Wireshark로 캡쳐한 것이다.[출처: Wireshark.org]

Ether-wake와 UDP 패킷 2가지가 나와있다.

cfile26.uf.125CBA4350259BC91C8AB5.pcap


매직 패킷을 보낼 수 있는 프로그램

Fusion WOL

http://fusionfenix.com/product/wol-1-0

찾아보면 이것말고 꽤 있다.

W5200의 WOL 기능

-. Wake On LAN과 Power down mode와는 아무 관련이 없다. 그리고 power down mode를 enable하면 패킷을 못 받는다.

-. 즉 WOL은 MCU가 sleep하고 있고, W5200은 동작하고 있는 상태에서 WOL기능을 이용해서 매직 패킷을 받으면 인터랍트가 떠서 MCU 깨울때 사용하면 다.

-. 단 주의 사항은 W5200은 ether-wake 패킷만 지원을 한다. 

   따라서 PC에서 raw Ethernet Packet을 보낼 수 있는 프로그램이 필요하다.

참고

http://en.wikipedia.org/wiki/Wake-on-LAN

http://wiki.wireshark.org/WakeOnLAN

http://support.amd.com/us/Embedded_TechDocs/20213.pdf


TI의 SimpleLink Wi-Fi CC3000

TI가 기존의 오픈 소스 무선랜 솔루션이 외에 새로이 SimpleLink 라는 Wi-Fi 솔루션을 릴리즈 했다. EETimes 기사
이 기사에 따르면 잔디깍기, 그릇 세척기, 알람시스템, 홈시큐리티, 혈압 모니터 등의 가전, 홈네트워크 및 헬스케어 디바이스에 쉽게 Wi-Fi를 추가할 수 있다고 한다. 심지어 우산에 장착해서 기상시스템에 연결해서 비가 올것으로 예상이 되면 LED를 켜는 내용의 소개도 있다.

마케팅 매니저인 Kurtz에 의하면

“We realized that it was unreasonable to expect them to start running Linux and change to a high performance applications processor, so knowing the potential of the Internet of Things market, we rolled up our sleeves and rearchitected our existing Wi-Fi solution to make it suitable for any product – regardless of the architecture,” he said, adding that SimpleLink offered customers a “blueprint to connect even the simplest devices to the Internet.”

기존의 임베디스 Wi-Fi 솔루션을 가지고 있던 업체들과 동일한 얘기이다. 즉 Gainspan이나 Redpine Signals의 솔루션과 바로 경쟁이 될듯하다.
아래 동영상을 보면 상당히 쉬운 솔루션으로 소개를 하고 있으며, IoT(Internet of Things)의 시대가 바로 얼마남지 않은듯 하다.

Features



  • Wi-Fi 802.11 b/g

  • Best-in-class Link Budget

  • TX Power: +20dBm

  • RX Sensitivity: -89dBm

  • Embedded software including all drivers, stack, and supplicant

  • Low code size (Flash and RAM) required for MCU

  • Certified and production-ready modules

  • Complete platform solution including API guide, sample applications, Support Community (Wiki and Forum), User and porting guides

Benefits



  • Universal IP connectivity enabled anywhere

  • Enables low memory, low cost, low power MCU systems

  • Longer range advantage vs. competition

  • Proven Wi-Fi RF and interoperability

  • Implement Wi-Fi quickly without previous Wi-Fi or RF experience

  • Reduce development timeline and cost with CC3000 implementation and support infrastructure

  • Simple certification process, reusing module RF certification

  • Smaller board space for compact layouts


위 블럭다이아그램에 보듯이 Host MCU와는 SPI로 통신을 한다. SPI clock은 최대 26Mhz까지..
CC3000을 self-contained wireless processor라고 표현을 하는데, 이 말은 Wi-Fi를 위해 대부분의 처리는 CC3000에서 하므로 Host 시스템에서는 별로 할 것이 없다는 얘기이다.
정말 그런가? 이건 뒤에서 더 살펴보기로 하고…

제공되는 개발 플랫폼은
MSP430 기반의 보드 4종
CC3000 + MSP430 FRAM, CC3000 + MSP-EXP430F5529, CC3000 + MSP-EXP430F5438, CC3000 + MSP-EXP430FG4618
Cortex-M3기반 1종 CC3000 + Stellaris Cortex-M3,
Cortex-M4기반 1종 CC3000 + Stellaris Cortex-M4 이 있다.
모듈도 제공을 하는데 현재 LS Research사의 TiWi-SL이 있고 Murata에서 TypeVK를 출시 예정이다.

얼마나 쉽길래 SimpleLink 일까?
하드웨어적으로는 위 블럭 다이아그램처럼 간단히 SPI, IRQ, 전원정도만 연결을 하면 된다. 하지만 CC3000을 제어하기 위해서는 Host MCU에 SPI 드라이버를 포팅해야 한다. 이것도 이미 MCU에 대해 일반적인 지식이 있으면 어렵지 않다.

Host Driver Porting Guide
관련 자료 : http://processors.wiki.ti.com/index.php/CC3000_Host_Driver_Porting_Guide
MSP430을 쓰면 별도의 포팅 가이드 없이 제공해 주는 것을 쓰면 되겠지만 그렇지 않은 경우에는 위 가이드를 참고해서 같은 수준의 SPI 드라이버를 포팅한다.

Host Programming Guide



위 두 그림을 보면 TI에서 제공하는 s/w가 어떤 식으로 구성이 되는 지 알 수 있다. 위 두 그림은 같은 내용의 그림인데, 윗쪽의 그림을 보면 각 API가 command로 동작을 하고 event 기반임을 알 수 있다. 결국 SPI인터페이스 위에 HCI(Host Controlled Interface 의 약자)레이어가 있고, 4개의 API로 모듈화를 시켜놓았다.
각각의 모듈의 기능은 다음과 같다.



  • WLAN APIs, which interact with the underlying entity that is responsible for 802.11 protocol implementation

  • Network stacks APIs, which interact with the embedded network stack. These APIs comply with the well-known Berkeley socket APIs and are easy to use.

  • Embedded network application APIs, which interact with the embedded networking application delivered as a complementary part of the on-chip content. These include basic networking applications that the user can leverage (for example, ping utility and DNS).

  • Nonvolatile memory (NVMEM) APIs, which configure the external CC3000 device EEPROM, where most of the configuration is store.


코드를 보니 사실 NVMEM API는 configuration을 위한 독립적인 API이고, 나머지는 WLAN, SOCKET, NETAPP API는 서로 관련이 있는 API들인데, NETAPP API는 arp, ping, DHCP 및 IP 설정등을 담당하고, SOCKET API는 기본적인 TCP 함수들 send, recv, bind 등의 함수를 제공한다. WLAN API의 경우는 wlan 연결 설정 및 connect, close 등의 함수를 제공한다.
따라서 결론적으로 위의 코드들이 host MCU에 다 올라가야 한다는 얘기이다. -_-;;

임베디드시스템에 Wi-Fi를 추가하기 위해 어려운 점은 다음과 같다.
-. Linux와 같은 OS를 포팅해야 한다. 기존 시스템을 OS 기반의 시스템으로 전분 바꿔야 할지도…
-. RF에 대한 지식 부족. 전문가가 아니면 쉽게 손대기 힘들다. 따라서 모듈을 쓰는 경우가 많다.
-. 인증에 대한 비용 및 시간.
-. Wi-Fi 솔루션의 비용. 배보다 배꼽이 더 커질 수 있다.

SimpleLink가 많은 부분을 커버하고 있긴 하지만, AT command 기반의 seiral to Wi-Fi 모듈보다는 Host쪽에 코드를 포팅하는 작업은 그리 만만치 않아보인다.

보다 자세한 자료는 TI의 Wiki 페이지에서…http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_for_MCU


STM32 Journal

ST에서 발간하는 STM32 Journal 첫호입니다.

cfile24.uf.190D3B4B4EEAEA973742D8.pdf

주로 새로 출시한 STM32 F4에 대한 설명이 있습니다.


Connectivity쪽 자료를 보면 아래 그림과 같은 테이블이 나옵니다.


아래 테이블을 보면 MCU에서 초당 처리해야할 패킷의 수가 수치적으로 나와 있습니다. 당연히 한 패킷당 바이트수가 작을 수록 처리해야할 패킷의 수가 많습니다. 100Mbps의 경우는 10Mbps의 경우의 10배이고…
그리고 괄호안의 수치는 각 Bandwidth를 만족하기위한 1 패킷을 처리하기 위해 걸리는 시간입니다.
즉 MCU가 최소한 이정도 성능이 있어야 10M, 100Mbps를 만족한다는 것인데…

uC/TCP-IP 스텍을 사용시 zero copy 아키텍쳐를 사용하여 dedicated memory에 비해 장점이 있다고 설명을 합니다.



Ethernet 시스템 Layout guide

임베디드 시스템에서 Ethernet은 물리적으로 Ethernet Controller + Magnetic + RJ45로 이루어 진다.
Ethernet Controller는 다시 Etherent MAC + PHY로 구성이 되는데, Ethernet MAC의 경우 최근 MCU에 들어가 있는 경우가 많고 MAC/PHY칩으로 존재하기도 한다.
Magnetic의 경우 코일이 감겨진 transformer를 얘기하는데 RJ45잭 안에 이 Magnetic이 들어가 있는 경우 흔히 MagJack이라고 불리운다. 사실 MagJack은 BelFuse사의 trade mark이다. PoE를 지원하는 MagJack의 경우 이전 포스트를 참고.
임베디드 시스템에서 Ethernet의 하드웨어를 구현시 PCB 레이아웃을 할때는 PHY의 뒷단 부터는 신호의 무결성을 위해 
신경을 써야 한다. 대부분 PHY칩 업체의 가이드를 따르면 되며, 모든 벤더들의 가이드 역시 대동소이하다.

Micrel사의 디자인 가이드

cfile4.uf.206119494EDEFD94288766.pdf


Davicom사의 디자인 가이드
cfile9.uf.15635D494EDEFD94263063.pdf
IC Plus사의 디자인 가이드


cfile3.uf.186107494EDEFD9528439C.pdf
Reaktek 사의 디자인 가이드


cfile24.uf.127843494EDEFD95061C16.pdf


IEEE 1588 PTP (Precision Time Protocol)

장비 내 각각의 부분별로 별도의 정확한 클럭이 존재하지만 ns에서 μs 사이에 발생하는 회로의 변화나 작은 차이도 금방 누적된다. 또한 네트워크 장비에서의 버퍼링등으로 인한 딜레이 및 연결로 인해 레이턴시 지연, 즉 ‘지터(Jitter)’ 또한 발생한다. 하지만 PTP를 추가함으로써 이러한 타이밍에 대한 보상을 함으로써 문제를 해결할 수 있다. 네트워크 구성과 장비에 따라 수십ns~수μs 내로 클럭을 동기화 할 수 있다.

이러한 기능이 필요한 한가지 예는 스마트 그리드 시스템이다. 즉 peak-hour 빌링 같은 기능을 위해 정확한 시간정보가 필요하다. PTP의 장점은
-. 이미 네트워크 기능이 들어가 있는 장비에 PTP 프로토콜을 탑재함으로써 적은 비용으로 이런 기능의 구현이 가능하고,
-. Multicast(UDP)를 이용해서 작은 bandwidth 만 요구된다.

PTP는 IEEE 1588 에 Precision Clock Synchronization for Networked Measurement and Control Systems 로 정의가 되어 있다. 이 표준은 디바이스가 네트워크상에서 가장 정밀하고 정확한 클럭을 활용할 수 있는 프로토콜을 제공한다.
2 가지 버젼, PTP v1 IEEE 1588-2002, PTP v2 IEEE 1588-2008 이 있는데 하위 호환성은 없다.
MAC/PHY칩의 경우 H/W 적으로 IEEE 1588 time stamp 기능이 있는 칩이 있는데, 이런 칩의 경우 수 usec 내의 정확도를 보장하며, S/W만으로 구현할 경우 수 msec정도의 정확도가 가능하다. 
참고로 PHY에서 IEEE 1555을 지원하는 것도 있다. NI사의 DP83640 


cfile8.uf.133D703D4EDC981C0DC0A6.pdf




PTP Network




Master1이 문제가 있으면 Master2가 Grandmster가 된다. IED (Intelligent Electronice Device)

클럭 동기화를 위해 PTP는 time source인 마스터와 receiver인 슬레이브사이의 path delay를 정확히 측정을 해야하는데 아래 다이아그램에 있는 것 처럼 메시지를 보내고 메시지를 수신함을써 이것을 측정한다.



1. Master가 Sync를 보내고 Slave는 이것을 수신한 시간을 기록. 82초
2. Master가 Follow up 패킷을 보낼때 데이터에 보낸 time stamp(100)을 넣어서 보냄. 
   Slave는 100-82를 해서 옵셋을 보정함. 보정을 하니 Master가 103초일때 Slave는 101초이다. 즉 2초가 차이가 난다.
3. 이제 path delay만 보정하면 되는데, master to slave delay는 0 이다.<= 계산 방식은 위와 동일
   Slave to master delay는 4이다. 따라서 이것을 2로 나누면 +2초. 따라서 이 path delay 2초를 보정을 하면 master와 
   slave간에 동기가 맞아진다.

구체적인 구현이나 테스트를 위해 보면 좋은 자료
IEEE 1588 precision time protocol demonstration for STM32F107 connectivity line microcontroller


cfile29.uf.197FC53C4EDCA3E63148A9.pdf



참고
NI자료 Introduction to Distributed Clock Synchronization and the IEEE 1588 Precision Time Protocol
시스코 자료 Cisco CGS 2520 Switch Software Configuration Guide for IOS Release 12.2(58)EY


PoE 지원 MagJack

Ethernet 응용에서 가장 뒷단에 붙는 RJ-45 잭의 경우 흔히 맥잭(MagJack)이라고 부른다.
그런데 MagJack은 magnetic(transformer)이 내장된 RJ-45으로 Belpuse사에서 사용하는 이름이다. PoE를 위해서는 PoE를 지원하는 MagJack를 사용해야한다.
회로에서는 LAN 선의 1,3,5,6 또는 4,5,7,8 번 핀을 통해 전달되는 전원을 분리해야 한다.
아래 데이터시트는 BelPuse 및 UDE사의 PoE지원 MagJack

cfile9.uf.203B56374EB363B7184388.pdf


cfile29.uf.1643EE374EB363C70A2837.PDF



퀄컴 아데로스 AR4100

퀄컴이 아데로스를 인수했죠.
들리는 얘기로는 아데로스의 분위기는 더 좋아졌고, 퀄컴의 connectivity 부분이 아데로스와 합쳐져서 더 켜졌다고 합니다.

암튼 AR4100은 11n을 지원하지만 1T1R (SISO)로 low power, low cost, low end를 타겟으로 하고 있습니다.

인터페이스도 SPI를 제공해서 low end MCU에서도 사용이 가능하게 되어 있는데, 현재 지원되는 개발 환경은 주로 Freescale솔루션에 적용이 가능합니다.

Currently Supported Development Environment
• Freescale Tower Development Platform
• ColdFire MCF52259 or Kinetis MCU with greater then 128K NVM
• Freescale MQX™ version 3.6.2
• Freescale CodeWarrior® tool suite v7.2 for the ColdFire 52259 processor
• IAR Embedded Workbench® v6.10 for the Kinetis MCUs

cfile25.uf.1331BD3B4E0C3CB5027F2E.pdf


Pages:1234