Archive for April, 2007

XPe My PreFBA script

April 18, 2007
This is the batch file I run prior to FBA to:
Format the target drive (D: and named D)
Copy the image from my memory stick to the XPe Boot drive
Reboot the machine 
– In the reformat there are 2 user prompts,  D for the name and Y for Yes; that is all
– I have set XPe as the default boot option in boot.ini, so after the above its handsfree
– When building the image I build it directly to my memory stick in the folder "\windows embedded images"
echo on
format d: /fs:fat32 /q /v:D
xcopy "f:\windows embedded images" d: /e /h /k
shutdown -f -r -t 5  -c "Rebooting to XPe FBA now"

XPe Target Media: Development Efficiency

April 15, 2007
When developing an image, particularly with characteristics that you haven’t "played with" before, there is a lot a of iterative actvity… ie Add components, configure, build, copy to target , FBA, boot, look at logs, look at system (to see what hw hasn’t loaded), check nw, try out custom apps REPEAT until done.
Note that I am using a a separte HD on my target that has a bootable version of XP Pro.
The question then is what is the most efficient way to copy to the target?
(A) You could use the PXE Boot by booting the target system with XPe CD1 and doing a nw copy after a reformat.
(Note you need to reformat target partition each time)..Slow
(B) You could remove the media insert into dev machine and copy there.  Then replace in target and boot into FBA.
Not suitable if target media is a HD as inserting/removal requires shutdown at both ends.
(C) I have been using a USB memory stick to transport btw the dev machine and target.
I wrote a script on target machine to
– Reformat target partition. (D:)
– Copy image from memory stick dir to D:
– Autoreboot when done.
<I’ll post here as a comment later>
(D) Sean Liming suggested that the best way to go with this with FP2007 is to use USB boot.  <Thx Sean>
That way you just insert and boot… I’ll give this a try.
Coupled with making the memory stick the location on the dev machine to create the image in the first place, things are made a lot more efficient.

.NET CF2 SP2: Windows CE Platform Builder/VS2K5 Updates

April 15, 2007
From Mike’s Blog (Thanks Mike):

The .NET Compact Framework 2.0 SP2 has been released for mobile devices as a download on MSDN – The March 2007 Windows CE update also includes the .NET Compact Framework 2.0 SP2 bits for the Platform Builder Catalog.

Here’s a link to the downloads.

Windows CE 4.2

Update name: Windows CE 4.2 Platform Builder Monthly Update (March 2007)

Windows CE 5.0

Update name: Windows CE 5.0 Platform Builder Monthly Update (March 2007)

Windows CE 6.0

Update name: Windows Embedded CE 6.0 Monthly Update (March 2007)

From Mike

Windows XP and .NET (2) ..Problems

April 15, 2007
I tried adding .NET 2 to my FP2007 XPe image.
It added about 80 meg to the image…
My embedded disk is 478M
My image was now 340M
I had added 50M of swap space.
Towards the end of FBA I noticed that it was compiling .NET resources and failing becuase of lack of disk space.
The documentation (Help) doesn’t say much about .NET at all!
I will investigate this further.
– Eg try ngs
– Try a bigger disk and see how much it does use.

XPe, Tap and extra stuff it will find.

April 11, 2007
On the XPe blog it mentions that when Target Analyser is run on an existing XP Pro system it uses registry.
In doing so it finds any hw that was previously installed.
For example if a USB web Cam was plugged in and removed , Tap will find it and it will be included in the build if not removed.  It and all of its dependencies will be included increasing the image size
So only run TAP on a clean install.
Alternatively run Tap via the CD1 PXE boot but this is not as good as interogating an XP Pro installation.

XPe ran out of disk space with SP2 ..

April 11, 2007
Wasted several hours on this.
When I installed SP2 of XPe I ran out of diskspace.
Having created space the reinstall kept falling over.
Couldn’t write to repository.
Tried heaps:
– Changed permissions on repository.
– Deleted one repository dir (The one it couldn’t write to)
Eventually changed the repository share access permissions which solved it:
QAD (Quick and dirty) solution: Everyone write access.
This solved it.
(a) Will need to readjust repository remote  access permissions
(b) Probably would have run into build problems because of this.
Note running on Vista.

