OneWire

[coderatchance]

Hello All,

Put together the hw for the oneWire, as given by the maxim, etc.

However, I am not sure what library to use to interface and interact between two tiny3216? Currently looking at this lib: https://www.pjrc.com/teensy/td_libs_OneWire.html

However, I am not sure what is meant by OneWire myWire(pin) ?

For testing purposes I am looking to use only the TX on one tiny and RX on the other tiny. So, is the general TXD and RXD pins used in this case? Such as PB2 and PB3 ? Do I got that right?

Best.

[SpenceKonde]

OneWire, you might need to use the fixed version of that library - see the supported libraries page in the documentation for a link, unless they finally updated the version of OneWire library to support modern AVRs (the change was trivial - I remember porting one, putting in the pull request for the fix, and watching it be ignored for years by the author).

OneWire carries out communication via a single bidirectional pin. As the communication is bitbanged, it doesn't rely on specific hardware capabilities of the pin, and any normal I/O pin can be used.

[coderatchance]

Thanks for the comment, input, I have been fiddling around the "bit-banged" solutions... however, looking to overleap the pin counts, extra components and use the DS2484 and start with the i2c end, since I am already having the i2c going for other devices...
On this note, I am not sure how should the 'slave' look like when considering the communication between two AT Tiny's.

The solution I am currently looking at is:

tiny(1) "master" uC -> i2c -> DS2484 -> one wire <- (one wire port config on uC as one wire) "slave" tiny(2)

While the above solution may be ok I am wondering, if this is the same board, for example, why the DS2484 could not as well 'act' as a slave?

In this case, the i2c would be used, which is already on the board. So far I did not spot the "i2c one wire driver" to conceptualise the one wire "slaves". Which is obviously found for the "bit-banged solutions" such as the DS2480B ?

Anyway, have only spotted the "master" on i2c, I guess, because, for example, the new at tiny's have the port one wire configuration on the USART...

In addition, the the above thinking, how would someone protect the one wire? Essentially it is directly connected to the "port" of the uC on the 'slave'? This may be dangerous for the uC?

Hope I am thinking in the right directions, and that I am not way off. Any comments, suggestions how to tackle this are more than welcome!

[coderatchance]

Ok, tested the DS2484 with the DS1218B20 sensor on ATTINY1626 via this core and works!
Moving to using the 3216 as slave on the one wire bus. Found this library to be "useful" , however, it does not want to compile on new tinys, indeed, it is old, anyway, this is the error I am getting when compiling...

In file included from /Users/imac/Documents/Arduino/libraries/OneWireSlave/src/OneWireSlave.h:5:0,
                 from /Users/imac/Documents/Arduino/OneWire/One-wire_slave/One_wire_slave/One_wire_slave.ino:1:
/Users/imac/Documents/Arduino/libraries/OneWireSlave/src/utility/LowLevel.h: In constructor 'Pin::Pin()':
/Users/imac/Documents/Arduino/libraries/OneWireSlave/src/utility/LowLevel.h:119:14: warning: 'Pin::mask_' will be initialized after [-Wreorder]
  IO_REG_TYPE mask_;
              ^~~~~
/Users/imac/Documents/Arduino/libraries/OneWireSlave/src/utility/LowLevel.h:118:24: warning:   'volatile uint8_t* Pin::reg_' [-Wreorder]
  volatile IO_REG_TYPE *reg_;
                        ^~~~
/Users/imac/Documents/Arduino/libraries/OneWireSlave/src/utility/LowLevel.h:124:2: warning:   when initialized here [-Wreorder]
  Pin()
  ^~~
/Users/imac/Documents/Arduino/libraries/OneWireSlave/src/utility/LowLevel.h: In member function 'void Pin::attachInterrupt(void (*)(), int)':
/Users/imac/Documents/Arduino/libraries/OneWireSlave/src/utility/LowLevel.h:157:3: error: 'CLEARINTERRUPT' was not declared in this scope
   CLEARINTERRUPT;  // clear any pending interrupt (we want to call the handler only for interrupts happening after it is attached)
   ^~~~~~~~~~~~~~
/Users/imac/Documents/Arduino/libraries/OneWireSlave/src/utility/LowLevel.h:157:3: note: suggested alternative: 'EMPTY_INTERRUPT'
   CLEARINTERRUPT;  // clear any pending interrupt (we want to call the handler only for interrupts happening after it is attached)
   ^~~~~~~~~~~~~~
   EMPTY_INTERRUPT
exit status 1
Error compiling for board ATtiny3226/1626/826/426 w/Optiboot.

Before I start looking around how to fix this, a bit new for me, wondering, if we have a more recent "tiny slave library" ready that could be used?

Looking forward to any ideas , comments!

Best.

PS it compiles well for Arduino UNO

[coderatchance]

Found another OW library does not compile! Missing GPIO.h , probably too old. If any of you has already used that ir any other working library, comments ,etc are much appreciated.

Best.

[coderatchance]

Its funny how many OW libraries is out there, even @SpanceKonde notes that even the original library and its fix is not updated. Indeed, the software solutions either for master or slave are available, however, I did not find one yet that would work with this core.
Have to try few new fingers crossed!

Beat.

[coderatchance]

