I download Arduino IDE 1.0.5 and I have unzipped your zip under the llbraries folder.
I typed a sketch like this:
#include <DS1621.h>
void setup() {
// put your setup code here, to run once:
}
void loop() {
// put your main code here, to run repeatedly:
}
then I receive the following errors:
In file included from test.ino:1:
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:10: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:13: error: expected `)' before ‘i2c_addr’
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:16: error: ‘uint8_t’ has not been declared
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:19: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:24: error: ‘uint8_t’ has not been declared
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:32: error: ‘uint8_t’ has not been declared
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:41: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:42: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:43: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:44: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:45: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:46: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:47: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:48: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:51: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:52: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:53: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:54: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:55: error: ‘uint8_t’ does not name a type
/arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:56: error: ‘uint8_t’ does not name a type
It looks like the library was added correctly. The issue as you may have guessed stems from the use of the uint8_t data type in the library itself. The uint8_t data type is often used in C, but it is not part of the core standard and is not treated by Arduino as a data type. Fortunately, a uint8_t is just a char.
The code should have a typedef that defines a uint8_t as a char, but I don't see one. That said, when I tried to add one it would not let me as it said there already was one. So I just used #define to replace all instances of "uint8_t" with "char." This cleared the uint8_t errors for me, though other errors also existed, but I don't see any of them on your printout, so maybe you will be good to go.
So in summary to clear these errors, open up DS1621.h and insert the l following line at the top of the file.
I would not recommend doing what jroorda has recommended for several reasons.
Most importantly , a uint8_t is not a char.
In C there are 3 character data types:
char
unsigned char
signed char
They are distinct and different and have small subtle differences beyond
just their signedness.
Complicating matters further the signedness of "char" is implementation dependent,
i.e. the implmentor can at his whim make them signed or unsigned.
So given that uint8_t is specifically asking for a unsigned 8 bit value, then using a char is highly not
not recommended.
All the standard types are in <stdint.h>
In this particular case, the file DS1621.h should have included it but since
it included <Wire.h> it was included for it by <Wire.h>
While adding a #include <stdint.h> to DS1621.h would solve the current
issue you are seeing, that really isn't the only problem and so adding it really isn't necessary.
The Arduino IDE sketch build methodology uses the includes it "sees" in the user's sketch to
determine what libraries need to be built and linked into the final image.
In this case the DS1621 library uses and needs the Wire library.
Libraries using other libraries in Arduino kind of sucks because of the way
the Arduino build methodology works. i.e. There is no way for a library to
indicate that it needs/uses another library.
Therefore, the sketch must include a header file from the sub library to tell
the IDE that a library is used/needed.
Long story short, you need to add:
#include <Wire.h>
to your sketch above the include for the DS1621 library.
That will not only end up including the neaded <stdint.h> for you which will clear
up the uint8_t errors, but will also tell the IDE to build and link in the Wire
library which is needed by the DS1621 library.
In fact you will see that include if you look at their DS1621 example.
Hello thank you both for your answer.
Unfortunately my problem is not solved.
Before I post the code in my original post I tried the example and here are the results of the verify:
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:1:22: error: WProgram.h: No such file or directory
In file included from /arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:2:
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:10: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:13: error: expected `)' before ‘i2c_addr’
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:16: error: ‘uint8_t’ has not been declared
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:19: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:24: error: ‘uint8_t’ has not been declared
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:32: error: ‘uint8_t’ has not been declared
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:41: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:42: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:43: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:44: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:45: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:46: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:47: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:48: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:51: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:52: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:53: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:54: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:55: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:56: error: ‘uint8_t’ does not name a type
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:8: error: prototype for ‘DS1621::DS1621(uint8_t)’ does not match any in class ‘DS1621’
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:9: error: candidates are: DS1621::DS1621(const DS1621&)
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:9: error: DS1621::DS1621()
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:20: error: prototype for ‘void DS1621::setConfig(uint8_t)’ does not match any in class ‘DS1621’
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:16: error: candidate is: void DS1621::setConfig(int)
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:32: error: no ‘uint8_t DS1621::getReg(uint8_t)’ member function declared in class ‘DS1621’
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:47: error: prototype for ‘void DS1621::setThresh(uint8_t, int)’ does not match any in class ‘DS1621’
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:24: error: candidate is: void DS1621::setThresh(int, int)
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp: In member function ‘void DS1621::startConversion(bool)’:
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:64: error: ‘addr’ was not declared in this scope
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:66: error: ‘class TwoWire’ has no member named ‘send’
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:66: error: ‘START_CNV’ was not declared in this scope
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:68: error: ‘class TwoWire’ has no member named ‘send’
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:68: error: ‘STOP_CNV’ was not declared in this scope
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp: At global scope:
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:77: error: prototype for ‘int DS1621::getTemp(uint8_t)’ does not match any in class ‘DS1621’
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.h:32: error: candidate is: int DS1621::getTemp(int)
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp: In member function ‘int DS1621::getHrTemp()’:
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:103: error: ‘DONE’ was not declared in this scope
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:104: error: ‘ACCESS_CFG’ was not declared in this scope
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:104: error: ‘getReg’ was not declared in this scope
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:107: error: ‘RD_TEMP’ was not declared in this scope
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:108: error: ‘RD_CNTR’ was not declared in this scope
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:108: error: ‘getReg’ was not declared in this scope
arduino1.5Lib/arduino-1.0.5/libraries/DallasTM/DS1621.cpp:109: error: ‘RD_SLOPE’ was not declared in this scope
I tried to include the Wire.h library as well but the results were the same.
Are you able to compile the DS1621 sample at your machine?
I think that it must be something basic/configuration with the inclusion of the external library.
How it was possible otherwise for the writer of the github project DS 1621 to compile and run the code?
I do not think that the problem is at the source code.
Maybe the version of the IDE/compiler or another configuration option?
That is a different issue.
You can thank the wonderful Arduino team for this issue.
When they went from the final 1.0 release candidate to the official 1.0 release
they decided to make some changes to the some of the APIs.
(That is VERY bad s/w development practice, and normally is just not done)
They further decided that it was a good idea to speed up the adoption of their changes
by removing the old APIs which would break 100% of all the existing Arduino libraries.
The idea was that since it would break the libraries, that the authors would be quicker
to adopt their new APIs since it would be required to get them to work again.
The saddest part is that this was totally uncessary, and they could have left in
the old APIs or mapped them to the new APIs and 99% of the libraries would have continued to work.
(a few of the APIs are different enough that they can't be mapped - but that is a small minority)
They knew this and still moved forward with their plan.
Nice guys huh....
And now a few years later there are still library issues because of their decision.
So what you have is a library that was written for the Wire library before they
changed it in the 1.0 release.
The fixes are not difficult because they changed the names of certain functions and a header file
but you will have to make the changes to the library.
you solved it!
Is this documented somewhere officailly?
I have to say that I faced the same issue some months ago with a hardware part that I bought online.
Since then basically I left it like that since I could not find a solution.
The interesting part is that the owner of the shop could not find the problem although it was the same issue with the current.
Interesting that a proffesional (owner of a shop that was distributing Arduinos) was not aware of this (or simply didn't care enough).
Many thanks from me!!!
Is there something that I can do in order to accept your answer as the answer?
I cannot find something similar as in StackOverflow for example.
In terms of "official" accurate & complete documenation. Not really.
There were many, sometimes heated, discussions over it on the forums
during the first few months when it happened about 2 years ago.
Noticeably absent from most of the discussions was the Arduino team itself.
The more popular and better maintained libraries have been updated
but issues still keep coming up periodically.
And guess, what? The Arduino team were talking about breaking everything again
in the 1.5 release. As of now I think they have finally seen the light.
After several heated discussions in the google forums, it appears
that they have backed away from that "don't look back" mindset and
are re-grouping their direction.
The i2c (Wire library) is a good example of a library that could have been made to work
with pre 1.x sketches and other libraries as well as with the new API functions and headers.
In fact if you use the Teensy products: http://www.pjrc.com/teensy/
Pauls teensyduino, IDE addon, goes in and modifies the Arduino teams IDE
files to make it work with the older libraries. (but only when using his boards).
He wanted the Arduino team to adopt the updates so it would work for everyone
but they continually rejected it.
With respect to the actual 1.0 changes,
you can see some of it burried down in the release notes.
About the closest thing to documenation was a blog entry from dave mellis:
What he didn't mention in his blog was that 100% of the 3rd party Arduino libraries
would no longer compile.
Overall 1.0 transition was handled poorly,
and it resulted in quite a bit of instability, particuarly in the first few months.
Some of the resulting issues, as you have just experience still exist today.
Amazing if you think of the adoption that Arduino already has in the market.
I think they underestimated the already existing libraries and the effort for the transition.
In addition the error messages of course are misleading.
The error messages are strange and potentially confusing because they are being
generated from missing header files and therefore can be inconsistent between pre 1.x libraries.
The disapointing part is that another one of the things that they could have done and chose not to do
would have been to provide a dummy "WProgram.h" header file that could
be used to terminate the compiler with a specific error message.
(WProgram.h is no longer used in Arduino 1.x so any code that includes it is pre 1.x code)
That could be used to cause any pre 1.x code to break with a controlled predictable error message
stating that it was a pre 1.x library that needed to be updated rather than just let the compiler
wander off and generate strange errors based on missing header files.
From their perspective, backward compatibility didn't matter and that is why until recently
they didn't understand what all the fuss was about.
In their case, they release the IDE and all their supplied libraries all at once
and everything all worked together/
The Arduino team never had to go back and visit or support an older version of the IDE.
It was the 3rd party library and core guys that got squeezed since
they had to support a user based that was not all using the same version of the IDE.
Finally after some lengthy discussions on the new 1.5 library format, the light bulb
went on and they realized how different things are for them vs the 3rd party s/w developers.
If you want you could create this file:
{installdir}/hardware/arduino/cores/arduino/WProgram.h
#error "Attempting to use Pre 1.x Arduino code in 1.x Arduino"
Just create the .h file down in the Arduino core directory with that single line in it.
You can change the error message to anything you would rather see.
That way if you ever have a pre 1.x library again,
you will get this error message unstead of long string of strange errors.
(You might still get other errors, but at least you will see this message as well)