1-Wire. Hardware abstracted

[barthess]

Hi there.
I know about 1-wire master via UART but in our projects whatever
MCU we took - we always do not have enough serial ports.
So I decide to create driver using some other hardware resources.
Now I have a proof of concept driver constructed ontop
of PWM + PAL. It need 2 channels from single timer. Driver
can be implemented ontop of single GPT but PWM variant
generates less interrupts.

My question is "Is such 1-wire needed in ChibiOS?"

[Giovanni]

Hi Barthess,

Potentially yes but you know that I am reluctant to an unbounded growth of the code base because support concerns. On the other hand would be a shame to not include somehow all the code that is contributed.

Probably the solution would be to have some kind of "expanded" repository linked from the main repository and release all the code from the expanded repository as-is together with the core code, without any kind of support or maintenance except what that authors are willing to provide.

On another thread Tectu is searching for a new manager for the community git repository, probably that one could become this extended repository after defining a structure. We need just to find one or more persons willing to handle it, would you be interested?

viewtopic.php?f=3&t=2197

The repository could be linked by an ./ext directory from the main one and be internally organized exactly like the main one:

./ext/demos
./ext/os
./ext/os/hal
./ext/os/hal/include (additional headers)
./ext/os/hal/src (additional sources)

The structure of the main repository would be replicated under ./ext, the rule would be that there must not be overlapping files, a feature is in the main OR in ext, not in both.

This would apply to the kind of extensions you are proposing but also new ports, libraries etc

Giovanni

[Giovanni]

Of course all the above is because I need to draw a line separating what you can expect to be supported here and what is simply provided as-is, I would move also FatFS and lwIP stuff there.

Giovanni

[barthess]

Such way is less convenient for the first look but we definitely have to try it.

[barthess]

I created repository with test code for STMicroelectronics STM32F4-Discovery board here
https://github.com/ChibiOS/ChibiOS-onewire It will be moved to community repo later.

Note! This is just preview for to satisfy smb's curiosity. Code is dirty and lacks of comments.

Driver based on timings located in AN1199 (1-Wire® Communication with PIC® Microcontroller).
Currently only read and write operations realized. This is enough to
communicate with single device on bus. Search rom command is working in progress.

To use demo you have to power your 1-wire device from 5V bus on board
and connect DQ line to PB8. Do not forget about external pullup
resistor to 5V (4k7 recommended).

[barthess]

Some news.
Driver now looks much better and cleaner. Now it able to perform "search rom" command (tested in hardware with 3 DS18B20 on one bus).
Plans:
1) create synthetic test for "search rom" command
2) combine all helper structures in single driver structure
3) compile time switch for "search rom" command
4) add strong pull up support and test hardware in parasitic power mode

[barthess]

Some news:
Functionality looks finished. Synthetic test done. Only strong pullup needs to be tested in hardware. After that I will clean code and move it to community repository.

[barthess]

Code is tested and looks fully functional. It just need commenting and little formating.

Parasitic power mode ready too, but I am not sure about it necessity.
1) It raises interrupt jitter constrains from ~40uS to ~4uS
2) Pollute code with #ifdefs

[Giovanni]

About jitter, how much it affects the driver? for example, is it able to run during the execution of the whole test suite?

Giovanni

[steved]

Parasitic power mode ready too, but I am not sure about it necessity.
1) It raises interrupt jitter constrains from ~40uS to ~4uS
2) Pollute code with #ifdefs

I use parasitic power mode quite a lot (I assume by that you mean that the OWB devices derive their power directly from the OWB, rather than from some other power source), and I get the impression that its the 'usual' operating mode.
I've been using the DS2484 as the interface, which does greatly simplify both the hardware and the low-level software interface - although there's still a substantial amount of code involved.
The disadvantage/complication of parasitic power mode is that some devices (e.g. temperature sensors) then require you to keep the bus powered and inactive during their internal A-D conversion. This can take as long as 750ms, IIRC, which seriously limits throughput. So for one application I'm actually intending to distribute 5volts to avoid those delays.