dev_config.h referenced but not included

[iinnovations]

Hello!

It appears that dev_config.h is referenced by features.h (and elsewhere, I believe), but it not included here in the repo. Where do I find him?

Thanks,
Colin

[iinnovations]

I see now this is generated by the Makefile. I'm trying to get this into the Arduino IDE and onto an ATTiny85. Any help on the easiest way for me to port it?

Thanks,
Colin

[iinnovations]

So after reading all the docs, I get a python error from Cfg.py: RuntimeError: maximum recursion depth exceeded while calling a Python object

C

[smurfix]

On 31.08.2015 00:37, Interface Innovations wrote:

So after reading all the docs, I get a python error from Cfg.py:
RuntimeError: maximum recursion depth exceeded while calling a Python
object

C

I'll need the command you called, your config file, and the actual stack
backtrace.

-- Matthias Urlichs

[iinnovations]

Matthias,

I've tried multiple configs with the same result. Please find one attached.

The command issued here was' make CFG=attiny85config.cfg tinytc
&>makeoutput'

I have a couple other questions:

1. The .o files did not seem to be included in my distro of avr-gcc. I
   copied them from my Win-AVR version into a directory that I added to the
   makefile. I needed to add this directory to CFLAGS to begin with to have
   the header files found to begin compilation. I copied crttn85.o into
   avr25 into this directory to eliminate the not found errors there.
   Shouldn't these be included in avr-gcc?
2. How does one add code to relay arbitrary or translated values as
   1Wire data? For example, if I wanted to scale or combine read values
   into one output variable, or read something over SPI and relay that data?
3. Is the code asynchronous, so that running other code is possible?
4. Are there clock requirements for the slave to communicate properly?
   Is setting the ATTiny85 to 16MHz internal sufficient, for example, or is
   an external clock required? Is the internal 1MHz on an ATMega328P good
   enough? (Is the 328P yet supported?)

Thanks,
Colin

On 8/30/2015 11:43 PM, Matthias Urlichs wrote:

On 31.08.2015 00:37, Interface Innovations wrote:

So after reading all the docs, I get a python error from Cfg.py:
RuntimeError: maximum recursion depth exceeded while calling a Python
object

C

I'll need the command you called, your config file, and the actual stack
backtrace.

-- Matthias Urlichs

—
Reply to this email directly or view it on GitHub
#10 (comment).

[smurfix]

On 31.08.2015 16:17, Interface Innovations wrote:

_include: world.cfg
Would you please attach the file, not paste it? your mailer ate the
leading spaces.

-- Matthias Urlichs

[iinnovations]

I did attach them. It grabbed text and blurged it into the forum here. Why don't we do this:

https://interfaceinnovations.org/temp/makeoutput
https://interfaceinnovations.org/temp/attiny85config.cfg

Colin

[smurfix]

On 01.09.2015 08:06, Interface Innovations wrote:

I did attach them. It grabbed text and blurged it into the forum here.
Why don't we do this:

https://interfaceinnovations.org/temp/makeoutput
https://interfaceinnovations.org/temp/attiny85config.cfg

Colin

—
Reply to this email directly or view it on GitHub
#10 (comment).

Better, thanks.

The current master (75fbf68 on github) compiles for me.

I also had to fix your config file a bit:

. types:

. port: 1

. port:

. 1: B4~*

-- Matthias Urlichs

[smurfix]

Hi,

On 31.08.2015 16:17, Interface Innovations wrote:

1. The .o files did not seem to be included in my distro of avr-gcc.
   They're in the "avr-libc" package on my Debian system.
2. How does one add code to relay arbitrary or translated values as
   1Wire data? For example, if I wanted to scale or combine read values
   into one output variable, or read something over SPI and relay that data?
   Look at adc.c + moat_adc.c for an example. The server-side code is in my
   branch of owfs, in module/owlib/src/c/ow_moat.c ( and
   …/src/include/ow_moat.h).
3. Is the code asynchronous, so that running other code is possible?

The low-level 1wire handling is async, but the main loop is not. You
should use a state machine and limit your time in the main loop to a
millisecond or so (duration of bus reset+presence pulse). Again, adc.c
is a simple but workable example.

1. Are there clock requirements for the slave to communicate properly?
   8MHz is the minimum. 16MHz is much more reliable.

