Go Down

Topic: Invalid conversion from 'const_FlashStringHelper*' to 'uint16_t' (Read 5612 times) previous topic - next topic

scswift

Here is the actual file being read:
Code: [Select]

# This file contains parameters you can adjust to change the behavior of the proton pack kit.

powerupDelay 750 # Time to wait before playing the powerup sound and continuing with pack animation. Allows amp time to warm up. (milliseconds)
humFadeTime 300 # Time it takes for hum to fade out completely to conserve battery power. Hum will return to full volume again as soon as any other sound is played. (seconds) 

maxSpeed 10 # Time blast stream needs to be fired continuously to get lights to move at maximum speed and for the pack to overheat. (seconds)
overheatWarning 2 # Time before reaching max speed that you get warning beeps for impending overheat. (seconds)

minPowerDownSoundTime 3 # How long fire button needs to be held to get the short powerdown sound. (seconds)
midPowerDownSoundTime 5 # How long fire button needs to be held to get the medium powerdown sound. (seconds)
maxPowerDownSoundTime 7 # How long fire button needs to be held to get the long powerdown sound. (seconds)

shotgunShotsOverheat 8 # Number of times shotgun must be fired to cause pack to overheat.

SWAP_LEDMODULES 0 # 0 = Default LED module order, 1 = Reverse order of powercell and bargraph LED modules to allow Mighty to be installed in pack.

ENABLE_POWERDOWN 0 # 0 = No powerdown sound on deactivate. 1 = Powerdown sound when deactivate. (pwrdown.wav)

BARGRAPH_STANDBY 1 # Safety ON animaton
BARGRAPH_IDLE 2 # Ready to fire
BARGRAPH_FIRE 3 # Black button - Capture stream
BARGRAPH_ALTFIRE 4 # Red button - Blast stream

POWERCELL_IDLE 1 # Idling animation

# Bargraph animations:
#
# 0 - Off
# 1 - Fill and empty (Default safety)
# 2 - Random fill and empty (Default ready to fire)
# 3 - Ends to center to ends (Default capture stream)
# 4 - Ends to center (Default blast stream)
# 5 - Music mode (Displays current song)
# 6 - Reset (Resets shotgun animation)
# 7 - Ends to center (Default shotgun animation - One shot until reset)
# 8 - Do nothing (For future use)
# 9 - Solid
# 10 - Vent drain (Used when venting - drains quickly)
# 11 - Overheat drain (Used after overheat - drains slowly)
#
# For full movie accuracy, set STANDBY to 9, and IDLE, FIRE, and ALTFIRE to 1. 
# To swap the random fill and normal fill animations, set STANDBY to 2, and IDLE to 1.

# Powercell animations:
#
# 1 - Fill normally, speeding up as pack heats up.
# 2 - Fill halfway, then as pack heats up speed up and increase leds that light.

AWOL

Have you considered using sscanf_P, and forgetting about floating-point altogether?
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

scswift

#47
Oct 01, 2013, 05:05 pm Last Edit: Oct 01, 2013, 05:09 pm by scswift Reason: 1
I need floating point for my end users.  These config files are for them.  And they aren't programmers and would not like dealing with weird values like 4095 for specifying led brightness.






scswift

Well, there's a little good news... while the PACK.CFG file reader is not functioning properly, my LED.CFG file is being read properly now.  Here is the code for that:

Code: [Select]

// LED config scan function.
// index, scale, speed

  int scanLED(char* line, int& i, float& f1, float& f2) {
   
    char result_i[7];
    char result_f1[10];
    char result_f2[10];
   
    if (sscanf(line, " %6s %9s %9s", result_i, result_f1, result_f2) == 3) {
      i = atoi(result_i);
      f1 = atof(result_f1);
      f2 = atof(result_f2);
      return 3;
    }
   
  }

 
