Файловый архив студентов. Файловый архив студентов.
1313 вуза, 5304 предмета.
/ Регистрация
FAQ Обратная связь Вопросы и предложения
Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Санкт-Петербургский государственный электротехнический университет "ЛЭТИ"
Предмет:
Электротехника
Файл:

Bailey O.H.Embedded systems.Desktop integration.2005

.pdf
Скачиваний:
73
Добавлен:
23.08.2013
Размер:
9.53 Mб
Скачать
☆

440

Chapter 10 / The PSoC Prototype

 

 

people. There are several ways to limit access. One method is to check the origination IP address against a list of accepted addresses to see if it is an authorized control station. We could also add a password so that the user could be authenticated, limiting access to specific individuals working from specific workstations. In short, there are many ways to provide controls

prohibiting unauthorized use. The following listing illustrates one way of implementing UDP to connect to the PSoC.

Listing 10-6

/****************************************************************************** UDP Test Program for PSoC – Copyright 2004, Oliver H. Bailey

This program is for Embedded Systems, Desktop Integration Book

*****************************************************************************/

#include "predef.h" #include <stdio.h> #include <ctype.h> #include <startnet.h> #include <ucos.h> #include <udp.h> #include <autoupdate.h> #include <string.h> #include <taskmon.h>

extern "C"

{

void UserMain( void *pd );

}

// We

have to use 4 byte aligment for the NetBurner

DWORD

UdpTestStk[USER_TASK_STK_SIZE] __attribute__( ( aligned( 4 ) ) );

/******************************************************************************* The UDP Read Packet Function. - Waits for 100 clock ticks and then returns if no data arrived.

*******************************************************************************/

void UDPRead( void *pd )

