With my "ftdi" branch now merged to master, I'm picking this up again, 5
months since I wrote the last message below.
Any thoughts on the F0 family code, or other reasons for not merging?
On 10/11/15 20:10, Johan Ström wrote:
> Hi,
>
> a ticket was opened a few days ago regarding merging the "m
On 22.11.2015 17:03, Matthias Urlichs wrote:
> bah. Sorry about that. Will fix ASAP.
Fix pushed.
-- Matthias
--
___
Owfs-developers mailing list
Owfs-developers@lists.sourcefo
On 22.11.2015 00:18, Colin Reese wrote:
> Looks like same error:
>
> ./configure: line 16287: syntax error near unexpected token `LIBUSB,'
> ./configure: line 16287: ` PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
> 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'
If you even have "PKG_CHECK_MODULES" in
On 22.11.2015 02:42, Colin Reese wrote:
> Now this error on make on armhf:
>
> In file included from ../include/ow_devices.h:56:0,
> from ow_daemon.c:14:
> ../include/ow_moat.h:93:1: error: expected identifier before '<<' token
bah. Sorry about that. Will fix ASAP.
--
Now this error on make on armhf:
In file included from ../include/ow_devices.h:56:0,
from ow_daemon.c:14:
../include/ow_moat.h:93:1: error: expected identifier before '<<' token
../include/ow_moat.h:104:20: warning: 's_names' defined but not used
[-Wunused-variable]
Makefile:100
Interestingly, config runs fine on my Raspbian armhf. I'm attempting a
make right now.
C
On 11/21/2015 5:16 PM, Gregg Levine wrote:
> Hello!
> Aren't we fighting with the moat monsters here regarding the error?
> Why not examine the entire method behind how the token is created. In
> fact how's
Hello!
Aren't we fighting with the moat monsters here regarding the error?
Why not examine the entire method behind how the token is created. In
fact how's the entire configuration script written? That should answer
it.
Meanwhile where's Paul, I'm surprised he hasn't commented by now.
-
Gregg
Looks like same error:
./configure: line 16287: syntax error near unexpected token `LIBUSB,'
./configure: line 16287: ` PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
0.9.1, ENABLE_USB=true,ENABLE_USB=false)'
C
On 11/20/2015 10:46 PM, Colin Reese wrote:
standard owfs builds fine on amhf debian,
On 21.11.2015 07:46, Colin Reese wrote:
> standard owfs builds fine on amhf debian, with owfs-moat results
> previously reported.
>
> On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat
> gives:
>
MoaT patch is based on 3.1, which has/had some issues with libusb.
I have pushe
standard owfs builds fine on amhf debian, with owfs-moat results
previously reported.
On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat
gives:
./configure: line 16305: syntax error near unexpected token `LIBUSB,'
./configure: line 16305: ` PKG_CHECK_MODULES(LIBUSB,
On 15.11.2015 19:32, Colin Reese wrote:
> What about changing port mode, e.g. digital, analog, pwm, pull-ups, etc?
Pullup etc. shouldn't be a problem, just needs some owfs support to be
useable. digital/analog, PWM etc. would require some slave code update
as currently the array sizes are fixed. I
That's not moat-related, nor owfs-related: "Internal compiler error".
I'd check for updates on your env, or change Linux dist or something.
For the record, line 476 of ow_moat.c is
static ZERO_OR_ERROR FS_r_alarm_status(struct one_wire_query *owq)
i.e nothing fancy at all.
On 16/11/15 01:10, C
After bootstrap and configure, I get the following on make:
ow_moat.c:476:22: internal compiler error: in set_lattice_value, at
tree-ssa-ccp.c:457
C
On 11/13/2015 11:50 AM, Johan Ström wrote:
Just sending F2 does not work, no. You need to send F2, then two more
bytes identifying what you wa
What about changing port mode, e.g. digital, analog, pwm, pull-ups, etc? Will
this be possible via owfs? Uart read/write would be great too.
I'm happy to write my own wrapper in Python (and still use 2.7 for package
compatibility) as long as the basic functions are supported via owfs. Even
rea
On 13.11.2015 20:50, Johan Ström wrote:
> Just sending F2 does not work, no. You need to send F2, then two more
> bytes identifying what you want to read For example, sending F2, 04, 01
> and then two read timeslots would give you the return value 01 0x where
> the last x indicates the value of po
Trying again since the my message yesterday got moderated due to size..
04 from the m_type enum
(https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/include/ow_moat.h#L40)
You will also see in generated file device/$TARGET/_def.h that "port" is
the 4th define (counting from 0. This is in
Great. So last question:
Where did the information below come from regarding 04 and 01 bytes?
I'll gladly dig through that part!
I am good to go with git (https://github.com/iinnovations)
I'll give the owfs a build and throw it on a machine and see what I see.
Thanks for the help!
C
On 11/1
Just sending F2 does not work, no. You need to send F2, then two more
bytes identifying what you want to read For example, sending F2, 04, 01
and then two read timeslots would give you the return value 01 0x where
the last x indicates the value of port 1. (Unless I got something wrong
here.. b
Thanks Johan,
My goal isn't to write an alternate master -- I just want to use the
Atmega328 as a 1Wire slave, reading the ports (and preferably
configuring them). My understanding is that most of this legwork is
done, but that the support isn't merged into owfs just yet.
In the meantime, I
Not sure if there is any good docs on this yet, don't think so, and the
code has a quite a few "clever tricks" which minimizes size & enhances
customability but makes it a bit tricky to follow for the uninitiated.
Basically, all reads & writes (owfs-side) goes through OW_r_std and
OW_w_std, an
To be clear, I'm using the TMBlockStream function in the TMEX API:
http://files.maximintegrated.com/sia_bu/softdev/owdocs/Docs/TMEX/bloc0zou.html
C
On 11/13/2015 10:26 AM, Colin Reese wrote:
Super.
So MOAT read and write are F2 and F4, respectively. Is there yet any
documentation on what th
Super.
So MOAT read and write are F2 and F4, respectively. Is there yet any
documentation on what these will return by default, what additional data
are required to specify what to read and write, and how to specify such
details in the config file? I apologize if this is clear from the code;
Ah, using the latest code is always a good start.. :)
Yes, the 'moat' device uses custom ROM commands. To communicate with the
moat from any other non-owfs master you'd need to implement the custom
ROM commands there.
See
https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/c/ow_moat.c
for d
First, I just noticed the HOWTO is much improved and has some details
about using the uart. Thanks Matthias.
I assume all of the data appears somewhat transparently via owfs as
indicated in the HOWTO, which is how I plan to use it typically. Using
other code, e.g. through LabVIEW or otherwise,
Finally got it. Built it on a machine without the updated code. Thanks.
C
On 11/12/2015 9:06 PM, Colin Reese wrote:
Understood.
From what I can see, 1Wire should be on INT0 (D2) per 152 in
world.cfg. With the world.cfg below, everything compiles fine and
loads from my USBTiny. I verified my
Understood.
From what I can see, 1Wire should be on INT0 (D2) per 152 in world.cfg.
With the world.cfg below, everything compiles fine and loads from my
USBTiny. I verified my fuses are xFF, xDE, x05, which looks good. I
still don't see anything on my DS9490R.
One more thing -- anybody know
You'd have to step through the "_ref" in your def, and the "default"
section in world.cfg to found out any defaults.
In my example, I only have specifically 'ref: mcu.mega328'. Checking the
mcu.mega328 section in world.cfg (included) we do not have a f_cpu def.
So continue to global 'defaults'
I understand, but if not already defined, what is the default value? Or,
why is this not defined in the code already?
On Thu, Nov 12, 2015 at 9:13 AM, Johan Ström wrote:
> Yes, the f_cpu define only controls timing calculations, which must match
> the clock speed. If incorrectly configured, it w
Yes, the f_cpu define only controls timing calculations, which must
match the clock speed. If incorrectly configured, it won't be able to
talk on the 1wire net.
On 12/11/15 18:04, Colin Reese wrote:
I see this in main:
#elif defined (__AVR_ATmega168__) || defined (__AVR_ATmega88__) ||
define
I see this in main:
#elif defined (__AVR_ATmega168__) || defined (__AVR_ATmega88__) ||
defined(__AVR_ATmega328__)// Clock is set via fuse
is the f_cpu definition necessary here?
C
On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström wrote:
> As long as your built it for 16MHz it should probably be co
As long as your built it for 16MHz it should probably be compatible (I'm
not familiar with any specific fuses the m328 might have).
Thus, f_cpu: 1600
On 12/11/15 03:39, Colin Reese wrote:
> So to avoid trying to get WinAVR to behave, on a windows machine with
> avrdude I would do something l
So to avoid trying to get WinAVR to behave, on a windows machine with
avrdude I would do something like:
avrdude -c usbtiny -p m328p -U flash:w:image.hex -U eeprom:w:eprom.hex
That should do the trick? Do I really need to set the fuses? I have it
set up as external 16Mhz. I assume this is compa
The header files seem to be installed to primarily:
/usr/lib/avr/include/avr
Cat/grep on all in the directory yields nothing for pgm_read_ptr, and a
number of functions, e.g. pgm_read_byte, pgm_read_word, float, etc.,
which are all present in pgmspace.h
I included the code provided by Matthias
On 11.11.2015 20:45, Colin Reese wrote:
> In the meantime, getting an updated libc from elsewhere than the apt repos is
> an option?
I'd be wary of compiler/libc or libc/header incompatibilities when
upgrading partially. IMHO it'd be safer to examine your existing
pgmspace.h and add a patch to Mo
In the meantime, getting an updated libc from elsewhere than the apt repos is
an option?
C
> On Nov 11, 2015, at 11:40 AM, Matthias Urlichs wrote:
>
>> On 11.11.2015 13:42, Johan Ström wrote:
>> Also try to search for pgm_read_ptr_near and/or pgm_read* in the include
>> files which your avr-li
Thanks for the update.
If i can get these working I'll be using them all over for io port expanders in
controls panels. I use ds2408s with optos, but they're expensive and don't have
analog (among other things). I will help wherever I can, but I'm certainly a
stronger integrator and coder in J
On 11.11.2015 13:42, Johan Ström wrote:
> Also try to search for pgm_read_ptr_near and/or pgm_read* in the include
> files which your avr-libc package installs (check with your package
> manager how to list installed files).
There seem to be some somewhat-incompatible and probably incompletely
upd
On 10.11.2015 20:32, Colin Reese wrote:
> I've been limping along with code for atmega328 from elsewhere and would love
> if someone has time to help me port it.
The devices I'm using right now use atmega88/168/328 ICs.
My personal use for this is home automation (heating control / switches
/ te
It would help if you can post specific version numbers of avr-libc (or
whatever it is named in Ubuntu), and winavr.
Also try to search for pgm_read_ptr_near and/or pgm_read* in the include
files which your avr-libc package installs (check with your package
manager how to list installed files).
On
I have tried on deb Linux (Ubuntu 14.04) with apt distros, also winavr. Just
downloaded owslave and tried fresh with the exact cfg you listed.
C
> On Nov 11, 2015, at 1:57 AM, Johan Ström wrote:
>
> Hm, first this was commited:
> https://github.com/M-o-a-T/owslave/commit/960a7decb26ee1aa792ef
Hm, first this was commited:
https://github.com/M-o-a-T/owslave/commit/960a7decb26ee1aa792ef41400c306ec563e77ab
but then this:
https://github.com/M-o-a-T/owslave/commit/e573863d5a62072945dd6c07eb4e6109a6108c16
Are you perhaps using either old revision of the owslave code, or
perhaps old AVR-libc
I get a number of errors on compile similar to:
/moat.c:182: undefined reference to `pgm_read_ptr_near'
C
On 11/10/2015 1:07 PM, Johan Ström wrote:
> _include: world.cfg
> devices:
> _default:
> _ref: defaults.target.m88
> types:
> _ref: defaults.types
> code: []
>
I don't have a m328 to test with, but it builds fine:
I created this local.cfg (based on sample cfg):
--
_include: world.cfg
devices:
_default:
_ref: defaults.target.m88
types:
_ref: defaults.types
code: []
m328test:
_ref: mcu.mega328
defs:
f_cpu: 8
I will look again as I did not see this. I did not have success with the attiny
moat. Using another owslave (by youen) I needed to run at 16mhz to get it
working. Rather than rewrite to expose local IO (and other arbitrary values
like serial), my end goal, I'd much rather get moat working.
C
While I haven't tested it myself, there are specific code for mega328
(and 168, 88 and 8), besides tiny84/85 (which is marked "untested for
some time" though).
I've only used it on the mega8 and mega88 so far, running at 8Mhz with
internal oscillator with great success.
On 10/11/15 20:32, Colin
Is this still only for attiny? I've been limping along with code for atmega328
from elsewhere and would love if someone has time to help me port it. I love
the idea.
> On Nov 10, 2015, at 11:10 AM, Johan Ström wrote:
>
> Hi,
>
> a ticket was opened a few days ago regarding merging the "moat"
Hi,
a ticket was opened a few days ago regarding merging the "moat" device
specific owfs code into master:
http://sourceforge.net/p/owfs/feature-requests/9/
Does anyone object that I merge this? I've run this code myself for
months without any issues.
The only reason I can come to think of is
47 matches
Mail list logo
