Re: [Bacnet-developers] Understanding AVR port

[Steve K. <st...@ka...>]

Hi Sonny,

Greetings from the BACnet Object and Services working group meeting in
New York City!

>      Forgive me for creating a new e-mail but I tried to follow-up from my
> previous e-mail dated (01/13/2008) but don't know how to follow-up or reply
> to my e-mail, I can only send e-mail to
> bac...@li....

I have sent you private email about how to reply to message. You are
always welcome to send unsolicited message to this mailing list, even
if you are continuing an older thread.

>      After more readings on the Internet and different bacnet hardware ports
> for (i.e. PIC, AT91SAM, rtos32, etc.) I see sometimes comments like
> photocell input but after reading all the relevant files that I never really
> see a conversion for the photocell or any analog input.  So what I am
> understanding is that bacnet stack 0.4.2 is just that a stack and for some
> services who is, i am that does not require an actual hardware i/o it's fine
> to response.

Yes, the software is just a software stack that requires no underlying
I/O hardware, and the demo applications (other than some of the
specific port demo applications) don't actually change I/O.

> However, when there is an actual hardware i/o (i.e. analog or
> digital i/o) that the implementor (me I think) will do the actual coding.

Yes, that is correct.  Sometimes a developer will want to use the
values stored in the demo/object/xx.c object property, or sometimes
they will replace the demo/object/xx.c with their own BACnet object
code that reads/writes to their existing product properties.

> So I start building the hardware part Linux with rs-232 to rs-485 converter
> and a couple of AVR 168 with rs-485 and  I'm planning to use the MSTP
> protocol.

[snip]

>      If what I'm thinking is correct the actual activation of the hardware
> is done in the handler service that the implementor added (binary output in
> the case above).
>
>      Does this make sense?

Yes, the activation can be done in the handler.  In the demo
applications of this BACnet stack, the datalink layer passes the
message to ndpu.c, which calls apdu.c , which calls the correct
demo/handler/xx.c handler, which in turn calls the demo/object/xx.c
object file for ReadProperty encoding or WriteProperty handling.

Although the BACnet Stack at SourceForge is written for embedded
devices, it is certainly not optimized for tiny devices.  It was my
intent that someone would be able to review the code and be able to
see how things happen, and to be able to learn about BACnet.

I was happy that the BACnet Stack at SourceForge was able to just fit
into the ATmega168 using the GNU AVR compiler with ReadProperty,
WhoIs, I-Am services and Device and 9 Analog Value objects, and for
the most part, the core files of the stack were unaltered, and the
architecture was unaltered.  I have also compiled that same project
using the IAR AVR compiler, and here are the size differences:

GCC AVR:
Program:   15574 bytes (95.1% Full) (.text + .data + .bootloader)
Data:        498 bytes (48.6% Full) (.data + .bss + .noinit)

IAR AVR:
 10 055 bytes of CODE memory (+ 36 range fill )
    553 bytes of DATA memory (+ 24 absolute )

That said, if you want to use the demo/atmega168/ demo project as is,
note that it currently does not include WriteProperty service, which
it sounds like something you want.  The reason that it does not
include WriteProperty service is that it didn't fit into the ATmega168
using the GCC AVR compiler with the existing BACnet Stack core source
code.  You would need to either optimize the code or change compilers
(i.e. IAR AVR) which might give you better code optimization.

Best Regards,

Steve
-- 
http://steve.kargs.net/