mboost-dp1
Seriel kommunikation med AT90S8535 (i C)
Vi sidder her og skal have gang i noget seriel kommunikation mellem et kit med en AT90S8535 processor og en PC. Den skal være 2-vejs, da vi skal kunne styre en motor fra PC'en og modtage andre data fra kittet (temperatur mv).
Der er sådan set ingen problemer i at modtage data fra kittet, det klares nemt ved at sætte registrene:
UCR=0x08; //UART TX enable. 8 data-bits, 1 stop-bit ingen paritets-bit
UBRR=0x33; //Baud-rate (9600baud)
og bruge f.eks. printf.
Nogen der har en ide om hvordan det foregår den anden vej?
Der er sådan set ingen problemer i at modtage data fra kittet, det klares nemt ved at sætte registrene:
UCR=0x08; //UART TX enable. 8 data-bits, 1 stop-bit ingen paritets-bit
UBRR=0x33; //Baud-rate (9600baud)
og bruge f.eks. printf.
Nogen der har en ide om hvordan det foregår den anden vej?
Jeg har med rimeligt gode resultater benyttet denne:
http://www.kmint21.com/serial-port-monitor/
Til at kigge komunikationen mellem en hardware enhed på en com port, og et .net program, efter i sømmene.
Måske kan du også bruge den?
Hvis du skal kode mod den så kan jeg da også lige fortælle at jeg bruger Sax's serial komponent (http://www.sax.net/framework/communications/) til .net og den fåes i en gratis community version (http://www.microsoft.com/downloads/details.aspx?FamilyId=EF4289B4-FFCB-40BD-9BFE-95256ABD0E13&displaylang=en).
http://www.kmint21.com/serial-port-monitor/
Til at kigge komunikationen mellem en hardware enhed på en com port, og et .net program, efter i sømmene.
Måske kan du også bruge den?
Hvis du skal kode mod den så kan jeg da også lige fortælle at jeg bruger Sax's serial komponent (http://www.sax.net/framework/communications/) til .net og den fåes i en gratis community version (http://www.microsoft.com/downloads/details.aspx?FamilyId=EF4289B4-FFCB-40BD-9BFE-95256ABD0E13&displaylang=en).
Well, det er programmet til selve kittet der er udfordringen. Vi koder i C (fordi vi stort set ikke kan andet, så der er ikke det store valg) og har bare brugt hyperterminal indtil videre.
Vi skal altså have lavet et C program der tager input fra serielporten på kittet, så vi kan behandle det. Programmet bliver compilet til hex og derefter programmerer vi kittet med PonyProg. Der er som sagt ikke noget problem i fra kit -> PC, da det blot er printf.
Kittet kan ses her
http://www.chipsguiden.dk/muhko/?side=kit
som en del af et tidligere projekt der gik ud på at få en bil til at køre selv. Normalt sidder der dog et dejligt 20x4 display og dækker det halve af kittet :)
Vi skal altså have lavet et C program der tager input fra serielporten på kittet, så vi kan behandle det. Programmet bliver compilet til hex og derefter programmerer vi kittet med PonyProg. Der er som sagt ikke noget problem i fra kit -> PC, da det blot er printf.
Kittet kan ses her
http://www.chipsguiden.dk/muhko/?side=kit
som en del af et tidligere projekt der gik ud på at få en bil til at køre selv. Normalt sidder der dog et dejligt 20x4 display og dækker det halve af kittet :)
int fgetc (FILE *__stream)
men det er afhængig af din c kompiler.
Prøv http://www.avrfreaks.net/ her er en hjemme side for avr folk.
men det er afhængig af din c kompiler.
Prøv http://www.avrfreaks.net/ her er en hjemme side for avr folk.
På avrfreaks hjemme side er en komplet vejledning til gcc kompileren men her kommer forklaringen.
dette passer KUN på gcc kompileren.
---------------------------------------------------------------
#include <stdio.h>
Warning:
This implementation of the standard IO facilities is new to avr-libc. It is not yet expected to remain stable, so some aspects of the API might change in a future release.
This file declares the standard IO facilities that are implemented in avr-libc. Due to the nature of the underlying hardware, only a limited subset of standard IO is implemented. There is no actual file implementation available, so only device IO can be performed. Since there's no operating system, the application needs to provide enough details about their devices in order to make them usable by the standard IO facilities.
Due to space constraints, some functionality has not been implemented at all (like some of the printf conversions that have been left out). Nevertheless, potential users of this implementation should be warned: the printf and scanf families of functions, although usually associated with presumably simple things like the famous "Hello, world!" program, are actually fairly complex which causes their inclusion to eat up a fair amount of code space. Also, they are not fast due to the nature of interpreting the format string at run-time. Whenever possible, resorting to the (sometimes non-standard) predetermined conversion facilities that are offered by avr-libc will usually cost much less in terms of speed and code size.
In order to allow programmers a code size vs. functionality tradeoff, the function vfprintf() which is the heart of the printf family can be selected in different flavours using linker options. See the documentation of vfprintf() for a detailed description. The same applies to vfscanf() and the scanf family of functions.
The standard streams stdin, stdout, and stderr are provided, but contrary to the C standard, since avr-libc has no knowledge about applicable devices, these streams are not already pre-initialized at application startup. Also, since there is no notion of "file" whatsoever to avr-libc, there is no function fopen() that could be used to associate a stream to some device. (See note 1.) Instead, the function fdevopen() is provided to associate a stream to a device, where the device needs to provide a function to send a character, to receive a character, or both. There is no differentiation between "text" and "binary" streams inside avr-libc. Character \\n is sent literally down to the device's put() function. If the device requires a carriage return (\\r) character to be sent before the linefeed, its put() routine must implement this (see note 2).
For convenience, the first call to fdevopen() that opens a stream for reading will cause the resulting stream to be aliased to stdin. Likewise, the first call to fdevopen() that opens a stream for writing will cause the resulting stream to be aliased to both, stdout, and stderr. Thus, if the open was done with both, read and write intent, all three standard streams will be identical. Note that these aliases are indistinguishable from each other, thus calling fclose() on such a stream will also effectively close all of its aliases (note 3).
All the printf and scanf family functions come in two flavours: the standard name, where the format string is expected to be in SRAM, as well as a version with the suffix "_P" where the format string is expected to reside in the flash ROM. The macro PSTR (explained in Program Space String Utilities) becomes very handy for declaring these format strings.
Note 1:
It might have been possible to implement a device abstraction that is compatible with fopen() but since this would have required to parse a string, and to take all the information needed either out of this string, or out of an additional table that would need to be provided by the application, this approach was not taken.
Note 2:
This basically follows the Unix approach: if a device such as a terminal needs special handling, it is in the domain of the terminal device driver to provide this functionality. Thus, a simple function suitable as put() for fdevopen() that talks to
UART interface might look like this:
int
uart_putchar(char c)
{
if (c == '\n')
uart_putchar('\r');
loop_until_bit_is_set(UCSRA, UDRE);
UDR = c;
return 0;
}
Note 3:
This implementation has been chosen because the cost of maintaining an alias is considerably smaller than the cost of maintaining full copies of each stream. Yet, providing an implementation that offers the complete set of standard streams was deemed to be useful. Not only that writing printf() instead of fprintf(mystream, ...) saves typing work, but since avr-gcc needs to resort to pass all arguments of variadic functions on the stack (as opposed to passing them in registers for functions that take a fixed number of parameters), the ability to pass one parameter less by implying stdin will also save some execution time.
dette passer KUN på gcc kompileren.
---------------------------------------------------------------
#include <stdio.h>
Warning:
This implementation of the standard IO facilities is new to avr-libc. It is not yet expected to remain stable, so some aspects of the API might change in a future release.
This file declares the standard IO facilities that are implemented in avr-libc. Due to the nature of the underlying hardware, only a limited subset of standard IO is implemented. There is no actual file implementation available, so only device IO can be performed. Since there's no operating system, the application needs to provide enough details about their devices in order to make them usable by the standard IO facilities.
Due to space constraints, some functionality has not been implemented at all (like some of the printf conversions that have been left out). Nevertheless, potential users of this implementation should be warned: the printf and scanf families of functions, although usually associated with presumably simple things like the famous "Hello, world!" program, are actually fairly complex which causes their inclusion to eat up a fair amount of code space. Also, they are not fast due to the nature of interpreting the format string at run-time. Whenever possible, resorting to the (sometimes non-standard) predetermined conversion facilities that are offered by avr-libc will usually cost much less in terms of speed and code size.
In order to allow programmers a code size vs. functionality tradeoff, the function vfprintf() which is the heart of the printf family can be selected in different flavours using linker options. See the documentation of vfprintf() for a detailed description. The same applies to vfscanf() and the scanf family of functions.
The standard streams stdin, stdout, and stderr are provided, but contrary to the C standard, since avr-libc has no knowledge about applicable devices, these streams are not already pre-initialized at application startup. Also, since there is no notion of "file" whatsoever to avr-libc, there is no function fopen() that could be used to associate a stream to some device. (See note 1.) Instead, the function fdevopen() is provided to associate a stream to a device, where the device needs to provide a function to send a character, to receive a character, or both. There is no differentiation between "text" and "binary" streams inside avr-libc. Character \\n is sent literally down to the device's put() function. If the device requires a carriage return (\\r) character to be sent before the linefeed, its put() routine must implement this (see note 2).
For convenience, the first call to fdevopen() that opens a stream for reading will cause the resulting stream to be aliased to stdin. Likewise, the first call to fdevopen() that opens a stream for writing will cause the resulting stream to be aliased to both, stdout, and stderr. Thus, if the open was done with both, read and write intent, all three standard streams will be identical. Note that these aliases are indistinguishable from each other, thus calling fclose() on such a stream will also effectively close all of its aliases (note 3).
All the printf and scanf family functions come in two flavours: the standard name, where the format string is expected to be in SRAM, as well as a version with the suffix "_P" where the format string is expected to reside in the flash ROM. The macro PSTR (explained in Program Space String Utilities) becomes very handy for declaring these format strings.
Note 1:
It might have been possible to implement a device abstraction that is compatible with fopen() but since this would have required to parse a string, and to take all the information needed either out of this string, or out of an additional table that would need to be provided by the application, this approach was not taken.
Note 2:
This basically follows the Unix approach: if a device such as a terminal needs special handling, it is in the domain of the terminal device driver to provide this functionality. Thus, a simple function suitable as put() for fdevopen() that talks to
UART interface might look like this:
int
uart_putchar(char c)
{
if (c == '\n')
uart_putchar('\r');
loop_until_bit_is_set(UCSRA, UDRE);
UDR = c;
return 0;
}
Note 3:
This implementation has been chosen because the cost of maintaining an alias is considerably smaller than the cost of maintaining full copies of each stream. Yet, providing an implementation that offers the complete set of standard streams was deemed to be useful. Not only that writing printf() instead of fprintf(mystream, ...) saves typing work, but since avr-gcc needs to resort to pass all arguments of variadic functions on the stack (as opposed to passing them in registers for functions that take a fixed number of parameters), the ability to pass one parameter less by implying stdin will also save some execution time.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund