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

[iinnovations]

Now we have:

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

I'd be happy to update the toolchain. I just grabbed what was in the deb repos. Where should I grab an updated package from?

Colin

[iinnovations]

I did chown, but I thought I saw a perms issue on something outside of
the owslave and didn't want to futz with it. Same error without sudo on
pgm_ptr_near however.

Colin

On 9/1/2015 11:02 AM, Matthias Urlichs wrote:

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

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

[smurfix]

On 01.09.2015 20:02, Interface Innovations wrote:

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

Please send me a copy of your avr/pgmspace.h. Should be in
/usr/lib/avr/include or thereabouts.

-- Matthias Urlichs

[iinnovations]

https://interfaceinnovations.org/temp/pgmspace.h

On 9/1/2015 11:31 AM, Matthias Urlichs wrote:

On 01.09.2015 20:02, Interface Innovations wrote:

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

Please send me a copy of your avr/pgmspace.h. Should be in
/usr/lib/avr/include or thereabouts.

-- Matthias Urlichs

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

[iinnovations]

Same error on new version of WinAVR with Python 3.4. Fresh download,
using world.cfg test85.

Colin

On 9/1/2015 11:31 AM, Matthias Urlichs wrote:

On 01.09.2015 20:02, Interface Innovations wrote:

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

Please send me a copy of your avr/pgmspace.h. Should be in
/usr/lib/avr/include or thereabouts.

-- Matthias Urlichs

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

[iinnovations]

Ok, so my pgmspace.h was very old. I replaced it with what I found here: http://www.nongnu.org/avr-libc/user-manual/pgmspace_8h_source.html

Seems to contain the macro that was not found, but I still receive the same error when I attempt compile. This is making me feel pretty dumb.

C

[iinnovations]

Tried on yet another ubuntu machine:

/home/colin/avr/owslave/moat.c:120: undefined reference to `pgm_read_ptr_near'

What shall I do?

[iinnovations]

Alright. I must confess I haven't compiled and linked c in a decade, so this is all slowly coming back. First, for whatever reason, the pgmspace.h file was not being loaded in the pgm.h workaround. Don't know why. I added another block in pgm.h to include the pgm_read_ptr_near definition, and it now compiles. I still don't understand why this is the case. Where are these definitions supposed to be normally? And why wasn't pgmspace.h being loaded as requested?

C

[smurfix]

On 03.09.2015 22:41, Interface Innovations wrote:

And why wasn't pgmspace.h being loaded as requested?

This issue is not the place to explain C include file handling.

I'll implement a workaround for too-old avr/pgmspace.h.

-- Matthias Urlichs

[iinnovations]

Fair enough. Please feel free to email me off list at
myfirstname.mylastname@interfaceinnovations.org and we can take this
offline.

Also not the place here, but compile and burn does not work on windows
(as expected, commands are written for shell). I copied the commands
issued to avrdude, but am not sure where and what the tempfile is and if
it's necessary. I also consistently get an hfuse verification error on
write. Not sure if these two items are related, but again I still don't
have a functional 1Wire slave.

Colin

On 9/3/2015 8:51 PM, Matthias Urlichs wrote:

On 03.09.2015 22:41, Interface Innovations wrote:

And why wasn't pgmspace.h being loaded as requested?

This issue is not the place to explain C include file handling.

I'll implement a workaround for too-old avr/pgmspace.h.

-- Matthias Urlichs

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