Hello Stepan, please report a PR and we will process it further over there :-) I have ordered 3x DS2431+ so I could test it in some days :-) Thank you :-) Tomek
On Mon, Jun 23, 2025 at 4:34 PM Štěpán Pressl <nuttx.pressl.ste...@gmail.com> wrote: > > Hello, > > I've developed a onewire driver for the DS2XXX one wire EEPROMs (such as > DS2431). In the email you should find the .c and the .h files attached > containing the lowerhalf driver. Before the PR on GitHub, I'd like to hear > your opinions on my implementation. > > I shall put this file into drivers/eeprom, as this makes more sense. You > should perform writes, reads and lseeks on this eeprom as it acts as a file. > I've tested this in my application and it seems to be fully functional, I was > inspired by the 24xxxx driver. > > However, I'd like to address some issues I am not really sure about. I ran > into a compilation problem when I tried to define the priv with the > onewire_master_s struct. Also, I do not see any point in using > onewire_master_s instead of onewire_dev_s (the lowerhalf driver) other than > you can use struct onewire_master_s to perform the ROM bus scan. Moreover I > need to interface multiple eeproms on the same bus - I solved this by using > an ioctl call which just assigns the target rom to a uint64_t variable > located in priv. All the available devices on the network can be scanned by > this hack of mine: I defined a boardctl all which just calls onewire_search > (here, the compilation somehow works as it needs onewire_master_s). All > scanned ROMS are saved in the userspace application and then via the ioctl > call I update the internal ROM variable. > > The previous paragraph implies that I don't really get the purpose of > onewire_master_s, when I can just use the lowlevel onewire_dev_s. I think the > 1wire driver should be restructuralized that it features an unified API for > rom scanning (for example ROMSCANIOC) that returns devices' ROMs > corresponding to the driver's family code. Then other ioctl call (such as > SETROMIOC) "selects" the devices which should be interfaced. > > I agree this is not really ideal and the ideal solution would involve > periodic scanning of the bus and then dynamically registering/unregistering > the devices in the file system (such as /sys in linux) but I think this > really goes against the lightweight philosophy of nuttx. > > Also some delays are needed between the scratchpad writes to the eeprom. Now > I'm using up_udelay which should not be multitasking friendly - are there any > other approaches that allow for multitasking friendly delays in the driver? > What about workqueue? > > Thanks in advance and BR, > Štěpán Pressl -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
