Creating DS18B20

I have started to implement this. However, truly 1-Wire protocol is not implemented at all? Thus one device is possible per pin? Protocol must exists, to support several commands and several devices. That is not possible currently, as ROM of the device must be read for identification...

I can create reading/writing temp. but that is not enough to support multiple devices on the same line..

truly 1-Wire protocol is not implemented at all?

No, it's not implemented because there is no component using it.

Protocol must exists, to support several commands and several devices. That is not possible currently, as ROM of the device must be read for identification

You need to implement 1-Wire protocol in your component.

I can hardly do that, as I have no deeper insight in your software.

All is related to Dallas Semiconductor 1-Wire devices and is the same for all...

Notice as well that 1-Wire bus can handle up to 63 devices. I.e. 63 connections per node, one more for pull-up resistor and MCU pin and each for VCC and GND. That means 100s lines per joint for multiple buses need to be implemented for proper handling, while current software handles only few....

Plus, 1-Wire devices can work on parasitic power... But then they may behaves a bit differently....

The 1-Wire bus is unique and must be carefully implemented, which is beyond my abilities, as I'm hardly scratched the essence in your software... What I can do is just to encode/decode data which specific device's commands produces. But protocol itself is something you have to implement as it is the same for all 1-Wire devices...

Probably, changes are way too complex to do all properly...

I can hardly do that, as I have no deeper insight in your software.

DHT22 uses a custom 1 wire protocol.
You can use it as a reference.
It's all about adapting it to Dallas Semiconductor 1-Wire protocol.

Unfortunately, 1-Wire protocol is much more complicated than that...

If and when you can do it, it is entirely on you. Basic sequence:
- Reset
- Enumerate devices. Search devices / reading ROM for each device on the bus
- Sending commands and receiving data to/from specific device

Implementing bit-banging protocol in your software is not in my power.

Implementing bit-banging protocol in your software is not in my power.

Implementing communication is quite simple:
1- Detect Reset: exactly the same than DHT22 but different timing.
2- Send "ACK": exactly the same than DHT22 but different timing.
3- Start to read bits: exactly the same than Detect Reset but different timing.
4- Every 8 bits = 1 byte received: Do whatever with each byte received.

I don't know much about this protocol, but if I understand correctly Master also clocks the Slave to send each bit.
If so, sending data is even easier than DHT22:
1-  Detect start signal: exactly the same than Detect Reset  but different timing.
2- If bit = 0: Pull line down  exactly the same than Send "ACK" but different timing.
   If bit = 1: Do nothing.

All this is implemented in DHT22::voltChanged() and DHT22::runEvent() functions.

Unfortunately, 1-Wire protocol it is much more complicated than that...

If and when you can do it, it is entirely on you. Basic sequence:
- Reset
- Enumerate devices
- Search devices
- Read ROM
- Sending command and receiving data

As far as I know that is what the Master does.
The slave just receive bytes and takes actions depending on the byte number ant content.
So some kind of "state machine" must be implemented that do whatever with received bytes.

Tomorrow I will send you a basic implementation of the bit-banging protocol:
Basically copy-paste from DHT22 with some changes.

Attached basic implementation for DS18B20.
Full component ready for use with bitbanging implemented (NOT TESTED).
It's basically a mix betwen DHT22 and DS1621.

Add it to src/gui/circuitwidget/itemlibrary.cpp:
After line 47:

Code:

#include "ds1307.h"
#include "ds1621.h"
#include "ds18b20.h" // Add this line

After line 240:

Code:

    addItem( Dht22::libraryItem() );
    addItem( DS1621::libraryItem() );
    addItem( Ds18b20::libraryItem() ); // Add this line

Component is now available in component list: Micro->Sensors.

Now you can do stuff at
Ds18b20::byteReceived() // a byte has been received (it's in m_data)
Ds18b20::byteSent() // Last byte has been sent

To send data just use:
sendByte( data );

It is not tested, so expect errors, but all the "infrastucture" to receive and send data is there.
I would start by testing that it's actually receiving data correctly.
Then you can start to implement whatever must be done with that data.

Can you check, I do not see any attachment here...

Sorry, forgot to click some button...
Attachment added in previous post.

OK... I will look on it later.

I have added some code, which should work independently (tested). However, existed simulator code reading and sending bytes with some problems, I'm unable to fix