No luck! The OWI library is not compatible with the megaTinyCore :(

For example, if the Arduino UNO is selected as "board" for which to compile, compiles ok, otherwise, if the megaTineCore the library is found into the folder as incompatible... :/

Really wondering what library to use for the mega tiny core :)

Best.

[coderatchance]

Found another example, it is actually a slave, and here is another one, onewirehub but none compiles on megaTinyCore, indeed, would love to compile it on megaTinyCore , wondering what can we do?

If we are waiting for the author of the library, is this really the only option?

Best.

#include "Arduino.h"
#include "OneWireSlave.h"

// This is the pin that will be used for one-wire data (depending on your arduino model, you are limited to a few choices, because some pins don't have complete interrupt support)
// On Arduino Uno, you can use pin 2 or pin 3
Pin oneWireData(2);

Pin led(13);

// This is the ROM the arduino will respond to, make sure it doesn't conflict with another device
const byte owROM[7] = { 0x28, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02 };

// This sample emulates a DS18B20 device (temperature sensor), so we start by defining the available commands
const byte DS18B20_START_CONVERSION = 0x44;
const byte DS18B20_READ_SCRATCHPAD = 0xBE;
const byte DS18B20_WRITE_SCRATCHPAD = 0x4E;

// TODO:
// - handle configuration (resolution, alarms)

enum DeviceState
{
	DS_WaitingReset,
	DS_WaitingCommand,
	DS_ConvertingTemperature,
	DS_TemperatureConverted,
};
volatile DeviceState state = DS_WaitingReset;

// scratchpad, with the CRC byte at the end
volatile byte scratchpad[9];

volatile unsigned long conversionStartTime = 0;

// This function will be called each time the OneWire library has an event to notify (reset, error, byte received)
void owReceive(OneWireSlave::ReceiveEvent evt, byte data);

void setup()
{
	led.outputMode();
	led.writeLow();

	// Setup the OneWire library
	OWSlave.setReceiveCallback(&owReceive);
	OWSlave.begin(owROM, oneWireData.getPinNumber());
}

void loop()
{
	delay(10);

	cli();//disable interrupts
	// Be sure to not block interrupts for too long, OneWire timing is very tight for some operations. 1 or 2 microseconds (yes, microseconds, not milliseconds) can be too much depending on your master controller, but then it's equally unlikely that you block exactly at the moment where it matters.
	// This can be mitigated by using error checking and retry in your high-level communication protocol. A good thing to do anyway.
	DeviceState localState = state;
	unsigned long localConversionStartTime = conversionStartTime;
	sei();//enable interrupts

	if (localState == DS_ConvertingTemperature && millis() > localConversionStartTime + 750)
	{
		float temperature = 42.0f; // here you could plug any logic you want to return the emulated temperature
		int16_t raw = (int16_t)(temperature * 16.0f + 0.5f);

		byte data[9];
		data[0] = (byte)raw;
		data[1] = (byte)(raw >> 8);
		for (int i = 2; i < 8; ++i)
			data[i] = 0;
		data[8] = OWSlave.crc8(data, 8);

		cli();
		memcpy((void*)scratchpad, data, 9);
		state = DS_TemperatureConverted;
		OWSlave.beginWriteBit(1, true); // now that conversion is finished, start sending ones until reset
		sei();
	}
}

void owReceive(OneWireSlave::ReceiveEvent evt, byte data)
{
	switch (evt)
	{
	case OneWireSlave::RE_Byte:
		switch (state)
		{
		case DS_WaitingCommand:
			switch (data)
			{
			case DS18B20_START_CONVERSION:
				state = DS_ConvertingTemperature;
				conversionStartTime = millis();
				OWSlave.beginWriteBit(0, true); // send zeros as long as the conversion is not finished
				break;

			case DS18B20_READ_SCRATCHPAD:
				state = DS_WaitingReset;
				OWSlave.beginWrite((const byte*)scratchpad, 9, 0);
				break;

			case DS18B20_WRITE_SCRATCHPAD:
				
				break;
			}
			break;
		}
		break;

	case OneWireSlave::RE_Reset:
		state = DS_WaitingCommand;
		break;

	case OneWireSlave::RE_Error:
		state = DS_WaitingReset;
		break;
	}
}

[SpenceKonde]

What's wrong with the version of the other library that I hacked up?

The only thing different between classic and modern parts from the perspective of a one-wire driver going to be direct pin I/O, which while not the same is closely analogous.

Onewirehub's code would be easy to adapt, I think, but what error are you getting on compile?

For OWI, I suspect the library is compatible, or could be made so with very little effort; what I'm having trouble with is finding where the substantive code is in there. Can you find it?

It's either compatible but for something somewhere that says it's compatible with the "avr" architecture, or it needs simple changes made. OneWire, unless you're doing wacky stuff, . I looked at half a dozen files, and didn't see a single register name - somewhere they've got to have some low level code right? Probably just simple pin i/o stuff that's cookbook to apply.

But, I can't find where on that OWI repo the jewlery is hidden...

The main reason nobody updates the libraries isthat they aren't interested in and don't use modern AVRs, which is a shame. But they don't havr any, are happy with what they are using and would these freaks (us, or at least me) using whackjob processors would just stick to 328P's and stop bothering them about wierd parts they'll never use.