-- Matthias Urlichs

[iinnovations]

Thanks for all the info. Very helpful.

I purged and reinstalled gcc-avr and avr-libc, nuked my owslave directory and pulled from the master. Now different errors, the key ones repeated are of the form:

/home/colin/avr/owslave-master/moat.c:120: undefined reference to `pgm_read_ptr'

https://interfaceinnovations.org/temp/makeoutput2
https://interfaceinnovations.org/temp/attiny85config2.cfg

I am also a bit curious as to why the make begins with a reference to:
MCU:atmega88
MCU_PROG:m88

I assumed that the ref in the config targeted the 85 specifically.

With respect to the port needing to be changed, I read from line 152 in HOWTO that this was the 'basic digital input/output pin', which I assumed means this is where the 1Wire emulation will take place. Hence, I changed this to 3, the pin that I want to connect to the 1Wire bus. If this is an incorrect reading, I still need to know where to specify this, as it is not clear from reading through adc.c, main.c, or several other files where I should specify this (or if it is hardcoded for each device type).

Overall, this looks quite powerful, and I'd be happy to blog about it to help laypeople such as myself to get it up and running. This functionality is certainly very useful.

Cheers,
Colin

[iinnovations]

I likewise tried to call 'sudo make CFG=world.cfg test85' to try the built-in test config with the same pgm_ptr errors listed above.

Colin

[smurfix]

On 01.09.2015 18:21, Interface Innovations wrote:

With respect to the port needing to be changed, I read from line 152
in HOWTO that this was the 'basic digital input/output pin', which I
assumed means this is where the 1Wire emulation will take place.
Hence, I changed this to 3, the pin that I want to connect to the
1Wire bus. If this is an incorrect reading, I still need to know where
to specify this, as it is not clear from reading through adc.c,
main.c, or several other files where I should specify this (or if it
is hardcoded for each device type).

Umm, no. "port: 3" simply says that you have three ports. See line 182.
The 1wire pin is hardcoded (INT0, or B2) because it needs its own
dedicated interrupt. I'll add that to the documentation.

-- Matthias Urlichs

[iinnovations]

Yes, I get that now after reading through world.cfg. It's still a bit
confusing to me, to be honest. When I build the test85 from world.cfg,
it is clearly trying to build a tiny85 MCU, while when I build my test
config, which I thought specified the proper MCU, it was trying to build
an 88.

Colin

On 9/1/2015 10:08 AM, Matthias Urlichs wrote:

On 01.09.2015 18:21, Interface Innovations wrote:

With respect to the port needing to be changed, I read from line 152
in HOWTO that this was the 'basic digital input/output pin', which I
assumed means this is where the 1Wire emulation will take place.
Hence, I changed this to 3, the pin that I want to connect to the
1Wire bus. If this is an incorrect reading, I still need to know where
to specify this, as it is not clear from reading through adc.c,
main.c, or several other files where I should specify this (or if it
is hardcoded for each device type).

Umm, no. "port: 3" simply says that you have three ports. See line 182.
The 1wire pin is hardcoded (INT0, or B2) because it needs its own
dedicated interrupt. I'll add that to the documentation.

-- Matthias Urlichs

—
Reply to this email directly or view it on GitHub
#10 (comment).

[smurfix]

On 01.09.2015 18:21, Interface Innovations wrote:

I am also a bit curious as to why the make begins with a reference to:
MCU:atmega88
MCU_PROG:m88

I assumed that the ref in the config targeted the 85 specifically.

??? my "make" run prints the correct values here.

-- Matthias Urlichs

[smurfix]

On 01.09.2015 18:21, Interface Innovations wrote:

/home/colin/avr/owslave-master/moat.c:120: undefined reference to
`pgm_read_ptr'

You use an older version of the AVR toolchain.

I added workaround in change e573863 -- please try again.

-- Matthias Urlichs

[smurfix]

On 01.09.2015 19:02, Interface Innovations wrote:

I likewise tried to call 'sudo make CFG=world.cfg test85' to try the
built-in test config with the same pgm_ptr errors listed above.

Please do NOT use "sudo make". There is no reason whatsoever to do that.
(Use "sudo chown -R your_user_name ." to fix that.)

-- Matthias Urlichs