setenv for Windows

Jim:

I have the misfortune of needing both the 9.1 and 9.2 versions of the Xilinx Platform Studio (XPS) development tools in Windows XP. They're not compatible, but I have designs that require IP and software from each version.

Both versions of XPS are installed on my workstation, and I need an easy way to switch between them without manually changing the path and environmental settings to work with either version.

I found one archived undocumented "setenv.exe" program on the web, but hesitated to use it without knowing what was really going on...

Rory wrote the following C# console application in a few minutes. You can build it yourself as a Console Application using Visual Studio.

using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication5
{
class Program
{
static void Main(string[] args)
{
try {
if (args.Length > 0){

Environment.SetEnvironmentVariable(args[0], args[1],
EnvironmentVariableTarget.Machine);
Console.WriteLine("Set command executed; open a new shell to verify");
}
else{
Console.WriteLine("USE:");
Console.WriteLine(" ");
}
}//try
catch (Exception e){
Console.WriteLine("Does this shell have admin permissions?");
Console.WriteLine(e);
}
}//Main
}//class
}//ns

Once built, put the resulting .exe in a directory contained in your path (i.e. Windows\System32).
The format from the command shell is "setenv attribute value"


Caveats / Notes:

Be careful!
- This code will modify registry entries for your environmental variables. Make sure to back up your environment first! (i.e "set > setBackup.txt")...

Also note:
- For some reason, I encountered an interaction between the cygwin installation and this setenv program; I had to manually include the path to cygwin\bin in the .bat files used in conjunction with the program before Xilinx XPS could be launched.

- You have to open another console window and type "set" to verify that your change has been made; the change will not be reflected in your current console window.

- This applies to XP, not Vista. I'm not using 10.1 yet...

I created a couple of .bat files that can be invoked from the cmd line, to swap back & forth between the two Xilinx development environments:

- typing "set > setenv9x.bat" will create a .bat file that you can modify to point to 9.1 variables; here's what the Xilinx portions of that batch file look like based on my installation:

setenv91.bat (excluding complete path info):

setenv LMC_HOME C:\Xil\Xil91\smartmodel\nt\installed_nt
setenv Path C:\Xil\Xil91edk\bin\nt;C:\Xil\XIl91edk\cygwin\bin;C:\Xil\Xil91\bin\nt; .....
setenv XILINX C:\Xil\Xil91
setenv XILINX_EDK C:\Xil\Xil91edk

Likewise for my 9.2 installation:

setenv92.bat (excluding complete path info):

setenv LMC_HOME C:\Xil\Xil92\smartmodel\nt\installed_nt
setenv Path C:\Xil\Xil92edk\bin\nt;C:\Xil\XIl92edk\cygwin\bin;C:\Xil\Xil92\bin\nt; ......
setenv XILINX C:\Xil\Xil92
setenv XILINX_EDK C:\Xil\Xil92edk

A twitter style application to interface to your applications

Rory:
One morning while creating an invoice and looking back over the timesheet for the software consulting I had been doing I noticed that I had forgot to enter my time for one day a week earlier. If only I had a simple way to enter my time daily. How about a Twitter style application - I could send an instant message that would automatically update our time keeping system with the date, duration, and description of the work I had done.

The Windows Service Architecture:




This program consists of a Windows Service that is running while our Windows Server is active. The service is using the DotMSN to listen for instant messages.

The plugin architecture: This system is extensible through a set of plug-ins that implement one function: MessageRecieved(string text). The Windows service will only load plug-ins that implement that function by inheriting the following interface:

using System;

namespace ActionPlugin.Common

{

///

/// Interface for the MessengerService plugins. Each plug-in that is

/// developed for the MessengerService must implement this interface.

/// </summary>

public interface IMessengerPlugin

{

/// <summary>

/// Authentication method

/// </summary>

bool MessageReceived( string text );

}

/// <summary>

/// This class allows metadata to be defined that

/// identifies the class that implements the

/// IMessengerPlugin interface and will be loaded

/// by main application.

/// </summary>

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = true)]

public sealed class CommonMessengerPluginAttribute : Attribute

{

}

}

When a text message is received all loaded plug-ins are notified through there MessageRecieved function. Each individual plug-in parses the message and applies a specific behavior using the message data.

For example:
If the text message read "3h rhallman worked on C# develpment" then the timekeeping plugin would recognize that this was a timekeeping entry for the user rhallman who worked 3 hours on C# development and make an entry into the timekeeping system.

If the text message that the Windows service recieved read "Movie Add rhallman Superbad" the timekeeping plugin would discard the message since it is not in a 'timekeeping format' and the netflix plugin would read the message and Superbad to the movie list for rhallman (Keep an eye out for our blog on the upcoming Netflix API.

Conclusion:
This Twitter like technique can be helpful in many real world situations and with plugin architectures you can fully leverage this technique for your business or personal use.

kbhit() equivalent in Windows MFC (VS 6.0)

Jim:

I'm just blogging this because it took me too long to find it... I needed to be able to break out of a loop by pressing a key; the example below uses the escape key. This block is within a larger loop. It samples the keyboard every 100 operations as bCount is incremented:

if(!(bCount%100)){

keyData = GetAsyncKeyState(VK_ESCAPE); //ESC KEY
if(keyData) {
break;
}
}

See the following references:

http://msdn2.microsoft.com/en-us/library/ms646293.aspx
http://msdn2.microsoft.com/en-us/library/ms645540(VS.85).aspx

UDP Checksums in Embedded, Linux, and Windows Systems

Jim:


Background:

I'm currently developing embedded and application software in order to stream large quantities of data between an embedded system (Avnet Fx-12 Mini Module) and a Host PC System. The embedded software is based on a Xilinx 9.1 Gigabit Ethernet reference design. This reference design sends and receives raw Ethernet frames by various methods - polled mode, interrupt driven, and scatter/gather DMA; but to be usable with PCs at the application layer, it must implement a standard protocol. Due to speed and resource requirements, I chose UDP.

The User Datagram Protocol (UDP) is an "open loop", session-less means for networked device communication. UDP is open loop in the sense that it does not guarantee that the data being sent will ever arrive at its destination; using UDP is like sending junk mail via the postal system. One "assumes" that the letter will arrive at its destination; if not, the sender will not be notified, and the information will be discarded.

UDP is session-less in the sense that there is no interaction between the sender and receiver to ensure the integrity of the communication link as there is with TCP. An analogy here would be a phone call between two people.... The sender dials the recipient's number; a conversation only ensues if the recipient answers the phone; both parties (typically) decide when to terminate the conversation.

The relative simplicity of the UDP protocol would make it an ideal choice for high-speed data transfer in low-end embedded systems - if it weren't for the UDP checksum calculation requirement.

The Ethernet, IP, and UDP Layers

There are too many details to describe here; but in summary:

• Each UDP packet is encapsulated first by Internet Protocol (IP) information, and then by Ethernet information.
  
• At each of these layers, there is a means to determine the integrity of the data being transmitted:

• At the Ethernet Frame(lowest) layer, the hardware ensures data integrity by validating (or generating) a checksum on the entire Ethernet frame.
• At the IP layer, the sender must calculate the checksum of the IP header portion of the data being transmitted. Because the data in this layer is small, the processing overhead is not excessive.
  
• At the UDP layer, things get interesting.

UDP Packet Processing

In theory, every UDP packet sent by an embedded system contains a checksum on the UDP portion of the data in the packet. This checksum is then used by the recipient to validate the integrity of the UDP data in the packet - the UDP payload.

In practice, the UDP checksum is calculated in two ways. In higher-end systems, special hardware and drivers offload the UDP payload checksum calculation, and inserts the checksum value into the UDP packet. But in lower-end embedded systems, the checksum must be calculated in software. This adds a huge processing burden to the system. It can turn a data "stream" from an embedded system into a trickle.


Eliminating UDP Checksum Calculations

What happens if we don't perform the checksum calculation? RFC 1122 states the following:

  4.1.3.4  UDP Checksums

       A host MUST implement the facility to generate and validate
       UDP checksums.  An application MAY optionally be able to
       control whether a UDP checksum will be generated, but it
       MUST default to checksumming on.

       If a UDP datagram is received with a checksum that is non-
       zero and invalid, UDP MUST silently discard the datagram.
       An application MAY optionally be able to control whether UDP
       datagrams without checksums should be discarded or passed to
       the application.

So, as long as I set the UDP checksum field to zero, everything should be fine, right? Here's what I discovered in practice:

1. I typically use Ethereal to debug network traffic; with UDP checksums disabled, Ethereal showed all traffic being transmitted & received as expected. This applied in Linux (Fedora 8 via Wireshark), and Windows XP.
2. In Windows XP, the checksum-less UDP packets vanished. Surprise. Packet sniffers use their own stacks. Windows elects to "silently discard" UDP packets with checksums set to zero. Try finding this documented somewhere.
3. In Linux (Fedora 8, at least) the checksum-less UDP packets are accessible at the application layer.

Conclusion

Zero-checksum UDP packets are ideal for streaming large quantities of data from embedded systems to Linux Hosts. Windows XP cannot be used to receive this data stream. If there is a way to disable the "silently discard" behavior of the Win32 stack, I have yet to find it.

Word SaveCopyAs

Rory:

Background:

While writing C# based Add-in components for Office 2003 I noticed that the SaveCopyAs function that works so well in Excel, PowerPoint, Outlook, etc was absent from the Word interop assembly. After digging around for hours I found the following solution.

Solution:

public void SaveCopyAs(Word.Document wordDoc)

{

string fileName = TempFolderPath + @"\" + wordDoc.Name;

object saveFormat = Word.WdSaveFormat.wdFormatDocument;

if (Path.GetExtension(fileName).ToLower() != ".doc")

{

fileName += ".doc";

}

// There is no SaveCopyAs function in the ActiveDocument API

// Here is the workaround for that problem

object index = 1;

wordDoc.HTMLProject.HTMLProjectItems.Item(ref index).SaveCopyAs(fileName);

}

wordDoc.HTMLProject.HTMLProjectItems.Item(ref index).SaveCopyAs("c:\\1.doc");

5 static IP addresses that I wish I could use

Rory:

Background:

As a small software development company we host many the applications that we develop in our lab on in house servers. Many of these applications require large databases and high bandwidth that would make off site hosting or collocation cost prohibitive. Recently we bought five additional static IP addresses from our Internet Service Provider to host our growing number of websites / applications.

We knew that we could use those five IP addresses to host other applications and websites, but for now, we want to host all of the websites on one server. This post will outline the ins and outs of setting up this type of system.

The Modem: At this point we have five IP addresses and one Ethernet wire coming out of the modem.	The Router / Firewall: We need a device that will be able to route all of the IPs to a single location. We want to serve five websites (all on port 80) and protect our server from the internet.	The server: Our web server has a single network card and is running Windows 2003 server.

Starting out we thought we needed an off the shelf router, but we knew that the cheap Linksys router we were currently using would only allow us to assign it one external IP address. After hours of searching we figured out that the ability to assign multiple external IP addresses to a router is call multi-NAT. After more searching and a few calls we also figured out that it was virtually impossible to tell whether a router was capable of multi-NAT. Since a commercial router would break our equipment budget, we started evaluating Smoothwall Linux. Smoothwall is a Linux based firewall that is fully configurable (including multi-NAT).

Setup:

1. Configure the Windows Ethernet card with your five corresponding internal IPs.
(Network - Local Area Network Connection - TCP/IP - Properties) I will assign two addresses for the following example.



2. Install 3 NIC cards into the PC that will become the Smoothwall firewall.

3. Burn Smoothwall installation to a CD and install on the firewall PC.

3. Boot firewall and login as root to setup forwarding of the red interface packets coming in on port 80 to the correct internal IP of the server. Edit the /etc/rc.d/firewall.up to forward the correct packets. Assuming that I want to forward web server requests coming into the firewall's red interface to the green interface, add the following lines to the end of the firewall.up file:

# Add external IPs to the red interface (eth2)
/sbin/ifconfig eth2:19 128.49.41.19 broadcast 128.49.41.255 netmask 255.255.255.0
/sbin/ifconfig eth2:20 128.49.41.20 broadcast 128.49.41.255 netmask 255.255.255.0

# Route RED to GREEN
/sbin/iptables -I PREROUTING -t nat -d 128.49.41.19 -j DNAT --to-destination 192.168.1.19
/sbin/iptables -I PREROUTING -t nat -d 128.49.41.20 -j DNAT --to-destination 192.168.1.20

# Change all web server responses from GREEN to RED
/sbin/iptables -I POSTROUTING -t nat -o $RED_DEV -p tcp -s 192.168.1.19 -j SNAT --to-source 128.49.41.19
/sbin/iptables -I POSTROUTING -t nat -o $RED_DEV -p tcp -s 192.168.1.20 -j SNAT --to-source 128.49.41.20

# Allow port 80 traffic to pass through firewall
/sbin/iptables -I FORWARD -d 192.168.1.19 -i $RED_DEV -o $GREEN_DEV -p tcp --dport 80 -j ACCEPT
/sbin/iptables -I FORWARD -d 192.168.1.20 -i $RED_DEV -o $GREEN_DEV -p tcp --dport 80 -j ACCEPT

Conclusion:

After many attempts to configure the firewall through the web admin, even after adding the MODS for Full Firewall Control and Mutliple IP Addresses I found that configuring the firewall manually was the simplest way to get it working.

References:

http://community.smoothwall.org/forum/viewtopic.php?t=11446
http://community.smoothwall.org/forum/viewtopic.php?t=4820
http://www.smoothwall.org/
http://pigtail.net/LRP/broadcast.html

The Jumbo Ethernet Frames "Standard"

Jim:

Recently, I've been using Xilinx reference design Xapp902 as the basis for a (relatively) high speed Ethernet data transfer project. Xapp902 targets Xilinx's ML403 Evaluation Platform; the platform features the Virtex 4 FX12 device (an embedded Power PC 405 core). (jargon off)

In an attempt to conserve CPU cycles and increase data throughput, I began looking for information on Jumbo Frame implementations.


Brief Background

Data in a Local Area Network is organized hierarchically. An Ethernet or 802.2 Frame is the lowest level of data organization. And while the two are compatible, an Ethernet Frame is not the same thing as an 802.2 Frame.

Eventually, the maximum Ethernet Frame size standardized to 1518 bytes:

- 6 bytes for the destination MAC address
- 6 bytes for the source MAC address
- 2 bytes for length or type information (this is the key difference between Ethernet & 802.2)
- 1500 bytes (maximum) for data
- 4 bytes for a CRC checksum on the Ethernet Frame

At the hardware level, (the MAC and PHY layers), dedicated hardware components are responsible for transmission, reception, and error detection in these frames; however, the System CPU is generally responsible for orchestrating data handling once an entire packet becomes available.

This scheme was fine in the days of 10 Mbit/sec Ethernet, but as network speeds increase, the CPU has less & less time for orchestration, and spends an increasingly higher percentage of its time just handling network traffic. At Gigabit Ethernet speeds, packets arrive 100 times faster than they did with the old 10 Mbit/sec protocol... Enter the Jumbo Frame.

The Jumbo Frame

This problem was recognized years ago. In response, engineers proposed tweaking the meaning of the length/type field in the Ethernet/802.2 frame. They proposed letting the length/type field contain data for Frames > 1500 bytes.

By increasing the Frame size (to approx. 9 KBytes), the network processing burden on the CPU could be reduced proportionately. Makes sense, doesn't it? The problem was that there was already too much networking infrastructure in place by then, and Jumbo Frames were largely incompatible with that infrastructure. Consequently, the Jumbo Frame proposal was rejected.

But, that didn't stop Jumbo Frames from being implemented in systems; they've just been declared as proprietary. A proprietary non-standard standard. Oh boy.

I'm not sure how many non-standard implementations there are out there; in the Xilinx Ethernet device driver code I've seen, there are some values that can be changed in the MAC hardware to allow receipt & transmission of Jumbo Frames. But it looks as if the length/type field must be used to indicate Frame size.

Of course, the resulting packets would non-standard, which means that they could be rejected by other devices on the network. Not good if I need to move data through switches and routers.

Given the hassles described above, I've decided to stick with regular 1518 byte Frames; but, I would like to know if and how other devices and systems are handling Jumbo Frames. Do they just "flip the Jumbo hardware switch" and assume that the length/type field represents the Frame size?

My understanding is that Jumbo Frames are part of the Gigabit Ethernet standard, but I haven't seen anything documenting this.