- Fri Jun 17, 2016 11:56 pm
#49365
Ok, so I'm burning time I don't have on this, but what follows is code that might actually work if plugged into the interpreter:
Now what? I don't know what to do with this. I guess it gets compiled and flashed or something but that's beyond my feeble brain.
I can see why this was not done in the first place. The device codes are 8 byte values and they don't represent easily in what appears to be a 32 bit system with handy conversion functions that only work with 32 rather than 64 bits. Even if we can declare 64 bit unsigned integers, we'll probably want to express them as character strings to save in flash based files or something. If the device rom codes were 32 bits, this would have been so much easier!
Fascinating exercise! I learned a little about how the interpreter is written. I'd have used tokenization to eliminate variable and function lookups but the writers did a great job of keeping the code organized and functional. Check line 50 though:
if (Name == F("D8")) PinReturnValue = 13;
I think that should be 15, not 13.
Code: Select all
// the following 3 declarations need to be made somewhere to have them available for both functions.
byte devAddr[8]; // create 8 byte storage area for device code
String junk=""; // Need a place to compile results or process code "halves"
byte index; // Just any old counter
// The rest can be plugged into the interpreter code right after the temp() function handler:
else if ( fname == F("temp_ids") && num_args == 0 ) {
// function temp_ids()
// Return all connected sensor ROM codes as space-separated string (16 characters each)
junk="";
for (index=0; sensors.getAddress(deviceAddr,index); index++) // Loop while devices are found
{
if (index>0) junk.concat(" "); // If not the first device, add a separator space
junk.concat(String(*((uint32_t *)devAddr), HEX); // Convert & append the first 4 bytes of device code
junk.concat(String(*((uint32_t *)(&devAddr[4])), HEX); // Convert and append the last 4 bytes of device code
}
*value_str = junk;
return PARSER_TRUE;
}
else if ( fname == F("temp_by_id") && num_args == 1 ) {
// function temp_by_id( Rom Code ) Rom code is a 16 character hexadecimal string
// Return all connected sensor ROM codes as space-separated string
sensors.requestTemperatures(); // Tell all sensors to convert analog to digital
junk=args_str[0].substring(0,7); // Get first 8 characters and...
junk.strtoul(devAddr, NULL, 16); // ... convert them to the first 4 code bytes
junk=args_str[0].substring(8); // Do the same with the remaining 8 bytes
junk.strtoul(&devAddr[4], NULL, 16);
*value = sensors.getTempC(devAddr); // Perform the temperature read by device code
return PARSER_TRUE;
}Now what? I don't know what to do with this. I guess it gets compiled and flashed or something but that's beyond my feeble brain.
I can see why this was not done in the first place. The device codes are 8 byte values and they don't represent easily in what appears to be a 32 bit system with handy conversion functions that only work with 32 rather than 64 bits. Even if we can declare 64 bit unsigned integers, we'll probably want to express them as character strings to save in flash based files or something. If the device rom codes were 32 bits, this would have been so much easier!
Fascinating exercise! I learned a little about how the interpreter is written. I'd have used tokenization to eliminate variable and function lookups but the writers did a great job of keeping the code organized and functional. Check line 50 though:
if (Name == F("D8")) PinReturnValue = 13;
I think that should be 15, not 13.
