40 comments
Congratulations to the DS1820toUSB adapter, well done ...
But the rom_search code is buggy; i.e. it doesn't find more than two sensors! |
| mg21 |
03.07.2010 12:27 |
| It's easily possible there is some bug in the scan logic, but you'd need to be a bit more specific. |
| PoempelFox |
14.07.2010 22:58 |
| do you think I can use attiny2313 instead of tiny45? should I alter the client code? do you have any binaries (i'm running macos and I'm afraid it wouldn't be easy for me to compile that host-related code) |
| makakasirapuka |
03.04.2011 22:44 |
An atTiny2313 is not suitable, as it only has 2 KB of flash - the code won't fit into that, at least not without a lot of work.
And I do not plan to make binaries for the hostsoftware available. |
| PoempelFox |
06.04.2011 22:16 |
I asked as there was somewhat tiny15lp on the initial scheme...
btw, did you know that according to datasheet
(http://www.atmel.com/dyn/products/product_parameters.asp?category_id=163&family_id=607&subfamily_id=791&part_id=3618&ListAllAttributes=1)
this attiny45 is equipped with an integrated temp.sensor? |
| makakasirapuka |
07.04.2011 11:15 |
Oh yes, it does. However, according to that datasheet, it is only usable after calibration, and even then only offers an accuracy of roundabout plusminus 10 degrees. In other words, it's useless.
|
| PoempelFox |
07.04.2011 20:19 |
# ./hostsoftware -v status
ERROR: Command 'status' is unknown.
[...]
--- a/ds1820tousb-20100717/hostsoftware.c
+++ b/ds1820tousb-20100717/hostsoftware.c
@@ -575,5 +575,5 @@ int main(int argc, char ** argv)
if (strcmp(argv[curarg], "test") == 0) {
dodevicetest(handle);
- } else if (strcmp(argv[1], "status") == 0) {
+ } else if (strcmp(argv[curarg], "status") == 0) {
dodevicestatus(handle);
} else if (strcmp(argv[curarg], "rescan") == 0) {
|
| johnLate |
08.07.2011 16:52 |
hallo,
ich habe den Code / Firmware auf den atMega8 angepasst und auf die AVR CDC-232 portiert. Quarz=12MHz.
Das gesamte Paket würde ich gerne per e-mail zusenden. bitte sende mir mal deine.
Danke Uwe
|
| de0508 |
28.07.2011 00:11 |
Naja, das ganze auf nen groesseren AVR bringen ist ja eher trivial :)
Mailadresse steht auf der Homepage? Und Modifikationen fuer andere AVRs wuerde ich wohl eher nicht online stellen - aber drauf verlinken.
|
| PoempelFox |
06.08.2011 22:25 |
Hi guys,
how many temperature sensors can be conected to this system ? ? Did anyone try this ?? I need 16 sensors for my school work and I am a big lama, can anyone help me please? Let me know on email pepino.cz@seznam.cz
thanks a lot guys |
| Josef |
05.09.2011 20:02 |
Hi, I am interested in buildind such a Thermometer. Its my first project so maybe some of my questions are dumb.
I managed to compile the software in AVR studio, after that on FreeBSD as on that runs my home GW. I just have some questions as the whole thing does not work for me for some reasons.
I am using ATtiny85, 15Mhz Crystal. After compilation the Eprom file is empty. Is this OK? Programming the dss1820 and .elf file went ok.
If I plug it in my Windwos XP desktop, windows tries to do some stuff but finnaly shows that it may by malfunctioning and is unrecognized. Is this OK? ( maybe yes )
Other thing is, the diods 1N4001 get hot and the DS18B20 gets very hot when pluggen in into USB for cca 5 minutes in my desktop. I dont think its ok, is it?
All components are put tohether in a breadboard and the DS18B20 is just directly put into the breadboard, no wire, first I would like to get it working.
On my BSD the USB ports have no power for some unknown reason, but ist an old laptop from 2004, so maybe just broken.
Could someone please answer the 3 questions so I could move forwards, or reset the whole stuff and do it again (i did it once but ended up the same). Thank you. |
| karol |
29.12.2011 12:32 |
The empty EEPROM is fine. This project doesn't use the EEPROM, but the Makefile is sort of generic, so generates an empty EEPROM file.
I'm not sure what exactly Windows will show when you plug it in, but it is to be expected that Windows will not find a suitable driver for the device - that is not a problem.
However, no component in this circuitry should ever get hot, especially not the DS18B20 - it would be pretty bad if the probe doing the measurement generated so much heat that it would completely spoil any measurement, wouldn't it? If the circuit is working properly, then it uses so little power that the 1N4001 do not create a measurable amount of heat either, even though they are abused as voltage droppers. From the fact that they get hot you can deduce that something in your circuitry is drawing _significantly_ too much power, probably a short-circuit.
As the DS18B20 is also getting hot, my best guess would be that you reverse-poled it, thereby turning it into an expensive short-circuit. For starters, try removing it (the board should also work without a connected probe) and look for other short-circuits. |
| PoempelFox |
04.01.2012 09:41 |
Im an AVR-n00b and wonder if you can specify what firmwarechanges are needed for using 12MHz Crystal instead of 15MHz?
Thank you for any hints you can give me.
|
| nilsht |
08.01.2012 16:35 |
Hallo,
muss ich am ATTiny45 noch Fuses setzen und wenn ja welche?
Benutze aber einen 12MHz Quarz, da der 15er nirgends zu finden war :'(
Die Hostsoftware sagt mir jetzt, dass die Platine nicht ansteuerbar ist. |
| donvipre |
02.02.2012 09:01 |
To answer the last two posts: In theory, it should be fine to just adapt the CPUFREQ definition in the Makefile, then "make clean" and "make" again.
For the german question about how to set the fuses: "make uploadfuses" will tell you what I usually set them to, but in the end you need to verify it with the manual of your particular avr controller, especially if you change things like using another quartz. |
| PoempelFox |
10.02.2012 08:12 |
Hi. I had made this device, it works great. thx/ Truely I fix some in code about frequency of oscillator, manually set the F_CPU.
Now I have two questions:
1. How get access on linux by simple user, i have error like:
"ERROR: Failed to claim ds1820tousb device nr. 1 on the USB: could not claim interface 0: Operation not permitted"
2. Does anybody get it work on Windows system? And how? |
| tester |
17.04.2012 09:01 |
| Hi. I have made this device and it works great with 3 sensors, but it's not possible to get normal work with 4 sensors. I have compiled firmware for 8 sensors (tiny85) and when I connect 4'th sensor I can see full filled list of devices in hostsoftware list (I can see 8 serial numbers, (some duplicate in the list). Does anybody have tried this great device with more then 3 sensors? Maybe the firmware have an error? |
| Mindaugas |
14.11.2012 13:07 |
| would it be possible to buy a chip which is already programmed? For me its no problem to set up the board with the parts but I haven't the stuff (programmer) and the know how to compile the AVR Firmware and send it to the chip. |
| HDFrank |
06.01.2013 22:59 |
To answer the last posts:
@tester: access to the device on linux as a simple user usually involves configuring udev-rules for that, which is a mess I will not get into.
@Mindaugas: yes, there probably is a bug in the code that scans the bus for the sensors, it seems to fail with certain combinations of sensor serial numbers, however that hasn't been debugged yet.
@HDFrank: AVR programming adapters are really really cheap, so that wouldn't make too much sense. I certainly do not plan to offer it. |
| PoempelFox |
10.01.2013 08:29 |
| do you believe it would work under tomatousb/dd-wrt? what drivers do I need there? what are the pid/mid numbers are set there? |
| makakasirapuka |
25.01.2013 22:33 |
| As long as it has libusb (and the hardware has an USB host port) it should work. I do not understand the last part of your question. |
| PoempelFox |
03.03.2013 20:45 |
Ah, I've compiled the host software last month for my mac and for tomato router! It runs okay, however, I haven't tested it yet with the device.
I though that I would need the product ID and manufacturer ID of the device but then I realized I don't need it.
Just drew the board - in sop package, plus I want it to run from 5V with two zenners on data lines, rather than dropping voltage from 5 to 3v with diodes.
Now, the problems: It turns out my local suppliers don't have 15MHz quartz here, ordering it from ebay can take another month, and it seems stupid. I've already flashed the µC with your firmware and it would be quite tricky to reflash it (as it needs external crystal).
What makes things even more complicated is I am not familiar with the windows environment (to recompile the code for 12mHz quartz. When I try to do that in macos I get a bunch of errors, which I am not sure how to deal with... Could you be so kind as to add the 12MHz firmware to the archive? (It seems I'm not alone with this question) |
| makakasirapuka |
09.03.2013 12:05 |
has anyone tried running it from 12MHz crystal? Any success?
Yesterday I set up my virtual windows environment, changed the makefile to attiny85 and 12mhz instead of 15, did 'make' and uploaded the hex file to the µC.
my computer now says:
USBF: 1502185.632 [0xffffff800b263200] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 1 of Hub at 0x1d000000)
USBF: 1502188.809 [0xffffff800b263200] The IOUSBFamily was not able to enumerate a device.
is it the firmware-related problem, or electrical one? |
| makakasirapuka |
10.03.2013 11:29 |
Hi, congrats to the complete and a very neat project.
I was wondering, is there a reason for using the crystal? Crystal is not needed for V-USB (i think), to the only reason would be the OneWire code. Is the OneWire done by bitbanging? Sorry for novice questions. |
| maco |
10.03.2013 20:40 |
the further I go, the more questions I get. sorry for bothering.
should it be working without the sensors connected?
why does it need BOD fuse?
I built the scheme with zeners and recompiled the code for 12MHz crystal, but it seems the scheme just restarts each two seconds... |
| makakasirapuka |
15.03.2013 02:08 |
To answer the recent posts:
@makakasirapuka: I will not add a 12 MHz firmware to the archive as I would be unable to test it in any way.
@makakasirapuka: There is no way to tell from the USB errors whether the problem is electrical or firmware.
@maco: There are two reasons for the crystal: At the time I did this, V-USBs support for using the AVRs internal clock still seemed very experimental, so I did not want to try it. I also know from experience that the AVRs internal clock is EXTREMELY unstable even when calibrated, and both the onewire bus and the USB are quite timing sensitive, so a more stable clocksource is certainly a good idea.
@makakasirapuka: The BOD fuse prevents the controller from running with severe undervoltage, which would lead to completely unpredictable behaviour of the chip. If it restarts every two seconds, then that is probably not the brownout, but the watchdog timer, as that is set to two seconds (see main.c). If that triggers it means it didn't execute the main loop a single time in two seconds, meaning it got stuck somewhere. I can't tell you out of the top of my head whether it works without any sensors connected - it might well get stuck because there are no sensors at all.
|
| PoempelFox |
16.03.2013 23:42 |
Hi, I have some questions:
1) is possible to re-program programmed attiny85 with this fw? I have programed two and I can' t re-program them after setting fuses lfuse:w:0xff:m
hfuse:w:0xdd:m
efuse:w:0xff:m
my wish is to re-compile fw with support for more than 4 probes and program these tinnys one more time
2) is possible to re-program "dead" attiny85, after setting only one fuse lfuse:w:0xff:m (fuses must be set all at one time!!!, I have try to set one by one and now is tiny dead and does not respond after first lfuse - is locked like at point 1, but at point one I have set all fuses at once and ds18tousb works)
3) how to debug fw for these tinnys? I wish to play with it, but thanks point 1 and 2 I'd rather not to damage more tinnys...
4) where to set support for more than 4 probes? In ds1820.h? And just #define DS1820_MAXPROBES 8? Thats all?
5) What I need to change, when I move to 12MHz Crystal? "...just adapt the CPUFREQ definition in the Makefile..." this means just change CPUFREQ = 15000000UL to CPUFREQ = 12000000UL? And fuses? What to set?
http://www.engbedded.com/fusecalc/
6) find someone similar project for AM2302 (AM2302 (wired DHT22) temperature-humidity sensor)? I realy need am2302tousb... searching searching and nothing :(
7) Is on new hostsoftware 1.14 fixed searching more than 2 probes?
My errors:
1) diodes and temperature probe gets hot, device not recognized - I have reverse polarity on the probe... after reversing probe works very good!
2) device not recognized on system - bad fw on chip or fuses are not set
3) when everything works and no probe is connected, system recognizes ds1820tousb very well, hostsoftware finds ds1820tousb, but while probing returns only zeros (serial and temperature)
Thanks for your great project and time :) |
| Radius |
19.04.2013 15:14 |
To answer the last post: I'm not sure if I'm following you.
Yes, it is possible to use this firmware with an attiny85 if you properly compile the firmware for it (set chiptype in Makefile) - which you need to do anyways to increase the number of probes allowed. For most fundamental changes you will need to make sure the firmware is fully recompiled - i.e. do a "make clean ; make" not just a make.
In general, it is usually always possible to reprogram a "dead" attiny - although you will usually need to take it out of the circuit and put it into a proper programmer instead (no ISP).
I cannot provide you with personal experience of debugging these except the usual "toggle some of the output lines to signal stuff to the outside" - please ask the internet search engine of your choice about the debugging features like "debugwire" these chips have.
For more probes, you just need to change the define in ds1820.h. Do not set the number of probes too high - if the attiny runs out of memory because you set it too high, it will usually crash silently.
If you still use a crystal and not the internal osc., the only thing you should need to change is the CPUFREQ define. The fuses should not need adaption.
I do not know of a similar project for AM2302.
There is no general problem with more than 2 probes, it can work - it depends on the serials of the probes you have. That bug however is not fixed yet, as still nobody has provided me with the bare minimum to debug it: The serials of probes which cause the bug when used together.
|
| PoempelFox |
19.04.2013 20:36 |
Sorry, you' re follow me not... my bad english.
My situation is, I have working 3 ds18b20 (yes I make it :)) with attiny85, but while doing things to work, I have block one attiny85 (set only one fuse - lfuse:w:0xff:m). And my question is, is possible to unlock him and program one more time corectly? That was point 1 and 2/my question 1 and 2. Your answer is - "...proper programmer instead (no ISP)..." - I have http://www.fischl.de/usbasp/ usbasp programmer, this will not work? Can you please post link to ebay for proper programmer (or programing with serial port will work???)?
3) very thanks
4) very thanks
5) so just change CPUFREQ = 15000000UL (for 15MHz crystal) to CPUFREQ = 12000000UL (for 12MHz Crystal) and nothing more? Seems easy...
6) very thanks
7) the problem is in hostsoftware or in fw? I will try to post serials of probes.
New question:
Who is maintaining this?
http://git.informatik.uni-erlangen.de/?p=ds1820tousb/.git;a=blob;f=hostsoftware.c;hb=HEAD
There is new version of hostsoftware 1.14 and you have on your project 1.12. When I have little time, I will look for differences.
Very thanks for your time and patience. |
| Radius |
24.04.2013 23:15 |
You probably do not really need a different programmer, the usual problem with bricking an avr is that due to messed up clock configuration in the fuse bits it is expecting an external cpu clocking that just isn't there - provide it (depends on what you set the fuses to of course) somehow externally, and you can reprogram it again. Only in very rare cases can you mess up the fuse bits so badly there is only one way out: High Voltage Programming which requires a pretty expensive programmer then. In general, google for "unbrick avr" - there are a gazillion ways to try.
The bug with multiple probes is definitely in the firmware, in the code that detects the probes attached. There is a documented algorithm for that, and implementing it on the attiny is a PITA due to the limited memory, which is why the code that is currently there is a big mess.
The gitweb repository you mention is mine of course - I linked to it in the previous comments, didn't you see? |
| PoempelFox |
25.04.2013 08:18 |
Bug:
used probes:
28 000004925723
28 000004927afb
28 00000492a93d
result:
28 00000492a93d
28 000004925723
28 00000492a93d
28 00000492a93d
used probes:
28 00000491d3bd
28 000004927afb
28 000004925723
result:
28 00000491d3bd
28 000004925723
28 00000491d3bd
28 000004925723
used probes:
28 000004925723
28 000004927afb
28 0000049318a7
result:
works
used probes:
28 000004925723
28 000004927afb
28 000004923eec
result:
28 000004923eec
28 000004925723
28 000004923eec
28 000004925723
used probes:
28 000004925723
28 00000492a93d
28 00000491d3bd
result:
works
used probes:
28 000004925723
28 00000492a93d
28 00000491d3bd
28 000004927afb
result:
28 00000492a93d U 72 208 85.00
28 00000491d3bd U 133 147 28.19
28 000004925723 U 194 86 28.31
28 00000491d3bd U 255 25 28.19
used probes:
28 000004925723
28 00000492a93d
28 00000491d3bd
28 000004923eec
result:
28 000004923eec
28 00000492a93d
28 000004923eec
28 000004923eec
used probes:
28 00000492a93d
28 00000491d3bd
28 000004925723
28 0000049318a7
result:
28 00000492a93d
28 00000491d3bd
28 000004925723
28 00000492a93d
used probes:
28 00000492a93d
28 00000491d3bd
28 000004925723
28 000004927afb
result:
28 00000492a93d
28 00000491d3bd
28 000004925723
28 00000491d3bd
On one result, there is bug in temp, sometimes shows with 3 temps too.
2 probes works perfectly everytime, four seems to not work everytime.
And seems that i have found another maybe bug... I will try to inspect it more.
Thanks for your time.
R. |
| Radius |
28.04.2013 19:11 |
thank you for this helpful report, I will be looking into it.
Update 2013-07-20: I wrote a simulator now, so I can reproduce what the scan routine does. It does indeed reproduce that the scan routine goes into an endless loop with certain combinations of serials.
Update 2013-07-21: I have improved the scan function now, and I hope that the problem is fixed now. Unfortunately I don't currently have a piece of hardware to test it outside of the simulator. If you want to test, compile a current snapshot of ds1820tousb.
|
| PoempelFox |
12.05.2013 08:50 |
I have compiled and tested new software version. It seems that program is working correctly.
I have made some tests with 3, 4, 5, 6, 7 and 8 probes.
We can wait another testers opinion.
Thanks |
| Mindaugas |
27.07.2013 20:58 |
Hi, very thanks. Seems it is working well with 6 probes. But I have one little question. I have made 5V design and he is working some minutes and after random time it will crash with error:
Windows XP
ERROR: USB error: cygusb0-dll:err [_usb_reap_async] reaping request failed, win error: Zařízení připojené k systému nefunguje.
Translated error:
ERROR: USB error: cygusb0-dll:err [_usb_reap_async] reaping request failed, win error: A device attached to the system is not working.
Linux Mint Debian Edition:
ERROR: invalid interrupt message received from device (0 bytes instead of 8) - continuing
ERROR: USB error: No error
Using Windows XP (testing virtual), compiled with gcc and cygwin.
Using Linux Mint Debian Edition (Debian 8 testing), compiled with gcc.
Runing with command showint.
Schematics:
download vusb and under vusb-20121206.zip\vusb-20121206\circuits\with-zener.png
Only main difference is, that whole design is using 5V from USB and only data pins are lowered with diodes.
I don' t know where is problem, soldering, bad parts or just firmware? Maybe more problems? Any ideas?
And one more time very, very thanks for very good job on probes:) and for your time. |
| Radius |
09.10.2013 22:17 |
Hi,
Sorry for my latest post - I've already sort it out. I seems that it was bug in soft (I used some old version from github).
Now I'm facing another issue:
root@debian:/ds1820tousb# ./hostsoftware status
Device Version is 00.01
Device time is currently timestamp 13625
4 probes supported by device
fa serial fl lastseen ticksago lastvalue
10 000802aaab23 U 13483 142 3.75
10 000802aaad1b U 13544 81 3.06
00 000000000000 0 13625 0.00
00 000000000000 0 13625 0.00
temperature should show something about 30 C. Why it is showing 3.06 ? |
| bengbu |
15.12.2013 10:44 |
Because you're apparently using the wrong sensor type. The "10" in the family column suggests its a DS18S20, the cheaper variant of the DS18B20 that has the resolution hardwired to 9 bit (0.5 degrees). To make this work you will need to adjust how the hostsoftware interprets the values from the sensor - in particular, you will at least need to change the line in hostsoftware.c that reads
res = (double)t2 * 0.0625L;
to
res = (double)t2 * 0.5000L;
That should give more realistic values.
BTW: The proper sensors (DS18B20) should have a "family" value of "28". |
| PoempelFox |
17.12.2013 07:11 |
You were right! I changed sesnor to ds18b20 and it worked just as it should.
You rock, poempelfox! |
| bengbu |
17.12.2013 22:00 |
Hi, I have question, which software are you using for developing the firmware? AVR Studio?
Radius |
| Radius |
25.01.2014 20:50 |
| I was trying to connect a DS18(S)20 to linux as well. There are solutions without Atmel microcontroller but I've got an even simpler solution to work: I connected RX+TX of a USB-to-serial (CH341) via 220 Ohm resistor to the sensor middle and ground to the two side pins (parasitic mode). digitemp_DS9097 reads it well on a breadboard ... |
| GMA |
27.04.2016 19:32 |
write a new comment:
|