The simulator read something, but not correctly. I believe bits are mirrored (should be read LSB to MSB, not MSB to LSB) and/or skip or miss interpreted some signals...

It is really necessary to create 1-Wire protocol lib, as similarly existed for I2C and others...

Attached current DS18B20 code, simulator file with Arduino samples. One uses Arduino lib, others not.

Try first with DS18B20_nolib1.ino and debug code which sending CCh.. Simulator wrongly received 19h...

By side of datasheet and flow chart, look also these:

Detailed explanation of the 1-Wire protocol Part 1-6:
https://www.youtube.com/watch?v=UR_cAvNjUZc&list=PLHZCZKKB20XZ6gE3Ki8A7TVkjJRkA12Xk

1-Wire – Through the Looking Glass (Scope) and Down the Rabbit Hole (Bit Level):
https://www.youtube.com/watch?v=UIx8R1LV6HM

The simulator read something, but not correctly. I believe bits are mirrored (should be read LSB to MSB, not MSB to LSB)

Yes, that was the problem.
Solved at Rev 1129;

sendByte() fixed at Rev 1130.

Thank you for the feedback.

You will then continue on this to add rest?

BTW, seems that sending bytes still have a problem.

You will then continue on this to add rest?

No.

OK, I will then...

But first, please fix that problem with sending data.

But first, please fix that problem with sending data.

Can you define the problem?
How to reproduce it?

Yes, send multiple bytes to master. E.g. execute "Read ROM" command (33h). Nothing is sent or just one byte with 00h...

Also look at byteSent(), it is never executed, or just for one byte, instead all 8 bytes, for upper command 33h.

E.g. execute "Read ROM" command (33h). Nothing is sent or just one byte with 00h

Is that command implemented?
That's what needs to be done: implementing commands.

Also look at byteSent(), it is never executed

Is executed when you call it.
When the byte is sent then byteSent() is called.

or just for one byte, instead all 8 bytes

That's what you have to implement.

Well, I did and I have sent you all with examples yesterday...
You have not implemented that, just fixed bugs with receive bytes.

I did insert all that codes with new version and tested - it failed to send data.

I will resend you all with some added new code...

Well, I did and I have sent you all with examples yesterday...

Sorry I didn't realize.

Some issues I found:

Code:

void Ds18b20::readROM()
{
    /// Code: 33h
    /// If there is only one device on the bus, no need for search ROM procedure
    /// Master demands ROM address of it

    for(int i=0; i<8; i++)
    {
       sendByte(m_ROM[i]);
    }
}

You can't do that.
You need to send one byte, when that byte is sent then you send next one and so on.
same for Ds18b20::readScratchpad().

Ds18b20::command is never called.

And the way to do that properly is?

I have told you that I have no deeper insight in your software. It is probably heavily threaded, but I really do not have a time to look deeper.

And for instance, temperature reading in real device (command 44h) last 750ms max (for 12-bit resolution). How to accomplish that here, not to affect overall performance?

Commands was in process of implementation, that code was current implementation and could be called directly for test...

I have almost implemented all commands, just need solution for upper...

And the way to do that properly is?

You need to send one byte.
When the byte is sent then byteSent() is called.
Then you send next byte and so on.

I have told you that I have no deeper insight in your software.

This is not specific for simulide.
You just need to implement some way to send an array one byte at a time.

Probably implementing a method: sendData( std::vector<uint8_t> data )
Consider using std::vector instead of plain arrays.
For example something like this:
- Save the vector to send.
- Send first byte.
- In byteSent():
   Vector is empty?
   True: Transaction finished.
   False: Use data.pop_back() to take the last byte and call sendByte()

And for instance, temperature reading in real device (command 44h) last 750ms max (for 12-bit resolution). How to accomplish that here, not to affect overall performance?

As I understand this is not critical by now.
This can be fine tuned later.

This is preliminary code. Many things still missing, but basic is fully functional.

What is working are basic examples with 1-wire Arduino libraries. I will add some basic examples later (test I'm using require quite a bit of cleaning), if needed.

Dallas Semiconductor lib will not work, since search ROM is still not implemented.

According to latest bug report regarding different speed when interrupts are disabled, this may  explain why this component is unstable.

For instance, 1-wire lib use that method for precise delay timings:
https://github.com/PaulStoffregen/OneWire/blob/master/OneWire.cpp