Creating DS18B20

Again: What about doing nothing?

Does the device need to do something?

arcachofo wrote:Again: What about doing nothing?

Does the device need to do something?

Yes, it needs to send bit 0 on the bus after 97.5 to 750ms conversion time and then wait for master reset pulse.

Yes, it needs to send bit 0 on the bus after 97.5 to 750ms conversion time

Then use the pulse() function.

arcachofo wrote:
Then use the pulse() function.

It doesn't work with such large delay, I have tried already. It is not a pulse anyway, just delay. The bus is already pulled up by master.

The simulation timing is decoupled from real time (our time).
Until 0.4.15 simulation run based in a clock, from 1.0.0 simulation runs based in events.
But in any case 1 us of "circuit time" can be 1 ns of "our time" or can be 1 hour.
All the timing is managed by the simulation engine and you can't do sleeps or anything else related with timing in your component.

The way to do anything (from 1.0.0) is registering events in the simulation engine:
Simulator::self()->addEvent( time, object );

Then object::runEvent() will be called after "time" picosecons (circuit time).

Ds18b20::pulse( time, witdth ) does this for you:
It sends a low pulse of "width" us duration after "time" us.

It doesn't work with such large delay, I have tried already. It is not a pulse anyway, just delay. The bus is already pulled up by master.

It works with any delay you want.

It is not a pulse anyway, just delay

As far as I know is a pulse: drive the line low for some time, then release it.

Probably I missing something, but we have two powering schemes here:

Code:

Convert T [44h]
This command begins a temperature conversion. No further data is required. The temperature conversion will be performed and then the DS18B20 will remain idle. If the bus master issues read time slots following this command, the DS18B20 will output 0 on the bus as long as it is busy making a temperature conversion; it will return a 1 when the temperature conversion is complete. If parasite-powered, the bus master has to enable a strong pullup for a period greater than t conv immediately after issuing this command.

I'm trying to solve parasite-powered mode, as that is default. I have added VDD pin in order to determine the unit is in parasite or normal mode. If VDD pin is grounded, it is in parasite mode and just take power with internal 25pF from the bus pull-up.

Here, timing is critical. If too much time is spend, it will run out of the power and shut down and power up again when is charged up...

I'm trying to solve parasite-powered mode, as that is default.

Yes, that's what I understood.
So if not in parasite mode:
It must wait for a read pulse from master.
If the read pulse is received then send a pulse for the duration of the conversion.
If not just do nothing.

In my first implementation I added this line to do the pulse:
if( !m_parPower ) pulse( 1, 749 ); // Send a 749 us pulse after 1 us

This is wrong, because it needs to wait for read pulse, but that is the way to do it if the read pulse is received.

There are other errors as well, I don't know if you solved them, but in my last commit I solved all errors found.

Yes, I have solved many problems and all working now. The nightmare is to solve parasitic and non-parasite mode properly and was not possible without VDD pin.

As well, "remain idle" means it waiting for command or data in the datasheet content, but flow chart and other content says "After ROM command if function command is possible and follow it, device will wait for master reset pulse after it's execution".

At least as I understood datasheet...

Dallas Temperature lib works fine in current implementation, but I do not know why if VDD is grounded (0V) avoid to recognize it as parasite, while if not connected at all (floating) it do it as such...

That is over my power to solve and similar stuff. I will also test all on real device further and will be probably able to send all during weekend to cleanup all. Then we will see for next steps.

That is over my power to solve and similar stuff. I will also test all on real device further and will be probably able to send all during weekend to cleanup all. Then we will see for next steps.

Ok, by now there is nothing I can do until I see the code.

arcachofo wrote:Ok, by now there is nothing I can do until I see the code.

Actually, this about VDD pin can help a bit. I have define it as such:

Code:

//Added VDD pin
    m_pin[1] = m_Vdd = new Pin( 180, QPoint(-36, 0), id+"-vddPin", 1, this );   
    m_Vdd->setLabelColor( QColor( 250, 200, 200 ) );
    m_Vdd->setLabelText("Vdd");

Then in the code later:

Code:


void Ds18b20::writeRawBit( uint8_t bit )
{
  if (bit == 0)
      pulse( 5, 80 );
  else
      pulse( 5, 50 );
}

void Ds18b20::readPowerSupply() // Code B4h : using parasite power? pull down
time???
{
    m_parasitePower = m_Vdd->getVolt() == 0; // Should sense rail voltage;

    if (m_parasitePower)
        writeRawBit(0);

    // After this command, wait for reset pulse
    m_DeviceIsIdle = false;
}


Now, if the Vdd is grounded, m_parasitePower is false. If is floating it is true (probably should not be available) and if connect to 5V is false (as it should be)....

