Hello, I have just connected a DS2438, which seems to be reporting a A6 family code, and thus not giving the correct input details. w1_master_driver w1_bus_master1: Family a6 for a6.5000009b8f5f.f6 is not registered. On owfs 3.1p1 Regards John ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
Am 29.11.2016 um 18:29 schrieb John Bass:
> > I have just connected a DS2438, which seems to be reporting a A6 family code, and thus not giving the correct input details. > w1_master_driver w1_bus_master1: Family a6 for a6.5000009b8f5f.f6 is not registered. > This is a message from the kernel driver. It means: there is no kernel driver for the DS2438 loaded. Which is quite true, as such a driver does not exist yet. > On owfs 3.1p1 > Uh, no. You are looking at the wrong thing. The w1 subsystem has two parts. One is the host adaptor code, which owfs happily use when started with --w1. On top of this, owfs implements its own userspace driver code for all the slave chips it supports. So if something fails with a slave chip, you have to look for another error which doesn't come from the kernel driver. (The other part of the w1 subsystem is the slave code which owfs doesn't use at all. You can use it in parallel to owfs when there is a kernel driver for the slave chip existing.) Kind regards Jan ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
Hello Jan,
Had a good look, no other errors. I have tried to run owserver in debug mode, Here is some of the debug output, I think this is the area you might need... is it that I need to add the family code (A6) to the 2438 family list in some way DEBUG: ow_w1_parse.c:(249) About to call nrs_callback DEBUG: ow_w1_parse.c:(251) Called nrs_callback DEBUG: ow_w1.c:(196) SN found: A6 5F 8F 9B 00 00 50 F6 DEBUG: ow_search.c:(74) Device found: A6 5F 8F 9B 00 00 50 F6 DEBUG: ow_cache.c:(546) Adding device location A6 5F 8F 9B 00 00 50 F6 bus=1 DEBUG: ow_cache.c:(635) Add to cache sn A6 5F 8F 9B 00 00 50 F6 pointer=0xb6eb0950 index=0 size=4 DEBUG: ow_cache.c:(546) Adding device location A6 5F 8F 9B 00 00 50 F6 bus=1 DEBUG: ow_cache.c:(635) Add to cache sn A6 5F 8F 9B 00 00 50 F6 pointer=0xb6eb0950 index=0 size=4 CALL: ow_parsename.c:(104) path=[/A6.5F8F9B000050] DEBUG: ow_regex.c:(74) Reg Ex expression <^bus\.([[:digit:]]+)/?> compiled to 0xb6eb0560 DEBUG: ow_regex.c:(74) Reg Ex expression <^settings/?> compiled to 0xb6eb0580 DEBUG: ow_regex.c:(74) Reg Ex expression <^statistics/?> compiled to 0xb6eb05a0 DEBUG: ow_regex.c:(74) Reg Ex expression <^structure/?> compiled to 0xb6eb05c0 DEBUG: ow_regex.c:(74) Reg Ex expression <^system/?> compiled to 0xb6eb05e0 DEBUG: ow_regex.c:(74) Reg Ex expression <^interface/?> compiled to 0xb6eb0600 DEBUG: ow_regex.c:(74) Reg Ex expression <^text/?> compiled to 0xb6eb0620 DEBUG: ow_regex.c:(74) Reg Ex expression <^json/?> compiled to 0xb6eb0640 DEBUG: ow_regex.c:(74) Reg Ex expression <^uncached/?> compiled to 0xb6eb0660 DEBUG: ow_regex.c:(74) Reg Ex expression <^unaliased/?> compiled to 0xb6eb0680 DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(74) Reg Ex expression <^alarm?> compiled to 0xb6eb04a0 DEBUG: ow_regex.c:(74) Reg Ex expression <^simultaneous/?> compiled to 0xb6eb03e0 DEBUG: ow_regex.c:(74) Reg Ex expression <^thermostat/?> compiled to 0xb6eb0400 DEBUG: ow_regex.c:(74) Reg Ex expression <^text/?> compiled to 0xb6eb0420 DEBUG: ow_regex.c:(74) Reg Ex expression <^json/?> compiled to 0xb6eb0440 DEBUG: ow_regex.c:(74) Reg Ex expression <^uncached/?> compiled to 0xb6eb0460 DEBUG: ow_regex.c:(74) Reg Ex expression <^unaliased/?> compiled to 0xb6eb0480 DEBUG: ow_regex.c:(74) Reg Ex expression <^([[:xdigit:]]{2})\.?([[:xdigit:]]{12})\.?([[:xdigit:]]{2}){0,1}$> compiled to 0xb6eb0740 DEBUG: ow_regex.c:(201) 0: 0->15 found <><A6.5F8F9B000050><> DEBUG: ow_regex.c:(201) 1: 0->2 found <><A6><.5F8F9B000050> DEBUG: ow_regex.c:(201) 2: 3->15 found <A6.><5F8F9B000050><> DEBUG: ow_cache.c:(912) Looking for device A6 5F 8F 9B 00 00 50 F6 DEBUG: ow_cache.c:(1070) Search in cache sn A6 5F 8F 9B 00 00 50 F6 pointer=0xb6eb0950 index=0 size=4 DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 120 seconds. DEBUG: ow_presence.c:(75) Found device on bus 1 DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(201) 0: 0->15 found <><A6.5F8F9B000050><> DEBUG: ow_regex.c:(201) 1: 0->2 found <><A6><.5F8F9B000050> DEBUG: ow_regex.c:(201) 2: 3->15 found <A6.><5F8F9B000050><> DEBUG: ow_parsename.c:(63) /A6.5F8F9B000050 DEBUG: ow_w1.c:(201) SN finished CALL: ow_parsename.c:(104) path=[/bus.1] DEBUG: ow_regex.c:(201) 0: 0->5 found <><bus.1><> DEBUG: ow_regex.c:(201) 1: 4->5 found <bus.><1><> DEBUG: ow_regex.c:(74) Reg Ex expression <^/bus\.[[:digit:]]+/?> compiled to 0xb6eb06a0 DEBUG: ow_regex.c:(201) 0: 0->6 found <></bus.1><> DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_parsename.c:(63) /bus.1 CALL: ow_parsename.c:(104) path=[/bus.0] DEBUG: ow_regex.c:(201) 0: 0->5 found <><bus.0><> DEBUG: ow_regex.c:(201) 1: 4->5 found <bus.><0><> DEBUG: ow_regex.c:(201) 0: 0->6 found <></bus.0><> DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_parsename.c:(63) /bus.0 CALL: ow_parsename.c:(104) path=[/uncached] DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_parsename.c:(63) /uncached CALL: ow_parsename.c:(104) path=[/settings] DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_parsename.c:(63) /settings CALL: ow_parsename.c:(104) path=[/system] DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_parsename.c:(63) /system CALL: ow_parsename.c:(104) path=[/statistics] DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_parsename.c:(63) /statistics CALL: ow_parsename.c:(104) path=[/structure] DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_regex.c:(154) Not found DEBUG: ow_parsename.c:(63) /structure DEBUG: ow_dir.c:(199) ret=0 DEBUG: ow_parsename.c:(63) / DEBUG: data.c:(193) DataHandler: FS_ParsedName_destroy done DEBUG: data.c:(207) DataHandler: cm.ret=0 DEBUG: to_client.c:(76) payload=82 size=81, ret=0, sg=0x10A offset=0 DEBUG: data.c:(226) Finished with client request DEBUG: handler.c:(135) OWSERVER handler done DEBUG: ow_net_server.c:(259) Normal completion. John -----Original Message----- From: Jan Kandziora [mailto:[hidden email]] Sent: 29 November 2016 22:33 To: OWFS (One-wire file system) discussion and help <[hidden email]> Subject: Re: [Owfs-developers] DS2438 reporting A6 as family Am 29.11.2016 um 18:29 schrieb John Bass: > > I have just connected a DS2438, which seems to be reporting a A6 family code, and thus not giving the correct input details. > w1_master_driver w1_bus_master1: Family a6 for a6.5000009b8f5f.f6 is not registered. > This is a message from the kernel driver. It means: there is no kernel driver for the DS2438 loaded. Which is quite true, as such a driver does not exist yet. > On owfs 3.1p1 > Uh, no. You are looking at the wrong thing. The w1 subsystem has two parts. One is the host adaptor code, which owfs happily use when started with --w1. On top of this, owfs implements its own userspace driver code for all the slave chips it supports. So if something fails with a slave chip, you have to look for another error which doesn't come from the kernel driver. (The other part of the w1 subsystem is the slave code which owfs doesn't use at all. You can use it in parallel to owfs when there is a kernel driver for the slave chip existing.) Kind regards Jan ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
In reply to this post by JohnneyBoy
> Hello, > > > I have just connected a DS2438, which seems to be reporting a A6 family > code, and thus not giving the correct input details. > > > w1_master_driver w1_bus_master1: Family a6 for a6.5000009b8f5f.f6 is not > registered. > > > On owfs 3.1p1 > I've been using DS2438 battery monitor devices for a number of years and they have a family code of 0x26 NOT 0xA6. This sounds like a fake similar to to ones I got burnt with recently, a supposed DS2413 with a family code of 0x85 instead of the correct code of 0x3A. I'm pretty sure that there are no genuine Dallas/Maxim devices with a family code where the MSB is set. -- Robin Gilks ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
On 30/11/16 10:18, Robin Gilks wrote: >> Hello, >> >> >> I have just connected a DS2438, which seems to be reporting a A6 family >> code, and thus not giving the correct input details. >> >> >> w1_master_driver w1_bus_master1: Family a6 for a6.5000009b8f5f.f6 is not >> registered. >> >> >> On owfs 3.1p1 >> > I've been using DS2438 battery monitor devices for a number of years and > they have a family code of 0x26 NOT 0xA6. > > This sounds like a fake similar to to ones I got burnt with recently, a > supposed DS2413 with a family code of 0x85 instead of the correct code of > 0x3A. I'm pretty sure that there are no genuine Dallas/Maxim devices with > a family code where the MSB is set. > > devices appearing, mostly, I have to say, iButtons, but I've heard of other 1-wire chips too. With the iButtons one of the things that seems to happen is that failed devices are stolen from the disposal bins at Maxim's facility in the Philippines and shipped off to China where they are disassembled and re-packaged with new batteries. We got badly burned when we bought $16,000 worth of DS1923s from a reputable second-source company in the US who had gone to the lengths of disassembling a couple of them, checking the dies and deciding they were originals. Unfortunately the Chinese had omitted to set the register that specified they were DS1923s and they read as DS2422s. Be very careful when offered cheap iButtons... Nigel ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
In reply to this post by Robin Gilks
Am 30.11.2016 um 11:18 schrieb Robin Gilks:
> > I've been using DS2438 battery monitor devices for a number of years and > they have a family code of 0x26 NOT 0xA6. > They can have both. See page 12 of the Book of iButton standards (sheet 19 of http://pdfserv.maximintegrated.com/en/an/AN937.pdf) Bit 7 is a "customer coded" flag. That means an 0xA6 DS2438 is a DS2438 with a serial number from a secondary pool. These devices seem to appear from time to time. We could easily add support for them. > I'm pretty sure that there are no genuine Dallas/Maxim devices with > a family code where the MSB is set. > For example 0x81 is a DS2401 built into the DS9490 USB host adapter. There are some more but yes, the most of the upper half of family codes is unused. Kind regards Jan ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
Hello Jan,
OK, that would be a great idea. I have had a go at changing the code in ow_2438.c but can't seem to get it to work, I wondered if just changing the family id would do the trick. So I added a copy of the DS2438 section called it DS2438z etc with the new address family.. but it does not seem to recognise it. static struct aggregate A2438z = { 8, ag_numbers, ag_separate, }; static struct filetype DS2438z[] = { F_STANDARD, {"pages", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"pages/page", 8, &A2438z, ft_binary, fc_stable, FS_r_page, FS_w_page, VISIBLE, NO_FILETYPE_DATA, }, {"VDD", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_volatile, FS_volts, NO_WRITE_FUNCTION, VISIBLE, {.i=voltage_source_VDD}, }, {"VAD", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_volatile, FS_volts, NO_WRITE_FUNCTION, VISIBLE, {.i=voltage_source_VAD}, }, {"temperature", PROPERTY_LENGTH_TEMP, NON_AGGREGATE, ft_temperature, fc_simultaneous_temperature, FS_temp, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"humidity", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_link, FS_Humid, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"vis", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_volatile, FS_Current, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"IAD", PROPERTY_LENGTH_YESNO, NON_AGGREGATE, ft_yesno, fc_stable, FS_r_status, FS_w_status, VISIBLE, {.i=0}, }, {"CA", PROPERTY_LENGTH_YESNO, NON_AGGREGATE, ft_yesno, fc_stable, FS_r_status, FS_w_status, VISIBLE, {.i=1}, }, {"EE", PROPERTY_LENGTH_YESNO, NON_AGGREGATE, ft_yesno, fc_stable, FS_r_status, FS_w_status, VISIBLE, {.i=2}, }, {"offset", PROPERTY_LENGTH_UNSIGNED, NON_AGGREGATE, ft_unsigned, fc_stable, FS_r_Offset, FS_w_Offset, VISIBLE, NO_FILETYPE_DATA, }, {"udate", PROPERTY_LENGTH_UNSIGNED, NON_AGGREGATE, ft_unsigned, fc_second, FS_r_counter, FS_w_counter, VISIBLE, {.s=0x08}, }, {"date", PROPERTY_LENGTH_DATE, NON_AGGREGATE, ft_date, fc_link, COMMON_r_date, COMMON_w_date, VISIBLE, {.a="udate"}, }, {"disconnect", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"disconnect/udate", PROPERTY_LENGTH_UNSIGNED, NON_AGGREGATE, ft_unsigned, fc_volatile, FS_r_counter, FS_w_counter, VISIBLE, {.s=0x10}, }, {"disconnect/date", PROPERTY_LENGTH_DATE, NON_AGGREGATE, ft_date, fc_link, COMMON_r_date, COMMON_w_date, VISIBLE, {.a="disconnect/udate"}, }, {"endcharge", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"endcharge/udate", PROPERTY_LENGTH_UNSIGNED, NON_AGGREGATE, ft_unsigned, fc_volatile, FS_r_counter, FS_w_counter, VISIBLE, {.s=0x14}, }, {"endcharge/date", PROPERTY_LENGTH_DATE, NON_AGGREGATE, ft_date, fc_link, COMMON_r_date, COMMON_w_date, VISIBLE, {.a="endcharge/udate"}, }, {"HTM1735", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"HTM1735/humidity", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_link, FS_Humid_1735, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"HIH3600", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"HIH3600/humidity", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_volatile, FS_Humid_3600, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"HIH4000", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"HIH4000/humidity", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_volatile, FS_Humid_4000, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"DATANAB", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE_DATANAB, NO_FILETYPE_DATA, }, {"DATANAB/humidity", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_volatile, FS_Humid_datanab, NO_WRITE_FUNCTION, VISIBLE_DATANAB, NO_FILETYPE_DATA, }, {"DATANAB/reset", PROPERTY_LENGTH_YESNO, NON_AGGREGATE, ft_yesno, fc_stable, NO_READ_FUNCTION, FS_reset_datanab, VISIBLE_DATANAB, NO_FILETYPE_DATA, }, {"MultiSensor", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"MultiSensor/type", 12, NON_AGGREGATE, ft_vascii, fc_stable, FS_MStype, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"B1-R1-A", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"B1-R1-A/pressure", PROPERTY_LENGTH_PRESSURE, NON_AGGREGATE, ft_pressure, fc_volatile, FS_B1R1A_pressure, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"B1-R1-A/offset", PROPERTY_LENGTH_PRESSURE, NON_AGGREGATE, ft_pressure, fc_stable, FS_r_B1R1A_offset, FS_w_B1R1A_offset, VISIBLE, NO_FILETYPE_DATA, }, {"B1-R1-A/gain", PROPERTY_LENGTH_PRESSURE, NON_AGGREGATE, ft_pressure, fc_stable, FS_r_B1R1A_gain, FS_w_B1R1A_gain, VISIBLE, NO_FILETYPE_DATA, }, {"S3-R1-A", PROPERTY_LENGTH_SUBDIR, NON_AGGREGATE, ft_subdir, fc_subdir, NO_READ_FUNCTION, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"S3-R1-A/current", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_volatile, FS_S3R1A_current, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"S3-R1-A/illuminance", PROPERTY_LENGTH_FLOAT, NON_AGGREGATE, ft_float, fc_volatile, FS_S3R1A_illuminance, NO_WRITE_FUNCTION, VISIBLE, NO_FILETYPE_DATA, }, {"S3-R1-A/gain", PROPERTY_LENGTH_PRESSURE, NON_AGGREGATE, ft_float, fc_stable, FS_r_S3R1A_gain, FS_w_S3R1A_gain, VISIBLE, NO_FILETYPE_DATA, }, }; DeviceEntryExtended(a6, DS2438z, DEV_temp | DEV_volt, NO_GENERIC_READ, NO_GENERIC_WRITE); John -----Original Message----- From: Jan Kandziora [mailto:[hidden email]] Sent: 30 November 2016 15:15 To: [hidden email]; OWFS (One-wire file system) discussion and help <[hidden email]> Subject: Re: [Owfs-developers] DS2438 reporting A6 as family Am 30.11.2016 um 11:18 schrieb Robin Gilks: > > I've been using DS2438 battery monitor devices for a number of years > and they have a family code of 0x26 NOT 0xA6. > They can have both. See page 12 of the Book of iButton standards (sheet 19 of http://pdfserv.maximintegrated.com/en/an/AN937.pdf) Bit 7 is a "customer coded" flag. That means an 0xA6 DS2438 is a DS2438 with a serial number from a secondary pool. These devices seem to appear from time to time. We could easily add support for them. > I'm pretty sure that there are no genuine Dallas/Maxim devices with a > family code where the MSB is set. > For example 0x81 is a DS2401 built into the DS9490 USB host adapter. There are some more but yes, the most of the upper half of family codes is unused. Kind regards Jan ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
Am 30.11.2016 um 16:52 schrieb John Bass:
> > I have had a go at changing the code in ow_2438.c but can't seem to > get it to work, I wondered if just changing the family id would do > the trick. So I added a copy of the DS2438 section called it DS2438z > etc with the new address family.. but it does not seem to recognise > it. > You have to patch module/owlib/src/c/ow_tree.c, too. Please tell if that helps. Kind regards Jan ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
Hello Jan, Found it a while back, and yep it works :-) I have noticed one very interesting issue, if you over clock the pi, the 1w driver does not work correctly! Devices do not work reliably or with reduced functionality especially the 2438. I put the clock back to 700mhz and the 2438 works perfectly!!! John Sent from my iPhone
------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
Am 30.11.2016 um 22:25 schrieb John Bass:
> Hello Jan, > > Found it a while back, and yep it works :-) > Do you have a patch? > I have noticed one very interesting issue, if you over clock the pi, > the 1w driver does not work correctly! Devices do not work reliably > or with reduced functionality especially the 2438. I put the clock > back to 700mhz and the 2438 works perfectly!!! > Do you use the bitbanging host? That one could have timing issues. Kind regards Jan ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
Hello Jan, Yep the gpio 1w driver. I'm a little surprised the clock speed makes a difference, would have expected that to have been taken into consideration by the driver developers. How would you like me to generate the patch? John Sent from my iPhone
------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
Am 30.11.2016 um 23:32 schrieb John Bass:
> > Yep the gpio 1w driver. I'm a little surprised the clock speed makes > a difference, would have expected that to have been taken into > consideration by the driver developers. > In theory all is timed but when the clock speed is out of bounds, the calculation formula could be wrong. > How would you like me to generate the patch? > Install git and gitk. Setup git: $ git config --global user.name "John Bass" $ git config --global user.email "[hidden email]" Clone the owfs git repository from sf.net (or github, that's a mirror): Use gitk to get an overview about commits. $ git clone https://github.com/owfs/owfs.git $ cd owfs $ gitk& (later: pull the newest version with "git pull" instead) Bootstrap the repository to prepare it for your test compiles: $ ./bootstrap $ ./configure *** Apply your patches *** Do a test. $ make $ sudo make install Commit your patches: $ git commit -m "added support for DS2438 with 0xA6 family code" modules/owlib/... Export your patch in a format suitable for inclusion into the archive: $ git format-patch master --stdout <old_id>..<new_id> <old_id> and <new_id> are the SHA1 ids as shown by the git tools, e.g. gitk& Make the email subject read "[PATCH 1/1]: added support for DS2438 with 0xA6 family code" Give further explanations on the "why" on top of the email and end these with a line Signed-off: "John Bass <[hidden email]>" Then paste that patch into an email (not as an attachment, just a plain pasting). Disable automatic line-breaking. That's the procedure as used by the Linux kernel maintainers. We have far less patches than them so we can accept stray patches too, but adapting their procedure sure helps you to get patches accepted everywhere. It's just good practice. Kind regards Jan ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
In reply to this post by JohnneyBoy
Am 30.11.2016 um 22:25 schrieb John Bass:
> Hello Jan, > > Found it a while back, and yep it works :-) > I've found time do develop a more generic approach to add support for "secondary" family codes. Could you try the appended patch? Of course, you had to remove your patch first. Kind regards Jan ------------------------------------------------------------------------------ Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers |
Free forum by Nabble | Edit this page |