I have the following code that prints the buff[ i ] value to the serial monitor (it's a continuous stream coming in via UDP) but I'd like to extract the value and use it elsewhere. In the snippet below I'm just trying to reassign the buff[ i ] value to a new variable, t, and print that., but all I get is a zero value.
Any tips greatly appreciated.
inData = recvfrom(sockfd, buff, sizeof(buff), 0, (sockaddr*)&from, &sockLen);
int i;
//-----print buffer contents------//
for(i=0;i<sizeof(buff);i++){
Serial.print(buff[i]); // This bit works as expected
int t = buff[i];
}
Serial.println("here comes t!");
Serial.println(t); // This always returns a zero value
if (t >= 300) {
Serial.print("made it!"); // This never happens
}}
No, it isn't. It's populated with new data each time the function is called. That is not the same thing.
for(i=0;i<sizeof(buff);i++){
Serial.print(buff[i]); // This bit works as expected
int t = buff[i];
}
While that works, it is useless. You are only copying one byte at a time into t, which is of the wrong type. It is also local to the for statement, so it goes out of scope when the loop ends.
If that snippet compiles, it is because you have t declared somewhere else. Using the same name for two different variables in two different, overlapping, scopes is a BAD idea.
if (t >= 300) {
Since the value you were trying to assign to t was in the range 0 to 255, this obviously will never be true.
Now, you need to show us the kind of data that is in the UDP packet, so we can suggest ways to accomplish your goal that will actually work.
Global scope, where a data item is defined outside of any function. That data item is "visible" everywhere in the source file.
Function scope, where a data item is defined within the opening and closing parentheses, but not within a statement block. Some people also call this local scope. The data item is visible everywhere within the function, but not outside the function.
Block scope, where a data item is defined within the opening and closing parenthesis of a keyword (e.g., for, if, while, etc) statement block. The data item is visible only within the statement block.
int myGlobla; // Global scope
int myFunction()
{
int i; // Function scope.
for(i=0;i < sizeof(buff); i++){
Serial.print(buff[i]);
int t = buff[i]; // block scope
} // closing parenthesis for statement block
}
because you defined t within the for statement block, it has block scope. Because t "dies" (i.e., goes out of scope) when the closing parenthesis of the for loop is reached, t is no loner available for use. As PaulS pointed out, this should draw a compiler error unless you have another t defined at function or global scope...a really bad idea.
Just had time to get back to this. Thank you for your thorough and excellently explained replies. Got my head round the scope thing and all works fine.
Anyone knows if it is possible to print in the Serial Monitor the buffer from a UDP Message in port 162 (SNMP Trap)?
It is possible to print anything you want in the Serial Monitor. That can include anything in a buffer, regardless of where the buffer came from. "a UDP Message in port 162 (SNMP Trap)" doesn't make sense, though. UDP messages are not IN ports. They come FROM ports, but the where and why is irrelevant.
I'm trying to generate a trap through a SNMP Manager (iReasoning MIB Browser, as you can see in the attachment "..Send Trap.png") and receive it in Serial Monitor.
However the result of the received buffer is very unusual. It has only two digits that are changing depending on the information that I add in the Trap (you can see it in "serial monitor.png").
I don't know if you are familiar with this kind of messages (SNMP Trap): they nomarlly have bindings associated and each binding could have a String or Integer information.
I was hoping that when Arduino receives this kind of message could concatenate all the information stuff in a buffer and show it in Serial Monitor. But I think that I am wrong with this thought.
I'm using the sketch UDPSendReceiveString form Ethernet Library. I have already increased the variable UDP_TX_PACKET_MAX_SIZE in EthernetUDP.h to support more info but the results were the same. If you please notice something wrong in my thoughts please let me know.
