![]() |
Robot style EOF?
What is the terminating character in the robots stream? System its EOF or '\0'. Another question if a stream > BUFFER will it allocate memory for the '\0' and place it? Also what lib's are not supported? One last question does constants in C like BUFFER, NULL, and FILE?
|
Re: Robot style EOF?
Yes, \0 is terminating character for "strings" (character arrays).
|
Re: Robot style EOF?
You will find programming for the Robot Controller in a microcontroller environment much different than programming for a PC.
To answer your questions about various library functions that are supported, please go to Microchip's page and look at their C Compiler User's Guide. |
Re: Robot style EOF?
There are no streams. There are no files. "EOF" is not a valid concept on the Robot Controller.
|
Re: Robot style EOF?
does anyone have some form of proof of this no such thing as a data stream on the robot, because the pwm passes chars to the engine and one would think that in theory that alone is a data stream and without EOF issues in ending the stream would have an issue.
MPLAB: The MPLAB® C18 compiler is a full-featured ANSI compliant C compiler for the PIC18 family of PICmicro® 8-bit MCUs. MPLAB C18 is a 32-bit Windows® console application as well as a fully integrated component of Microchip’s MPLAB Integrated Development Supports ANSI so then it must use things like EOF, enum, etc all of which people have said is not complient with the robot. |
Re: Robot style EOF?
Quote:
The only thing I can think of that might be called an engine is one of the motors, but they certainly don't accept data of any sort. What do you mean by "pwm" and "engine"? For that matter, what do you mean by "EOF"? The MPLAB C18 compiler manual details a number of ways in which the ANSI C '89 standard is not followed. So far as I can tell, however, enumeration types are supported. |
Re: Robot style EOF?
Kevin tends to use chars as another form of integers. Chars are, in fact, simply numbers, 8 bits in length that happen to be interpreted differently when sent to a terminal. There is not an "End Of File" command because you never send strings except to the camera, and then you really only send the characters and the line in terminated by a \r or \n, and wait for the camera to reply appropriately.
The processor interprets the data based on the information given to it by the code, aka if you pass a character, the processor waits for 8 bits of data, there is no need to indicate the "EOF" of a character because the processor knows that there is only 8 bits, no more, no less. The "End Of File" command is actually an antiquated way of identifying the end of files in old DOS operating systems. The "EOF" command is no longer used except as a method of terminating input at a terminal (and even then, it's rare because the EOF command varies based on the operating system, not the hardware), and for saving files for VERY old systems. It is also occasionally used as indicating the end of a file when being sent over the internet (look into netcat 1.0). The reason most systems don't use the EOF anymore is because they simply identify the size of the file at the start of the data, and then the computer doesn't need to read the whole file in order to allocate an appropriate amount of memory to display the file. |
Re: Robot style EOF?
Quote:
In response to kitscuzz: Char are 1 byte and 3 byte padding: "EOF" is not a character, its -1 an int: Name an OS does not use EOF: When passing a string to a cam: A string is an array, there is no string support in C. So all chars are saved in ordnance of the 0th element to MAX-1 element, The MAX element is '\0' || NULL in a char array and '-1’ in and int array. /*Lets for argument sake allow NULL == EOF even though there different in the char array the eof follows null*/ That is also the reason Even if you never declared the array all the function for strings must use them, thus all strings use EOF, all arrays use EOF. Brain W. Kernighan and Dennis M. Ritchie creators of c have an ANSI Book read pages 17, 28, chapter 7 151, 242+. Have a great day! |
Re: Robot style EOF?
Quote:
Quote:
|
Re: Robot style EOF?
Okay, to be pedantic:
A char is NOT 8 bits. A char is 8 bits on some (probably most) platforms, but it is not required. Here are the requirements for data types in C: A char is some size. A short is at least as big as a char. An int is at least as big as a short. A long is at least as big as an int. If you say 'a char is 8 bits', please quantify that by saying 'a char is 8 bits on the PIC, and the x86 as well'. Some DSPs have 16 or even 24 bit chars! As far as EOF, I think we need to figure out what question the original poster really meant to ask. What are you trying to accomplish, that you were thinking you needed to use EOF for? If it's for reading data from the serial, you use '\n' (or '\r', or both). Whoever said that this will be replaced with -1 is mistaken. ttyl, --buddy |
Re: Robot style EOF?
We have an /EOF at the end of all our stuff. Whatever Chris Hibner does is his own thing. I never checked on it cuz it seems to work.
Quote:
|
Re: Robot style EOF?
Quote:
I did not mean to imply that the EOF represented the size of the file, I was saying that the EOF has been replaced by the size of the file. As for what the EOF is, it is only returned, as the URL you directed me to says, by functions that are reading files or input from the terminal or another application. - EOF (0xff 0xff) is returned by fgetc() due to end of input You can also trigger an EOF by typing into the terminal a predefined sequence into a terminal. This is what I meant by "OS-specific" because the sequence to send the EOF to a terminal is dependent on the OS (for example on a windows system it's ctrl+z). As you said "EOF is a macro and is used for every line of stream." But unfortunately it is only triggered when you reach the end of a stream. This will NEVER HAPPEN unless you are reading from file or terminal, and when reading from a terminal, you need to have someone type an EOF (which won't be triggered while running the robot in normal conditions). Anyway, the point is that since we don't use files, we don't recieve an EOF. Hope that clears up any confusion. |
| All times are GMT -5. The time now is 04:45. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi