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, how would one read this
data? Is there a modified command set?
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 fuses are xFF, xDE, x05, which
looks good. I still don't see anything on my DS9490R.
One more thing -- anybody know what I need to do to select and enable
the debug UART? I can see that the default baudrate is 38400; I just
need to select a port, pin and enable it. I can't quite see what needs
to be defined to do it.
C
_include: world.cfg
devices:
_default:
_ref: defaults.target.m88
types:
_ref: defaults.types
code: []
m328test:
_ref: mcu.mega328
defs:
f_cpu: 16000000
port:
1: B0~
2: B1~
onewire_id: x0f361b8bff8a
On 11/12/2015 12:28 PM, Johan Ström wrote:
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' section, check defs. no f_cpu there
either.
So for this target, there is no "default". In my example, it was
explicitly set to 8Mhz though.
If we would instead use 'ref: defaults.target.m88' we would find _ref
'defaults.target.m8x_base' which contains the f_cpu def.
The reason it is not in code is that world.cfg controls all
dynamic/configurable properties. During build, it will write a
device/$TARGET/dev_config.h which is then included in the actual code.
On 12/11/15 18:17, Colin Reese wrote:
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 <jo...@stromnet.se
<mailto:jo...@stromnet.se>> wrote:
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__)
|| 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
<jo...@stromnet.se> wrote:
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: 16000000
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 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 compatible.
>
> C
>
> On 11/11/2015 12:34 PM, Matthias Urlichs wrote:
>> 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 MoaT that works around not
having the
>> current version of pgmspace.h. (I already tried that,
but apparently not
>> quite successfully.)
>>
>> In fact you might just email your version to me, I can
certainly take a
>> look.
>>
>>
>> -- Matthias Urlichs
>>
>>
>>
------------------------------------------------------------------------------
>> _______________________________________________
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
