Steve’s Software Trek

I drove to the BACnet meetings in nearby Atlanta and Bill photographed my license plate.  We need lofty goals, don’t we?

The BACnet committee met in Salt Lake City at the end of June.  We had a large number of Addenda that had finished public review, and had lots of comments for which to respond.  Salt Lake City had some interesting sites and some street items that I had not seen before.  The “Look” on the pavement, as well as the flags used at some crosswalks.

I attended Mass at Cathedral of the Madeleine on Saturday night.  It was a beautiful church and a thought provoking sermon.

I ate some wonderful food in Salt Lake City, including a fabulous carrot cake at Squatter’s Pub Brewery, and some delightful salmon at Cucina Toscana.

Our fun BACnet committee and working groups met in Germantown at the end of April for a week. The weather was perfect, and the Montgomery College Germantown Campus was beautiful and lively.

We had our traditional Tuesday night BACnet dinner at Dogfish Head Brewery.

Most of the working groups met.

I was invited to attend Sharkfest ‘08, a conference for Wireshark users and developers, held March 31-April 2 at Foothill College in Los Altos Hills, California. I had a great time, and am so grateful that Gerald invited me to attend. I attended as a Wireshark developer since I actively maintain the BACnet dissector. I went to the conference with several goals in mind:

1. Figure out how to do BACnet segmentation
2. Figure out how to get BACnet MS/TP into libpcap/winpcap.
3. Add a couple of BACnet dissector enhancements to Wireshark.
4. Learn about using Wireshark for problem network analysis.

I attended Laura Chappell’s training sessions, and learned a whole lot about Network analysis and the love-hate relationship between TCP/IP SYN, ACK, and Keepalives (#4 completed). I also wrote some Wireshark code during the classes which I promply submitted (#3 completed). Loris came into the activity center and sat down with my son Joshua and me, and so we discussed how to integrate BACnet MS/TP RS485 from serial port into libpcap/winpcap (#2 completed). On the last day and the last session of the conference, I attended a session by Richard Sharpe about file sharing protocols and learned about Wireshark conversations (#1 completed).

We were treated to an inspiration talk on Tuesday morning by Vint Cerf. After the talk, I went to Laura’s session, and Joshua talked to Vint. Vint signed Joshua’s Half-Life player guide, had photos taken with Vint and Gerald, and the Wireshark crew gave Joshua some swag.

Gerald treated the developers to dinner on Tuesday night at Trader Vic’s. I drove to dinner with Joshua and Jaap Keuter, and learned about PBX systems and Jaap’s passion for skydiving. At dinner I sat next to Ulf Lamping and learned about yet another division of Siemens and about Ulf’s love for motorcycle riding. Guy Harrris and Mike sat across from me.  Joshua ate with Gerald’s wife and daughter, and John Bruno’s wife.

The Foothill College campus was beautiful and on Spring Break. The food was awesome and plentiful.  The people were great!  The Wireshark sessions were helpful.  Maybe I will get to attend next year.

I found a bug in my Atmel AVR ATmega168 port of the BACnet Stack at SourceForge. It was the result of having not read the AVR datasheet close enough. Here is what the datasheet said:

The Transmit Complete (TXCn) Flag bit is set one when the entire frame in the Transmit Shift egister has been shifted out and there are no new data currently present in the transmit buffer. The TXCn Flag bit is automatically cleared when a transmit complete interrupt is executed, or it can be cleared by writing a one to its bit location.

I had initially written the code to clear the TXC0 flag by clearing it, rather than setting it. Since the code could not determine when the end of the transmission occurred, I had added a _delay_us() function from the AVR-GCC library. This is what the AVR-GCC manual says about that function:

In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

Severe code bloat indeed! I had used a non-constant (the Baud Rate) in the delay call, and that resulted in a 4k increase in code size. After fixing the Transmit Complete flag functionality, I was able to remove the _delay_us, and the code size dimimished by 4k. On this 16k device, that means alot!

Statistics for the BACnet Stack at SourceForge on the ATmega168 are as follows:

IAR Atmel AVR C/C++ Compiler V5.10A/W32
10 191 bytes of CODE memory (+ 36 range fill )
775 bytes of DATA memory (+ 24 absolute )

avr-gcc (GCC) 4.2.2 (WinAVR 20071221rc1)
Program: 12052 bytes (73.6% Full)
Data: 481 bytes (47.0% Full)

With all the extra code space, I went on to add more functionality to the demo. The BACnet capabilities include WhoIs, I-Am, ReadProperty, and WriteProperty support. The BACnet objects include a Device object, 10 Binary Value objects, and 10 Analog Value objects. An LED is controlled by Binary Value object instance 0. All required object properties can be retrieved using ReadProperty. The Present_Value property of the Analog Value and Binary Value objects can be written using WriteProperty. The Object_Identifier, Object_Name, Max_Info_Frames, Max_Master, and baud rate (property 9600) of the Device object can be written using WriteProperty.

After adding all that functionality, I learned the hard way about the C-Stack differences between the IAR AVR compiler and the GCC-AVR compiler. The IAR compiler uses a fixed CStack size. If it is not set correctly, the CStack can overflow and cause problems in your code.

The GCC compiler uses the RAM not allocated to variables and text for the C-Stack. That means that the data value reported by the avr-size program is only part of the picture. If the data value is 481 bytes, and the device has 1024 total, then 1024-481=543 bytes are used by the C-Stack. In other words, don’t be fooled by the “47% Full” printed by avr-size and think that you have extra RAM. You might be able to add some more functionality, but certainly leave some RAM (or alot in my case) for the C-Stack. The GCC-AVR has two intrinsic variables for tracking the C-Stack: _end and __stack. These can be used to paint the C-Stack prior to its usage, and monitor the C-Stack during runtime. I added this technique to the demo.

The final statistics on ATmega168 demo of the BACnet Stack at SourceForge:

IAR Atmel AVR C/C++ Compiler V5.10A/W32
12 732 bytes of CODE memory (+ 36 range fill )
955 bytes of DATA memory (+ 24 absolute ) (CStack=0×200)

avr-gcc (GCC) 4.2.2 (WinAVR 20071221rc1)
Program: 15790 bytes (96.4% Full)
Data: 414 bytes (40.4% Full) (CStack=0×262)

Note: The photos are ancient computer memory from The Computer History Museum in Mountain View, California.  I’m visiting the area for the Wireshark Sharkfest ‘08.

Our highly intelligent BACnet committee met in New York City. The discussion centered around Interpretation Requests, Public Review Addendum responses, and revised Public Review Addendum. The Lighting Output object, part of SSPC 135-2004 Addendum i, was approved for its second Public Review.

Many working groups also met on Thursday, Friday, and Sunday. The Lighting Applications working group met on Sunday morning, and we worked on the Color Output object. The Wireless Networking working group met and discussed ways to reduce broadcast packets. The Objects and Services working group met and reviewed addendum comments.

After the Sunday working group meetings, I attended mass at St. Patrick’s Cathedral. It was an awesome church and included a magnificent pipe organ and a number of alcoves.

It was my first visit to New York City. I took a ferry to see the Statue of Liberty Enlightening the World, the full name for the Statue of Liberty. I took a lot of photos, and also sent a photo from my cell phone to my family.

I also toured Ellis Island. It was very touching as I toured the building, rooms, and steps where many families walked through to live in America between 1892 and 1924. A set of steps leading down from the Registration Hall was divided into 3, and was dubbed the “Stairs of Separation.” The steps marked the parting of the way for many family and friends with different destinations. The middle steps led to the islands hospital or detention rooms, while the outer steps were destinations of New York or New Jersey by way of ferry.

I attended the BACnet Interoperability Workshop again this year. The Plugfest was held in Milwaukee. I tested another BACnet Stack at SourceForge enabled device. This time it was an Atmel AVR ATmega168 using the GCC WinAVR compiler. It was utilizing the BACnet MS/TP datalink layer, and had a Device object and 9 Analog Input objects inside. It supported the ReadProperty service, and WhoIs and I-Am services for binding. It had a Maximum APDU size of 128 bytes.
AVR Memory Usage
—————-
Device: atmega168

Program: 16350 bytes (99.8% Full)
(.text + .data + .bootloader)

Data: 630 bytes (61.5% Full)
(.data + .bss + .noinit)

Here is the key that helped me fit the code. I found a GCC compiler and linker directive that allowed all the unused functions and dead code to be removed. I found the directive initially on the GCC M68HC11 FAQ. It saved me from having to split out all the functions into separate files and put them into a single library.

I also met some great folks, some of whom were using the BACnet Stack at SourceForge in their products. I also saw a lot of folks using Wireshark for BACnet protocol analysis. I also got to see a lot of friends that I have made over the years.

Edit: I compiled the project with IAR AVR version 4 compiler and here are the memory usage statistics:

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

I used to analyze BACnet MS/TP RS-485 traffic using an HP54645D 100MHz 2+16 channel mixed signal oscilloscope because it had a deep buffer and MegaZoom which allowed me to see the data and timing of the frames. However, I have a new tool.

Howard introduced me to Digiview. The Digiview tool is a USB based logic analyzer. It permits you to view and decode signals. I set one of the signals to Async Decode, and gave the tool the baud rate, stop bits, parity of the signal. The software shows the logic signal and displays the decoded the data above the signal. The software also has time marker tools and allows you to set multiple time markers.

Using the DigiView tool and software, I am able to analyze BACnet MS/TP timing and frames with ease. I can see exactly how fast each node is responding and how long each node allows for the various BACnet MS/TP frames. I can also see exactly the content of each frame without having to decode the waveforms.

There are other mini logic analyzers on the market such as BitScope, USBee, PicoScope, and the Ant8 Logic Analyzer. Jack Ganssle wrote a review of some of them.

The BACnet committee met in Atlanta at Georgia Tech for their interim fall meeting. We enjoyed some good food at the Park Tavern. Many working groups had productive meetings during the week.

Inspired by Building Bare-Metal ARM Systems with GNU series of articles, I recently ported the BACnet MS/TP datalink layer to an Atmel AT91SAM7S-EK board - an ARM7 processor - using a GCC cross compiler for ARM.

I evaluated GNU Toolchain for ARM, GNU ARM, WinARM, and YAGARTO toolchains on the Windows platform. They all have their merits, but all have some slight differences too. I followed an excellent tutorial by James P. Lynch called Using Open Source Tools for AT91SAM7S Cross Development to get me up and running quickly. Jim used the YAGARTO project as his toolchain.

I used the YAGARTO toolchain and created my own Makefile. Makefiles are an interesting bit of programming that seems to be a lost art. Any of the cross compiler toolchain builds should work with the Makefile with a slight modification to the name of the compiler (one of the differences in each of the various GNU ARM cross compiler projects).

During my travels down the GCC road, I found the GCC-AVR and WinAVR for Atmel AVR series of microcontrollers. I searched for GCC for an 8051. I found the SDCC project - Small Device C Compiler - for Intel 8051, Maxim 80DS390, Zilog Z80 and the Motorola 68HC08. Both projects are also in the Ubuntu Linux repository.  I noticed that the Microchip PIC24 compiler C30 is based on GCC and the source code is available on their website.