A bit confusing for me, why when it is grounded (ground sign) show it is not in parasite mode. Probably I missing something in pin declaration....

Also, I would like to move pin on the other side (opposite to DQ), but I have no idea is it possible.

Code:

m_parasitePower = m_Vdd->getVolt() == 0; // Should sense rail voltage;

Voltage could be 1e-14 V for example, which is not 0.
You can use:

Code:

m_parasitePower = m_Vdd->getVolt() < threshold; // Should sense rail voltage;

You choose a threshold (datasheet?)

Also, I would like to move pin on the other side (opposite to DQ), but I have no idea is it possible.

m_pin[1] = m_Vdd = new Pin( angle, QPoint( x, y ), id+"-vddPin", 1, this );

angle = 0 for right side.
x is the tip of the pin (where wires attach)
x is positive for right side and must be multiple of 8.
I think in your case x must be 40 or 48.

Thanks. That should solve the problems...

I have start some basic tests on the real device. This one I have seems to be a genuine Dallas/Maxim product, not a fake or clone (see projects to detect them).

Quite a surprise was that it detects reset after just 202us delay (changed a bit Arduino OneWire lib reset for test) .
Passive and external power is also detected immediately. requiring no delay for pull up at all...

I will test further the rest of commands in both, parasite and external power and determine related timings. Also, I will possible "borrow" one more sensor from an old working project 24/7 almost a decade and see how it behaves in parasite and non-parasite configurations.

The code is almost ready, it passed all tests to discover fake sensor with only one minor issue:

Code:


--- # discover_fake_DS18B20.ino
This sketch will test DS18B20 sensors attached to
  pin 8 for differences with Maxim Integrated-produced DS18B20
  using only functionality documented in the datasheet and in
  Maxim Application Note AN4377.

28-54-7F-42-73-00-00-02: ROM ok.
  Scratchpad Register: 8A/02/AA/55/FF/FF/0C/10/79
  Info only: Scratchpad bytes 2,3,4 (AA/55/FF):  not Maxim default values 4B/46/7F.
  Scratchpad byte 5 (0xFF):  ok.
  Scratchpad byte 6 (0x0C):  unexpected value. Error.
  Scratchpad byte 7 (0x10):  ok.
  0x4E modifies alarm registers:  ok.
  0x4E accepts 10 bit resolution:  ok.
  0x4E preserves reserved bytes:  ok.
  0x4E accepts 12 bit resolution:  ok.
  0x4E preserves reserved bytes:  ok.
  Checking byte 6 upon temperature change: not necessary. Skipped.
  --> Sensor appears to be counterfeit based on 1 deviations.
  The number of deviations is unexpectedly small.
  Please see https://github.com/cpetrich/counterfeit_DS18B20/
  to help interpret the result.

Temperature was stored from UI,, thus that is easy to fix to hold defaults until call conversion.

I have start some basic tests on the real device. This one I have seems to be a genuine Dallas/Maxim product, not a fake or clone (see projects to detect them).

Quite a surprise was that it detects reset after just 202us delay (changed a bit Arduino OneWire lib reset for test) .
Passive and external power is also detected immediately. requiring no delay for pull up at all...

I will test further the rest of commands in both, parasite and external power and determine related timings. Also, I will possible "borrow" one more sensor from an old working project 24/7 almost a decade and see how it behaves in parasite and non-parasite configurations

Testing a real device will help a lot to know what it's actually doing.

Current, almost 100% complete code.

Only two things missing:
-  Proper busy emulation when conversion temperature is in progress (parasite and external power)
- Alarm search

Other works fine, although may be some minor glitches and some fine tuning.

Busy state emulation is quite important in DS18b20, otherwise conversion should report faulty reading.

BTW, It would be interesting if internal 25pF capacitor could be simulated. It is used for parasite power only.

Since sensor need 1-1.5mA to work properly for each command avoiding reset with multiple parasite power sensor, may be tricky. For determining proper cable length, resistor for the bus according number of devices and configuration, exists quite detail study. Not a trivial sensor at all...

Also, reserved byte 6 in scratchpad is actually not static. It changes his value according to result of conversion... I need to fix that as well.

Test files...

Unfortunately, I have no idea when I will be able to work on this again. I have too much private obligations... You may add this in repository, anyway.

I have also added timing ranges etc. However, the problem which stays is delay for specific command which need to be handled in the simulator correctly, as temperature conversion.

Just for the record...

I have found two bugs in Arduino DalasTemperature library.

The first one is a minor one: if temp. is exactly -55C, it will show -127C. Less or equal, instead less than -55C condition...

Another, more serious bug in it is temp. reading of many sensors, it is very slow, practically impossible (minutes waiting) to read on 63 sensors, for instance, as it do search command on entire bus every time temp. conversion is requested.