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?
Yes, \0 is terminating character for “strings” (character arrays).
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.
There are no streams. There are no files. “EOF” is not a valid concept on the Robot Controller.
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.
I have no idea what you mean by this. PWM stands for Pulse Width Modulation and refers to the signalling used to command servo position and the Victor speed controller outputs. It also gets used to refer to the three-wire cables and connectors that carry those signals, and by extension to similar cabling and connectors used to carry other signals.
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.
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
, 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.
Actually EOF does not identify the size of the file or the start of data. EOF stands for End Of File/stream and job to signal like a semicolon in C statements, that the particular data stream is finished. EOF is represented as -1 or ‘\o’. As a native C programmer I have never heard anyone ever mention that EOF was no longer a macro in the standard lib anymore ^ have I seen it even not been. I understand that when working with robot on partial C code that does not conform to ANSI or hides most the code in many files that you just assume that if you don’t run across EOF does not mean its not there. EOF is a macro and is used for every line of stream. AKA after every
a -1 is placed. Think of it as more of an End OF line. http://www.cprogramming.com/faq/cgi-bin/smartfaq.cgi?id=1043284351&answer=1048865140
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!
I’m still confused. What do you mean by “stream”? I understand it as a C++ or Java concept for dealing with reading and writing strings. Regular ANSI C doesn’t have it. MicroChip C certainly does not.
In response to kitscuzz:
Char are 1 byte and 3 byte padding:
This is absolutely incorrect. In MicroChip C (and EasyC), a char holds an eight-bit value. One byte. No padding.
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 ’
’ (or ‘\r’, or both). Whoever said that this will be replaced with -1 is mistaken.
ttyl,
–buddy
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.
#endif
/* EOF */
That is basically after everything, he must put it in for his own reference.
For the camera thing, yes, you send individual characters to the camera. That was what I meant by “strings except to the camera, **and then you really only send the characters and the line in terminated by a \r or
**, and wait for the camera to reply appropriately.” You send the characters with no \0 (but I’m not sure whether or not the \0 needs to be sent, someone more experienced should confirm that).
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.