I have the DHT11 temperature sensor and I am trying convert the humidity into a number I can use in compare statments.
If I use:
Serial.print("Humidity (%): ");
Serial.println((int)DHT11.humidity, DEC);
//Prints: 38 for the humidity
However if I use
int tempHum;
tempHum = ((int)DHT11.humidity, DEC);
Serial.print("Humidity (%): ");
Serial.println(tempHum);
//Always Prints: 10
How can I make the humidity into an accurate number other than the serial?
Next time you're posting, please add a link to the library you're using - that way we're sure to talk about the same. You haven't posted all of your code, but looking at this, it seems to me, that this line tempHum = ((int)DHT11.humidity, DEC); is cause your problems.
If you try to use tempHum = DHT11.humidity instead, you might have better results. This is because the cast you're doing and adding the DEC parameter seems to be to the println function, so that the underlying system knows which type it should print.
Of course you all need to remember to do a int retval = DHT11.read(DHT11PIN) and check on your retval that nothing went wrong - this should make it work.
Related
I am currently building an app to teach myself Swift so am still very new. I’ve encountered a problem. The app is a timetable creator. I have up to twelve subjects that all have points. These points are then spread across days. I have a concept for code that will allocate the points fine using loops but wondered whether there was something to reduce the amount of code rather than, what I currently have, something like this for each subject:
subject1.monpts = 20
subject1.tuepts = 20
subject1.wedpts = 20
subject1.thurpts = 20
subject1.fripts = 20
subject1.satpts = 20
subject1.sunpts = 20
This, x12, is a lot of code. But I need it so that each subject has an option for points for each day of the week (which the app will then allocate time based on these points). To print the timetable, I am putting each subjectX.daypts together but this means I’m writing out 12 subjects for each day.
I also need to only display something if the variable actually has a value. I plan to do this using if statements but that means writing a statement for every single variable which at the moment is 12 x 7 = 48! E.g. (ignore the formating - just for concept)
if subjects1.monpts = 0 {
subjects1monLabel = isHidden.false
// or just a print / don't print statement
}
I feel as if I'm missing an easier way to do this!
Here is a picture that explains the concept a bit better:
If you want to save information about those fields you can have a dictionary with keys of a enum and values of ints like so:
enum WeekDay: CaseIterable {
case monday, tuesday, wednesday, thursday, friday, saturday, sunday
}
struct Subject {
var pointsForWeekDay: [WeekDay: Int]
}
Now you could do:
var pointsForWeekDay = Dictionary(uniqueKeysWithValues:
WeekDay.allCases.map { weekDay in
return (weekDay, 20)
}
)
var subject = Subject(pointsForWeekDay: pointsForWeekDay)
CaseIterable allows you to access all values of your enum.
Map takes every weekDay and creates an array of tuples with your Int values.
And finally you can combine that to have a complete Dictionary with uniqueKeysWithValues initializer, which takes an array of the produced tuples.
Your whole vision of how to organize this material is upside down. Start by thinking about what all your subjects have in common: points for each of the seven days, label hidden for each of the seven days, and so forth. Now incorporate that into a type (a struct): Subject. Now instead of subjects1..., subjects2... and so forth, you have an Array of Subject.
So: any time you have variables named with a number, that should be an array instead. Any time you have clumps of repeated concepts, that should be a type instead.
Even the notion of the seven days of the week could itself be condensed in the same way. If all we're talking about is points per day, an array of seven numbers would do.
So we'd end up with a skeleton like this:
struct Subject {
var dayPoints : [Int]
}
var myTwelveSubjects : [Subject]
...and you can build that out as more requirements come online, such as whether a day is hidden.
I need time since Epoch in ms for an API request, so I'm looking to have a function that converts my myUIDatePicker.date.timeIntervalSince1970 into milliseconds by multiplying by 1000. My question is what should the return value be?
Right now I have
func setTimeSinceEpoch(datePicker: UIDatePicker) -> Int {
return Int(datePicker.date.timeIntervalSince1970 * 1000)
}
Will this cause any issues? I need an integer, not a floating point, but will I have issues with overflow? I tested it out with print statements and it seems to work but I want to find the best way of doing this.
Looking at Apple Docs:
var NSTimeIntervalSince1970: Double { get }
There is a nice function called distantFuture. Even if you use this date in you func the result will be smaller then the max Int.
let future = NSDate.distantFuture() // "Jan 1, 4001, 12:00 AM"
print((Int(future.timeIntervalSince1970) * 1000) < Int.max) // true
So, until 4001 you're good to go. It will work perfectly on 64-bits systems.
Note: If your system supports iPhone 5 (32-bits) it's going to get an error on pretty much any date you use. Int in Iphone 5 corresponds to Int32.
Returning an Int64 is a better approach. See this.
I have an if statement that is meant to check a float that increases over time (It's a timer) the current code is this
if (Day.DateTime == 1080){
ClientsTaken = Random.Range(MinNoOfClients, MaxNoOfClients);
GameObject.Find("Canvas").GetComponent(Brothel).Money += (ClientsTaken *(Cost * GirlMorale));
ClientsSeen += ClientsTaken;
Debug.Log("Clients taken = " + ClientsTaken);
}
The timer is definatly hitting 1080 but nothing is happening. I also tried 1080f but had the same result.
Any help would be greatly appreciated, thanks.
Comparing floating point variables this way is not recommended due to "floating point imprecision" - the way the floating point variables are internally stored on PC.
Instead, you can use Mathf.Approximately(), like this:
if (Mathf.Approximately(Day.DateTime, 1080.0))
{
...
{
I would change the check to Day.DateTime >= 1080. When dealing with floating point numbers you may not land directly on an integer value.
I need to load values from uint8 array into 128 NEON register. There is a similar question. But there were no good answers.
My solution is:
uint8_t arr[4] = {1,2,3,4};
//load 4 of 8-bit vals into 64 bit reg
uint8x8_t _vld1_u8 = vld1_u8(arr);
//convert to 16-bit and move to 128-bit reg
uint16x8_t _vmovl_u8 = vmovl_u8(_vld1_u8);
//get low 64 bit and move them to 64-bit reg
uint16x4_t _vget_low_u16 = vget_low_u16(_vmovl_u8);
//convert to 32-bit and move to 128-bit reg
uint32x4_t ld32x4 = vmovl_u16(_vget_low_u16);
This works fine, but it seems to me that this approach is not the fastest. Maybe there is a better and faster way to load 8bit data into 128 reg as 32bit ?
Edit:
Thanks to #FrankH. I've came up with the second version using some hack:
uint8x16x2_t z = vzipq_u8(vld1q_u8(arr), q_zero);
uint8x16_t rr = *(uint8x16_t*)&z;
z = vzipq_u8(rr, q_zero);
ld32x4 = *(uint8x16_t*)&z;
It boils down to this assembly (when compiler optimisations are on):
vld1.8 {d16, d17}, [r5]
vzip.8 q8, q9
vorr q9, q4, q4
vzip.8 q8, q9
So there are no redundant stores and it's pretty fast. But still it is about x1.5 slower then the first solution.
You can do a "double zip" with zeroes:
uint16x4_t zero = 0;
uint32x4_t ld32x4 =
vreinterpretq_u32_u16(
vzipq_u8(
vzip_u8(
vld1_u8(arr),
vreinterpret_u8_u16(zero)
),
zero
)
);
Since the vreinterpretq_*() are no-ops, this boils down to three instructions. Don't have a crosscompiler around at the moment, can't validate that :(
Edit:
Don't get me wrong there ... while vreinterpretq_*() isn't resulting in a Neon instruction, it's not a no-op; that's because it stops the compiler from doing the type of funky things you'd see if you'd instead use widerVal.val[0]. All it tells the compiler is, like:
"you've got a uint8x16x2_t but I want to use only half of that as a uint8x16_t, give me half the registers."
Or:
"you have a uint8x16x2_t but I want to use those regs as a uint32x4_t instead."
I.e. it tells the compilers to alias sets of neon registers - preventing stores/loads to/from the stack as you'd get if you do the explicit sub-set access through the .val[...] syntax.
In a way, the .val[...] syntax "is a hack" but the better method, the use of vreinterpretq_*(), "looks like a hack". Not using it results in more instructions and slower/inferior code.
I have some code to convert a time value returned from QueryPerformanceCounter to a double value in milliseconds, as this is more convenient to count with.
The function looks like this:
double timeGetExactTime() {
LARGE_INTEGER timerPerformanceCounter, timerPerformanceFrequency;
QueryPerformanceCounter(&timerPerformanceCounter);
if (QueryPerformanceFrequency(&timerPerformanceFrequency)) {
return (double)timerPerformanceCounter.QuadPart / (((double)timerPerformanceFrequency.QuadPart) / 1000.0);
}
return 0.0;
}
The problem I'm having recently (I don't think I had this problem before, and no changes have been made to the code) is that the result is not very accurate. The result does not contain any decimals, but it is even less accurate than 1 millisecond.
When I enter the expression in the debugger, the result is as accurate as I would expect.
I understand that a double cannot hold the accuracy of a 64-bit integer, but at this time, the PerformanceCounter only required 46 bits (and a double should be able to store 52 bits without loss)
Furthermore it seems odd that the debugger would use a different format to do the division.
Here are some results I got. The program was compiled in Debug mode, Floating Point mode in C++ options was set to the default ( Precise (/fp:precise) )
timerPerformanceCounter.QuadPart: 30270310439445
timerPerformanceFrequency.QuadPart: 14318180
double perfCounter = (double)timerPerformanceCounter.QuadPart;
30270310439445.000
double perfFrequency = (((double)timerPerformanceFrequency.QuadPart) / 1000.0);
14318.179687500000
double result = perfCounter / perfFrequency;
2114117248.0000000
return (double)timerPerformanceCounter.QuadPart / (((double)timerPerformanceFrequency.QuadPart) / 1000.0);
2114117248.0000000
Result with same expression in debugger:
2114117188.0396111
Result of perfTimerCount / perfTimerFreq in debugger:
2114117234.1810646
Result of 30270310439445 / 14318180 in calculator:
2114117188.0396111796331656677036
Does anyone know why the accuracy is different in the debugger's Watch compared to the result in my program?
Update: I tried deducting 30270310439445 from timerPerformanceCounter.QuadPart before doing the conversion and division, and it does appear to be accurate in all cases now.
Maybe the reason why I'm only seeing this behavior now might be because my computer's uptime is now 16 days, so the value is larger than I'm used to?
So it does appear to be a division accuracy issue with large numbers, but that still doesn't explain why the division was still correct in the Watch window.
Does it use a higher-precision type than double for it's results?
Adion,
If you don't mind the performance hit, cast your QuadPart numbers to decimal instead of double before performing the division. Then cast the resulting number back to double.
You are correct about the size of the numbers. It throws off the accuracy of the floating point calculations.
For more about this than you probably ever wanted to know, see:
What Every Computer Scientist Should Know About Floating-Point Arithmetic
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thanks, using decimal would probably be a solution too.
For now I've taken a slightly different approach, which also works well, at least as long as my program doesn't run longer than a week or so without restarting.
I just remember the performance counter of when my program started, and subtract this from the current counter before converting to double and doing the division.
I'm not sure which solution would be fastest, I guess I'd have to benchmark that first.
bool perfTimerInitialized = false;
double timerPerformanceFrequencyDbl;
LARGE_INTEGER timerPerformanceFrequency;
LARGE_INTEGER timerPerformanceCounterStart;
double timeGetExactTime()
{
if (!perfTimerInitialized) {
QueryPerformanceFrequency(&timerPerformanceFrequency);
timerPerformanceFrequencyDbl = ((double)timerPerformanceFrequency.QuadPart) / 1000.0;
QueryPerformanceCounter(&timerPerformanceCounterStart);
perfTimerInitialized = true;
}
LARGE_INTEGER timerPerformanceCounter;
if (QueryPerformanceCounter(&timerPerformanceCounter)) {
timerPerformanceCounter.QuadPart -= timerPerformanceCounterStart.QuadPart;
return ((double)timerPerformanceCounter.QuadPart) / timerPerformanceFrequencyDbl;
}
return (double)timeGetTime();
}