1-Wire. Hardware abstracted

Discussions and support about ChibiOS/HAL, the MCU Hardware Abstraction Layer.
User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

1-Wire. Hardware abstracted

Postby barthess » Thu Oct 02, 2014 7:23 pm

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?"

User avatar
Giovanni
Site Admin
Posts: 12573
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 643 times
Been thanked: 539 times
Contact:

Re: 1-Wire. Hardware abstracted

Postby Giovanni » Thu Oct 02, 2014 9:34 pm

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

User avatar
Giovanni
Site Admin
Posts: 12573
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 643 times
Been thanked: 539 times
Contact:

Re: 1-Wire. Hardware abstracted

Postby Giovanni » Thu Oct 02, 2014 9:36 pm

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

User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

Re: 1-Wire. Hardware abstracted

Postby barthess » Fri Oct 03, 2014 7:37 am

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

User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

Re: 1-Wire. Hardware abstracted

Postby barthess » Sun Nov 16, 2014 4:08 pm

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).

User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

Re: 1-Wire. Hardware abstracted

Postby barthess » Wed Nov 19, 2014 8:22 pm

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

User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

Re: 1-Wire. Hardware abstracted

Postby barthess » Tue Dec 02, 2014 8:49 pm

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.

User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

Re: 1-Wire. Hardware abstracted

Postby barthess » Wed Dec 03, 2014 8:38 pm

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

User avatar
Giovanni
Site Admin
Posts: 12573
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 643 times
Been thanked: 539 times
Contact:

Re: 1-Wire. Hardware abstracted

Postby Giovanni » Wed Dec 03, 2014 9:25 pm

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
Posts: 646
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 8 times
Been thanked: 92 times

Re: 1-Wire. Hardware abstracted

Postby steved » Wed Dec 03, 2014 10:36 pm

barthess wrote: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.


Return to “ChibiOS/HAL”

Who is online

Users browsing this forum: No registered users and 1 guest