In a few days, we’ll be in an industrial automation fair and only available internet connection there will be Wireless. We want to connect our devices to internet there but our devices only have Ethernet port. So we’ll rely on connection sharing of one of these OSes. The problem is that their DHCP servers are acting a bit different than a stock router you’d have.

Windows does not give responses quickly, after my DHCP REQUEST message, it takes a like 1-2 seconds to get ACK message back. And Windows’s DHCP server keeps sending OFFERs and ACKs like crazy for the previously received messages even though an IP address is acquired already. Tweaking the timeouts and making sure my client does not honor OFFERs once that state is passed fixed the issues with Windows’ DHCP server.

However the issue with the Mac was a more subtle one. My device couldn’t acquire IP address at all. I checked if my Windows laptop could get an IP from it and, not surprisingly, it could! My device couldn’t even get an OFFER for its DISCOVER message. I compared Windows’ DISCOVER message with mine to find the differences. There were two differenes:

1. Seconds field
2. Options field

secs 2 Filled in by client, seconds elapsed since client began address acquisition or renewal process.

I don’t see how this affects the behavior but it fixes the issue.

See also previous mistake I made about DHCP.

Cheers

Implementing Expansion Modules support in PLC firmware was pretty easy, since from the eyes of the PLC (Main Device) all the Expansion Modules look like ONE device. It turned out that with LM3S8738 MCU, it is a challenging task to implement Expansion Module communication logic in the Expansion Modules. The reason is that LM3S8738 has RX and TX FIFOs for to be used in SSI but there’s basically no control over the FIFOs. So I was not able to control the SSI peripheral as much as I wanted. Here’s the problem and design principles of the expansion modules.

Basic logic

All devices are connected to a bus and driven by the SSI CLK generated by the  SSI Master which is the Main Device (MD from now on).  When a clock is generated each expansion device  (XD from now on) transmits data to the next XD — except the last XD which transmits data back to MD and completes the loop. For instance in the first clock, MD sent 1 bit to XD A,  XD A sent 1 bit to XD B, XD B sent 1 bit to XD C and XD C sents 1 bit to MD. And all this transmission is enabled when the ENABLE line is LO. When the ENABLE line is HI all the XD’s know that the transmission is over and the last N bytes they received are intended for themselves.

So imagine this hypothetical scenario. Each XD’s message size is 1 byte and 3 XD’s are connected to the MD. For MD to send query to these XDs, it should send 3 bytes. And MD will receive 3 bytes of answers for the previous query. So here’s the work flow;

1. ENABLE line is LO

2. XDs put their answers for the previous query to TX FIFO. (First I need to clear TX FIFO but I can’t — explained below)

3. MD sends 1 byte Query C to XD A.

4. XD A sends Response_n-1A to XD B and puts Query C into its TX FIFO.

5. XD B sends Response_n-1B to XD C and puts Response_n-1A to its TX FIFO.

6. XD C sends Response_n-1C  to MD and puts Response_n-1B to its TX FIFO.

(Note that all steps from 3 to 7 happened simultaneously when MD is sending 1 byte, as required by the nature of SSI. )

7. MD sends 1 byte (Query B) to XD A.

8. XD A sends Query C to XD B and puts Query B to its TX FIFO.

9. XD B sends Responsen-1A to XD C and puts Query C to its TX FIFO.

10. XD C sends Responsen-1B to MD and puts Responsen-1A to TX FIFO.

11. MD sends 1 byte Query A to XD A

12. XD A sends Query B to XD B and puts Query A in its TX FIFO

13. XD B sends Query C to XD C and puts Query B to its TX FIFO.

14. XD C sends Responsen-1A to MD and puts Query C to its TX FIFO.

15. ENABLE line is HI.

16. Each XD looks for the last 1 byte they received and that’s their query to process for the next round.

The Problem

Since XDs don’t know the total number of XDs connected to the bus they don’t know how many bytes they will receive hence they rely on the ENABLE line. Whent he ENABLE line is HI, the last byte they got is their query. Since they don’t know the total frame length (encapsulated by the ENABLE line) they don’t know when not to put data to TX FIFO. So there’s a garbage byte in the TX FIFO when the transmission is over.

Here’re the things I could do.

1. Clear the TX FIFO each time ENABLE is LO, just before actual transmission begins — there’s no clean way to do this in LM3S8738 apparently.

2. Introduce another protocol element to tell XDs the size of the bus, so they’ll know when not to put garbage data to TX FIFO.

3. Put XDs into SSI Master mode for a very short time to clean the TX FIFO. (I’m doing this right now, it works but it is not elegant).

4. Disable/Enable SSI peripheral to reset the TX FIFO. (I could not manage to do SysCtlPeripheralDisable, the CPU hangs, probably gets into a BUS FAULT).

Conclusion

In XDs we implemented with low level 8-bit MCUs, it has more granular control over the SSI peripheral — which is simpler of course. There’s no TX/RX FIFO, and you can just overwrite the outstanding data to be sent. So when ENABLED line is low, you just put your answer there and it overwrites the garbage, and you are done with it.

With LM3S8738 I’m still looking for more elegant ways to tackle this problem.