{

int UDP_port =

( int ) pd;

//

UDP Port Number assignment

printf( "Using

port #%d\n", UDP_port );

//

Print Port Number

 

Chapter 10 / The PSoC Prototype

441

 

 

 

 

OS_FIFO Read_fifo;

// Create Read fifo

 

OSFifoInit( &Read_fifo );

// and Initialize the fifo

 

RegisterUDPFifo( UDP_port, &Read_fifo );

// Register the port number and buffer

while ( 1 )

// Do Forever

 

{

 

 

 

UDPPacket upkt( &Read_fifo, 100);

// Return on data or timeout

 

if ( upkt.Validate() )

// If we receive valid data, process

{

 

 

 

WORD Data_len = upkt.GetDataSize();

// Data length

 

printf( "Got %d UDP Bytes From :", ( int ) Data_len );

 

ShowIP( upkt.GetSourceAddress() );

// Data Source IP Address

 

printf( "\n" );

 

 

 

ShowData( upkt.GetDataBuffer(), Data_len ); // Display actual data

 

printf( "\n" );

 

 

 

}

// End of Valid Packet Data Handler

}

// End of do forever loop

 

}

// End of UDPRead

 

const char *AppName = "PSoC UDP Example";

void UserMain( void *pd )

{

int UDP_portnum; IPADDR UDP_addr; char buffer[80];

InitializeStack();

EnableAutoUpdate();

EnableTaskMonitor();

printf( "PSoC UDP BroadcastTest \n" ); printf( "Input the port number?\n" ); scanf( "%d", &UDP_portnum );

printf( "\nEnter the IP Address to send to?" ); buffer[0] = 0;

while ( buffer[0] == 0 )

{

//PortNumber Variable

//UDP Address Variable

//Buffer

//Initialize the Program Stack

//Enable Auto Update feature

//Enable Task Monitor

//Program Purpose

//Get Port Number from User

//Scan and Store

//Get Target IP address

//Buffer element = 0

//No keyboard data, wait

Chapter 10

442

 

Chapter 10 / The PSoC Prototype

 

 

 

 

 

 

gets( buffer );

// else, get Keyboard data

}

 

 

 

UDP_addr = AsciiToIp( buffer );

// Convert to dot notation

// Print Port Chosen

 

printf( "%d UDP Port in use ", UDP_portnum );

 

ShowIP( UDP_addr );

// Print IP Address

printf( "\n" );

 

OSChangePrio( MAIN_PRIO );

// Bump up task priority

OSTaskCreate( UDPRead,

// Let’s create a blocking read task

 

 

( void * ) UDP_portnum,

 

 

 

&UdpTestStk[USER_TASK_STK_SIZE],

 

 

 

UdpTestStk,

 

 

 

MAIN_PRIO - 1 );

// Make it lower priority

while ( 1 )

// Another Endless Loop

{

 

 

 

 

buffer = "Hello World\n";

// The infamous Hello World

 

printf( "Sending %s on UDP port %d to IP Address ", buffer, UDP_portnum );

 

ShowIP( UDP_addr );

// Display Target IP Address

UDPPacket pkt; pkt.SetSourcePort( UDP_portnum );

pkt.SetDestinationPort( UDP_portnum ); pkt.AddData( buffer ); pkt.AddDataByte( 0 );

pkt.Send( UDP_addr );

//Create a UDPPacket instance

//Select Source Port Number

//Set Destination Port Number

//Put buffer data in transfer buffer

//Add terminating NULL

//Send it to the destination address

printf( "\n" );

};

}

This program has two tasks, each contained in a do forever loop. The first task checks for valid incoming UDP data. If no data is received in 100 clock ticks, then it starts the wait cycle over again. The second task sends UDP data repeatedly.

Chapter 10 / The PSoC Prototype

443

 

 

This is a very simple demo for the NetBurner device. We could add multicasting, which allows support for broadcasting temperature data to multiple receivers. The purpose of this program is to get you familiar with the differences between TCP/IP and UDP. It also serves as a simple program that illustrates the process of setting up UDP data handlers in the NetBurner environment.

PSoC Schematics

Chapter 10

Figure 10-25: PSoC schematic

444

Chapter 10 / The PSoC Prototype

 

 

 

 

 

 

 

 

 

 

 

 

Figure 10-26: PSoC schematic

Chapter Summary

In this chapter we’ve seen how to implement the thermostat using the Cypress PSoC and EZ-USB. While the PSoC brings more flexibility than any of the other microcontrollers, it comes at the expense of much higher complexity and a deeper understanding of how the microcontroller internals work. The PSoC is a convergence of software and hardware technologies.

Chapter 10 / The PSoC Prototype

445

 

 

Hardware Summary

We have now implemented three different microcontrollers and three different USB interfaces. We have also used several different languages and methods of connecting each different type of interface to the desktop and embedded processor — from the simple to the complex. We could spend thousands of pages on these subjects and still not cover all the available information. The intention is to provide you, the reader, with the information to make a good decision in selecting components. In the course of developing each prototype we have published small code snippets to give you the experience of using different types of software tools and interfaces. For in-depth descriptions, please review the project source files as they contain very detailed information on how the software was implemented and interfaced to system clocks and other microprocessor-specific hardware. In the next and final chapter we look at the tools used to develop cross-platform software.

Chapter 10

This page intentionally left blank.

Chapter 11

Cross-Platform

Application

Development

We’ve finally reached the last chapter and desktop software development is our last remaining topic. We’ve planned all along to have our embedded system accessible from different platforms, so now we are ready to see how well our design works or even if it will work. Before we begin, let’s review the three different types of hardware interfaces and how well supported they are on different platforms.

Even though we are developing prototypes using different brands of hardware tools, the rules for developing single-source cross-platform software remains the same. In this chapter we will focus on the development strategies and steps necessary to develop cross-platform device interfaces and cross-platform user applications. These will be covered as separate topics for clarity. Let’s begin by looking once again at the three types of host interfaces we have implemented.

447

448

Chapter 11 / Cross-Platform Application Development

 

 

Ethernet, TCP/IP, and UDP

Ethernet is both well defined and well supported across all computers built today. As a wired interface it has become inexpensive and fast, making it the favored way to introduce DSL and cable into a building. Additionally, it is very well documented and supported on all computers as a means for creating and accessing a network. Today’s Ethernet standards have evolved from several different technologies into a solid, well-defined and supported network standard.

The software that makes the Ethernet interface so widely available is TCP/IP. From the desktop integration point of view TCP/IP is supported on every major computing platform available today. Windows, Linux, UNIX, FreeBSD, Macintosh, and even IBM mainframes all support the TCP/IP protocol suite. Of even greater importance is the fact that all of the above mentioned systems are running either Windows, Linux, or a version of BSD as the core operating system, at least at the kernel level. Also of importance is the fact that TCP/IP is supported at the operating system level of all the above mentioned systems and using a common, well-defined and portable interface, the socket library.

With the exception of Microsoft Windows, the Berkeley sockets are the standard interface when using UNIX-, Linux-, or BSD-based systems. This includes the Mac OS X, which is based on the BSD kernel. Microsoft chose to implement a slightly different version known as Winsock. The differences can be distinguished by using the define statements in the program source code, allowing us to have a single source interface to the Ethernet layer of the operating system.

Chapter 11 / Cross-Platform Application Development

449

 

 

RS-232 Support

Also supported at the operating system level, and as well as Ethernet, is the old RS-232 interface. This interface is supported identically on Linux-, UNIX-, and BSD-based systems with the exception of naming. Different operating systems sometimes name these ports slightly differentlym but for the most part they are accessed as stty devices in the /dev directories. This is true for Linux, UNIX, BSD, and the Mac OS X systems.

Again Microsoft Windows developed RS-232 support differently, choosing instead to use the old DOS naming and interface conventions. While all the operating systems treat the COM port as a file type device, device control is the major difference between Windows and the other systems. Even so, by developing an intermediate library we can use the same high-level calls from our application on Windowsand UNIX-based systems.

USB Support

Of the three host interface types USB has the biggest number of differences in its device driver layer. This is mostly due to differences in how kernel mode drivers are implemented in Windows and the fact that Windows has a unique way of implementing human interface devices (HID). Adding the USB support layer will be the most challenging of all the device interfaces.

Chapter 11

Соседние файлы в предмете Электротехника
Помощь Обратная связь Вопросы и предложения Пользовательское соглашение Политика конфиденциальности