CAN BUs References (AS URLs)

April 11, 2007



Here is the list of links as promised in a previous Blog entry:


Original Bosch Specification

·         “An Overview of Controller Area Network (CAN) Technology, Mannisto & Dawson, Nov 03, mBus,

·         “15 Years of CAN”,

·         Wikipedia (CANBus)


·         There are numerous other discussions of the CAN Bus


·         AN228 (ISO1198)

·         TTCAN:

There are several CAN physical layer standards:

·         ISO 11898-2: CAN high-speed

·         ISO 11898-3: CAN fault-tolerant (low-speed)

·         ISO 11992-1: CAN fault-tolerant for truck/trailer communication

·         ISO 11783-2: 250 kbit/s, Agricultural Standard

·         SAE J1939-11: 250 kbit/s, Shielded Twisted Pair (STP)

·         SAE J1939-15: 250 kbit/s, UnShielded Twisted Pair (UTP) (reduced layer)

·         SAE J2411: Single-wire CAN (SWC)

·         GMW3089: GMLAN Single Wire CAN Physical and Data Link Layers Specification-Engl; Revision D


CAN Bus Electrical Interface Circuit







Other USB-LAN Connectors:

·         There is also a CAN device The Grifo with a DIP28 profile that does a multitude of things at


·         Wikipedia (CANBus)



1.      GMW3089, GMLAN Single Wire CAN Physical & Data Link Layers Specification

·         Purchase from:
Note : We have a copy


2.     Vehicle-Bus Interface with GMLAN for Data Collection, Pheanis & Tenney,



3.     :,,4165.html  (Look for neoVI Blue)

CANcaseXL, available CANpiggys and the XL Driver Library for self-programming of applications. In order to work on GMLAN you will need the single wire CANpiggy 5790c opto.

Access Cluster Map

April 10, 2007


April 2, 2007
I’ve been working lately on the CAN Bus.  In particular we are interested in getting live information from teh vehicle for logging purposes and for making some real-time decisons.  CAN means controller area network and was originally specified by Robert Bosch.  It involve the 2 bottom layers of teh OSI model:
Layer1:  Physical Layer
Layer2: Data Link layer (Data Packets).
There exists controllers that implement layer 2 with an interface to a microcontroller through interfaces such as SPI.  There are also microcontrollers that implement layer 2 themselves.  Both of these devices send and receive through a Tx and Rx signal at TTL levels that then needs to be translated into the physical layer.  Typical CAN layer 1 is a twisted pair (2 wire) with logic 0 (recessive) having both wires at the same voltage and logic 1 (dominant) having them at least 1.5V apart so the receiver only needs to do a difference.   There exists ICs to take the level 2 signals and turn them into level 1 signals.  There are also single wire implementations of layer 1 with ICs being available.  For example teh low speed GMLAN is single wire.  There is also an Israeli company that has car (DC) power line modulation for Layer 1 CAN.  A WiFi or Bluetooth version of layer 1 CAN would be interesting!
The layer 2 protocol takes care of collision avoidance (necessary because its a singlel bus -multiple drop) wiithout retransmission based upon priority bits being in the leading part of the packet.
The use of controllers as an add-on to a microcontroller has the added complexity that you have to implement the interface messaging as well, eg SPI.  There is a standalone controller that has A2D, PWM and GPIO that gets programmed over CAN.  I have some samples and are keen to get started on this.
Of interest is that messaging is above layer 2 (typically 3) in the OSI model.  Layer 2 CAN only specifies 1 to 8 data bytes (Short messages) , nothing about what is in those data bytes; although there are other bits in a CAN packet, check sum , priority bits etc… The layer 2 controller adds those.  To interact with a proprietary CAB Bus, eg in a vehicle, you have to know what message structure within those 1 to 8 bytes it is using.  Knowing the CAN protocol is not not enough.  I’ll follow up with a list of CAN URLs and some other stuff.