• Work when you plug it into any traditional Ethernet network (i.e. with router with embedded DHCP server).
• It is also supposed to work when you directly connect it to another node (i.e. a computer which you’re want to configure the device with — where no DHCP server is available).

So our goal is:

• Zero-configuration connectivity on above two scenarios.

Our requirement:

• Severely scarce resources. Firmware should fit in a 64kb space.

Most such networked devices comes with a static IP already set and the node which is supposed to configure them (usually a PC) is supposed to be set to a specific IP address in the same subnet to configure them. This has several drawbacks:

• Users need to have administration privilleges
• Users need to have experience with computers
• And this is OS dependent.

There are other zero-configuration technology stacks, even though I don’t have a scientific fact, from their specs I think they’d take up significant code space.

So here’s what I’ve did

1. During device boot I assign it a link-local IP address (i.e. AUTOIP or http://tools.ietf.org/html/rfc3927). I did not implement RFC3927 and just generated a fixed IP address according to MAC of the device — partly because I don’t have a quality random number generator, as there’s no clock on most of the devices and reading analog inputs often give same results.
2. Then I start DHCP negotiations

With the scenario the device is able to communicate with another node which also have been assigned to a link-local address without waiting for a DHCP timeout. So when you plug your device directly to your computer you can communicate with the device as soon as your computer also assigned itself a link-local address. This varies from OS to OS but we’re pleased with the results. Our customers are able to connect to their devices without any configuration.

But there’s a problem! Even though this configuration worked on our network at the office and many other places where we sold the devices to, it didn’t work on my home network. It turned out that my linksys router in my home network does not honor DHCP DISCOVER requests if their source IP addresses are not 0.0.0.0

Problem:

• Some DHCP servers does not honor DHCP DISCOVER requests from 169.254.C.D. They strictly require source IP of the requests to be 0.0.0.0

To solve this problem I could either

• First assign my device IP address 0.0.0.0 and then wait for DHCP timeout, then fallback to AUTO IP. This way DHCP DISCOVER request would work with all routers but other party would have to wait for my device to timeout DHCP and fallback to link-local IP before starting communicating with it — this is a serious tradeoff.
• Or Add UDP IP Spoofing on top of our current implementation hence just make the DHCP DISCOVER source IP 0.0.0.0 and keep the rest the same.

Obviously I chose the second approach and patched uIP with the following code:

$ svn diff
Index: uip/uip.c
===================================================================
--- uip/uip.c   (revision 226)
+++ uip/uip.c   (working copy)
@@ -1181,7 +1181,17 @@
   BUF->srcport  = uip_udp_conn->lport;
   BUF->destport = uip_udp_conn->rport;

-  uip_ipaddr_copy(BUF->srcipaddr, uip_hostaddr);
+  extern int g_udp_spoof;
+  extern uip_ipaddr_t g_udp_spoof_ip;
+  if(!g_udp_spoof)
+  {
+    uip_ipaddr_copy(BUF->srcipaddr, uip_hostaddr);
+  }
+  else
+  {
+       g_udp_spoof = 0;
+       uip_ipaddr_copy(BUF->srcipaddr, g_udp_spoof_ip);
+  }
   uip_ipaddr_copy(BUF->destipaddr, uip_udp_conn->ripaddr);

   uip_appdata = &uip_buf[UIP_LLH_LEN + UIP_IPTCPH_LEN];

Now our device apparently has best of both worlds.

• It can communicate with any node with link-local IP address right away at boot time — without waiting for any sort of (DHCP) timeout.
• While link-local communication is working, it tries to acquire an IP address from DHCP server in parallel — thanks to source IP “spoofing”.

I’ll see if further testing will reveal any side effects.

See also:
DHCP RFC: http://tools.ietf.org/html/rfc2131
Link-local IP Address (AUTO IP): http://tools.ietf.org/html/rfc3927

So let’s start giving examples.

const char* str ="Foo";
str[0] = 'B'; // error: assignment of read-only location
str = "Bar"; // Perfectly OK

So, it is obvious that first line declares str as n pointer pointing to a constant object and the object is not modifiable but the pointer itself is.

Let’s review another example.

char * const str = "Foo";
str[0] = 'B'; // Perfectly OK (See the node below)
str = "Bar"; // error: assignment of read-only variable

Here we can see that the declaration tells compiler that the pointer value (address) is constant but the object it is pointing to can be modified. Please note that even though the above assignment “str[0] = ‘B’” will compile just fine, it will most probably result in a segmentation fault during runtime since your compiler will most likely put it in read only memory region.

Now let’s make another example.

const char * const str = "Foo";
str[0] = 'B'; // error: assignment of read-only location
str = "Bar"; // error: assignment of read-only variable

This declaration tells the compiler that neither the object the pointer is pointing to can be modified, nor the pointer value (address) itself. i.e. nothing is modifiable :)

Conclusion

So, we can conclude that qualifiers (const, volatile) that are placed before the * applies to the object the pointer is pointing to, and qualifiers placed after the * applies to the pointer value itself, i.e. the address.

So we can have weird looking declaration like this one:

extern volatile const char * volatile const str = "Foo";

I know it looks a bit unusual but it is perfectly valid.

Note: For hardware programming volatile keyword is a must. If you don’t know what it is, read this article at wiki.answers.com first. Here’s the backup, just in case.