void readLEDConfig() {
   
  char line[256]; // Next line of text in file.
  int index = 1, lastIndex;
  float scale = 1.0, lastScale;
  float speed = -1.0, lastSpeed;
 
  if (!file.open(root, "LED.CFG")) { Serial1.println(F("Failed to open LED.CFG!")); halt(7); } // Error if file does not exist.
 
  while (file.fgets(line, sizeof(line))) { // Read lines from the file until we hit the end.
   
    if (line[0] == '#') continue; // Check first character on line.  If comment, skip to next line.
   
    // Store last set of values read from the file before reading new ones:
   
      lastIndex = index;
      lastScale = scale;
      lastSpeed = speed;
   
    if (scanLED(line, index, scale, speed) == 3) { // Scan line.  If all parameters accounted for, store them, then execute code below.
     
      // Loop through all LEDs up to this point and fill them with previously read values.  Do not update the LED we just read parameters for yet.
     
        for (int i = lastIndex; i < index; i++) { // Loop through and set all LEDs up to, but not including, the one we just read from the file.
          led::setscale(i, lastScale);
          led::speed[i-1] = lastSpeed; // LEDs are 1-indexed but LED arrays are 0-indexed so we subtract 1 here. 
        }       
     
    } else {
     
      // Line may be blank, or contain a few whiespace characters.  Or it may be improperly formatted.
     
      //Serial1.println(F("Improperly formatted line in LED.CFG!"));
      //halt(7);
     
    }
 
  }

  for (int i = lastIndex; i <= leds; i++) { // Loop through remaining LEDs and set their values, starting from last one read.
    led::setscale(i, scale);
    led::speed[i-1] = speed;
  }

  // No need to bother closing file if we're not writing to it.
   
}



This tells me fgets is working.  So the issue must be something else.

I notice that your scan functions don't execute a return statement -- something like "return 0;" -- unless they actually find the requested identifier.

According to the standard, what your scan function returns to the caller is undefined without an explicit return statement. (...so it might quite possibly be "not zero", which would cause your parsing loop to continue early. Or it might happen to be zero; then you've gotten lucky.)

scswift

Ah.  That's good to know.  I'll try that.  I just assumed it returned 0.  I'm not sure how that hasn't bitten me before now.

scswift

Michael:

That appears to have been it.  God, I would have been looking for that for hours.  Thanks!

AWOL

Quote
And they aren't programmers and would not like dealing with weird values like 4095 for specifying led brightness

I am a programmer, and would much rather work with values specified in multiples of, say, tenths or hundredths of a percent.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

scswift

One more question...

Why am I getting a compiler error here?

Declaration in class:
Code: [Select]

bool exists(char* name);


Function:
Code: [Select]

bool FatReader::exists(char* name) {
FatReader tmp;
return tmp.open(this, name);
}


Function called:
Code: [Select]

uint8_t FatReader::open(FatReader &dir, char *name) {



The compiler is telling me "no matching function for call to 'FatReader::open(FatReader* const, char*&)'"

Why is there an & on the end there?

I pass a pointer to an array of chars to the function.  'name' is a pointer to type char.  I then pass 'name' along to another function which also takes a pointer to an array of type char as input.  Where's the problem here? 

I don't think I'm supposed to deference the pointer... then I'd be passing the character at the location the pointer points to instead of the address in the pointer.  Right?

Nick Gammon

Can you post enough code for me to reproduce that please? Not just a few lines.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

scswift

It's a ton of code, like a whole fat reader lib.  I gotta get this done tonight and by the time I worked up a sample the forums would be down for hours.  I'll just work around it.

Anyway, I did a quick test and found that what it's really complaining about is the use of "this" there.  For some reason it doesn't want to pass "this" to "uint8_t FatReader::open(FatReader &dir, char *name)".  If I pass it the tmp variable instead which is of type FatReader then it works fine.  Going by the error message it seems to want a const in there for some reason.


Nick Gammon

this is a pointer, FatReader &dir is a reference.

*this probably would have worked.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

scswift

I think I understand what's going on now.

The 'open' method takes it's directory input by reference.  Which would allow it to modify the variable passed to it.   But 'this' cannot be modified.  So the compiler complains.  

scswift


this is a pointer, FatReader &dir is a reference.

*this probably would have worked.


Hm... 

It seems like using a reference there is not the correct way of going about things then?  I guess I'll look up how one would usually pass an object to a function.  I didn't write the WaveHC fat lib, and the SDFat lib works a bit differently and has the open function declared differently which allows it to work without the *.

This is how that lib handles it:
Code: [Select]
bool SdBaseFile::open(SdBaseFile* dirFile, const char* path, uint8_t oflag)

scswift

I just tried your suggestion to dereference 'this' before passing it to the open function (I get what's going on now), and sure enough, it works.  I guess that's solved.  Thanks. :)

Go Up