[Dreamplug] Creation of a Setup-USB-Stick with Linux

Hey there,

since I already published some Debian-6-distributions shipping with various libraries and applications (Mono 2.10, OpenCV, LAMP, prepared to run customized start ups from a script,...), I think it might be interesting how to create an USB-Stick for the installation of such distributions on a Dreamplug.


Firstly, you need a USB-Pendrive with 4GB or better 8GB. Then grab yourself the required files:

• Kernel for Installation System: Ubuntu 9.04 Kernel 2.6 for Dreamplug
• Filesystem-Tarball for Installation-System: SetupStick-FS V0.6 (Note: This is currently unavailable for public, stay patient for a few more days please)
• Installation Instructions: setup_update_instructions_v2.pdf

Plug in the USB-Pendrive to your Linux Host. I use OpenSuse 12.2 and a Transcend JetFlas 8GB USB Flash Drive.

You now have to options to partition the Flash Drive. Either fdisk command line tool or the graphical GParted. To install GParted on OpenSuse, use zypper:

 linux-ulun:/home/tbergmueller # zypper in gparted  

Although I prefer fdisk, I'll show you the GParted-way, since this is more intuitive for most users:

Select your Drive from the drop-down in the upper right corner of the tool. Then delete the most-likely already existing partition on the drive. From the unallocated space, create two partitions:

1st primary Partition: 100MB fat16
2nd primary Partition: remaining space as ext3

GParted for USB Flash Drive partitioning

Doublecheck your settings in order to not accidentally delete some of your data on another drive or even break up your system. Then apply the changes by hitting the green tick on the Shortcut-bar.

Let's assume you downloaded the files from above to your Download-Folder. Mine is at /home/tbergmueller/Downloads.

Open a shell (preferably as root) and navigate to the Downloads-folder. Then create two directories for mounting the USB-Sticks partitions. I create them in /mnt named setupstick_kernel and setupstick_system. Then mount the formerly created USB Flash Drive's partitions to these nodes. My Flash-drive is registered as /dev/sdb.

 linux-ulun:/home/tbergmueller/Downloads # mkdir /mnt/setupstick_kernel  
 linux-ulun:/home/tbergmueller/Downloads # mkdir /mnt/setupstick_system  
 linux-ulun:/home/tbergmueller/Downloads # mount /dev/sdb1 /mnt/setupstick_kernel/  
 linux-ulun:/home/tbergmueller/Downloads # mount /dev/sdb2 /mnt/setupstick_system/  

Now copy the Kernel (uImage) to the 100MB partition and untar the Filesystem-tarball to the system-mount-point:

 linux-ulun:/home/tbergmueller/Downloads # cp uImage /mnt/setupstick_kernel/  
 linux-ulun:/home/tbergmueller/Downloads # cd /mnt/setupstick_system/  
 linux-ulun:/mnt/setupstick_system # tar -xvzf /home/tbergmueller/Downloads/setupStick_v0-6.tar.gz   

After this is done, safely remove the USB Flash Drive. You're now ready to install the system which is embed in the Setup-FS-Tarball. Best follow the Installation guide provided in setup_update_instructions_v2.pdf

OpenCV 2.4.2 on Dreamplug

Because of some real-time image processing I want to use OpenCV on the dreamplug. As expected, there is no precompiled package available for the dreamplug.

I chose 2.4.2 because I worked with this version for half a year and I'm pretty sure to run into no unexpected bugs this way.


To get a good overview on how to build OpenCV from source, refer http://opencv.willowgarage.com/wiki/InstallGuide


1.) Create a workspace (temporary folder) and download the OpenCV-Sources from  Sourceforge:

 mkdir /tmp/opencv  
 cd /tmp/opencv  
 wget http://sourceforge.net/projects/opencvlibrary/files/opencv-unix/2.4.2/OpenCV-2.4.2.tar.bz2/download  

2.) This leaves you with a 52MB file called 'download'. As it was formerly a tar.bz2 archive, let us get things right;

 mv download OpenCV-2.4.2.tar.bz2  

3.) Now unpack the whole thing

 root@debian:/tmp/opencv# tar -xvf OpenCV-2.4.2.tar.bz2  

4.) Once this is done you got an Folder named OpenCV-2.4.2.tar.bz2. This one holds the complete source code of opencv. In order to build the source, cMake has to be installed. If this is not the case on your dreamplug, install it by typing

 root@debian:/tmp/opencv# apt-get install cmake  

Well, now comes the funny part. Debian repositories for Dreamplug do NOT include a acceptable up-to-date version of cmake. So make sure to check the Version with cmake --version. If not the latest version of CMake is used, the build of OpenCV fails!! Lucky as I am this was the case at my dreamplug. Of course also the prebuilt stuff from CMake does not work, so I had to build that thing from source as well. Source is available at www.cmake.org/files/v2.8/cmake-2.8.10.2-Linux-i386.tar.gz. Simply download, un-tar and follow the instructions in Readme.txt. Note this step here takes forever and longer...


5.) Now make sure everything you need to build is installed. I got this from http://opencv.willowgarage.com/wiki/InstallGuide%20%3A%20Debian
It says not all packages are needed but I'm too lazy by now to sort out which ones I need and which ones not. Most likely the python stuff and everything related to GUI is not needed. Some may notify that cmake is listed again ;) Also the freeglut-stuff is most likely redundant as long as you don't want to use OpenGL.

 apt-get install build-essential 
 apt-get install pkg-config  
 apt-get install libpng12-0 libpng12-dev libpng++-dev libpng3  
 apt-get install libpnglite-dev libpngwriter0-dev libpngwriter0c2  
 apt-get install zlib1g-dbg zlib1g zlib1g-dev  
 apt-get install libjasper-dev libjasper-runtime libjasper1  
 apt-get install pngtools libtiff4-dev libtiff4 libtiffxx0c2 libtiff-tools  
 apt-get install libjpeg8 libjpeg8-dev libjpeg8-dbg libjpeg-prog  
 apt-get install ffmpeg libavcodec-dev libavcodec52 libavformat52 libavformat-dev  
 apt-get install libgstreamer0.10-0-dbg libgstreamer0.10-0 libgstreamer0.10-dev  
 apt-get install libxine1-ffmpeg libxine-dev libxine1-bin  
 apt-get install libunicap2 libunicap2-dev  
 apt-get install libdc1394-22-dev libdc1394-22 libdc1394-utils  
 apt-get install swig  
 apt-get install libv4l-0 libv4l-dev  
 apt-get install python-numpy  

 5.) Now let's run cmake. This creates a makefile and some other stuff required for building the library. cmake performs a bunch of tests to make sure the following build has chances to be sucessful.

6.) As we're building for a release version, let's create a directory and run cmake in ther. Note that I left out Python support here!

  root@debian:/tmp/opencv# mkdir release  
  root@debian:/tmp/opencv# cd release  
  root@debian:/tmp/opencv/release# cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_PYTHON_SUPPORT=ON ../OpenCV-2.4.2  

7.) Now comes the busy part. Simply run 'make' and grap a cup of coffee - this takes a while.

 root@debian:/tmp/opencv# make  

8.) A night later type the following:

 root@debian:/tmp/opencv# make install  

This should install OpenCV to /usr/local (becase this was passed as install prefix to cmake, see  above). Afterwards OpenCV should be available on your dreamplug. To verify, compile the following program:

[TBL-AVR] Now also on XMega

I'm pretty satisfied of my previous coding style as I managed to port the implementation from AVR Architecture to ATxmega128A1 within five hours (including lunch break, chatting and other stuff :P).


So, here is my setup:

On the one side there's the windows host, which is the master of the bus and the software to use TBL-Library is written in C#.

The other side is the Atxmega128A1 Board, which is the Slave with Address 10 (0xA).

The two of them are connected via USB-RS485-Converter Cable from FTDI (see http://www.ftdichip.com/Products/Cables/USBRS485.htm)


To verify communication I simply pinged the slave, because there's no additional coding needed, this command is already implemented in Master and Slave implementation and even measures the roundtrip time.

Here's the result:

 To get an idea of how simple the use of this system is, here's all the source code needed to get the 3 parts working:



Complete Master Implementation Code on PC (C#)

 using System;  
 using TBL.Communication;  
 using TBL.EDOLL;  
 namespace bac1_hardwareController  
 {  
      class Program  
      {  
           public static void Main(string[] args)  
           {  
                DevComMaster master = new DevComMaster(new devComSerialInterface("COM17"));  
                int err;                 
                if(!master.Connect(out err))  
                {  
                     stdOut.Error(EDOLLHandler.Verbalize(err));  
                     Environment.Exit(err);  
                }  
                long rtt;  
                if(!master.Ping(10, out rtt, out err))  
                {  
                     stdOut.Error(EDOLLHandler.Verbalize(err));  
                }  
                else  
                {  
                     stdOut.Info("Pinged with " + rtt + "ms ping");  
                }  
                // TODO: Implement Functionality Here  
                Console.Write("Press any key to continue . . . ");  
                Console.ReadKey(true);  
           }  
      }  
 }  

Complete Slave implementation Code on ATxmega128A1

 int main()  
 {  
      system_clocks_init();  
      DevComSlave_t* dc = dcs_create(SLAVE_ADDRESS);            
      // R/W Line of RS485 buscoupler  
      dc->RWPort = ((uint8_t*)(&(PORTD.OUT)));  
      dc->RW_bp = PIN5_bp;  
      dcs_start(UARTD1, dc, F_CPU, 500000);     // Start @ UART0 with 500kbits       
      while(1)  
      {  
           if(dc->NewReceived & DCS_REC_DATA_gm)  
           {  
                // Do something, access Data ranging from dc.Data[0] .. dc.Data[dc.DataUpperBound]                 
                dc->NewReceived &= ~(DCS_REC_DATA_gm); // Reset Flags  
           }  
      }       
 }  

 


That's all... quite simple, uh?


Next steps:

- Working on the Projects website, pre-releases of the library upon request
- Testing the library extensively on AtXmega and after testing include the XMega support to the library

[RS485] Hardware Hack

Uh, that's a bit embarressing - of course the 0x00 was sent on purpose, as Strings are always zero terminated in C. If the additional byte would be a 0xFE or a 0xFF this would have been caused by the issue described below.


Nevertheless, what I intended to state was that there is a bit of hardware that causes problems - if not now, than later when having bidirectional data transfer.

The original circuit is here:

The problem causing part is the WE-SL2 current compensing inductivity. The purpose for this part in design process was to add some line filtering for harsh environments.

This works excellent for unidirectional data transfers, because when data is transmitted the inductivity load's itself, as the inductivity law states. When then suddenly the data direction changes, the inducitivty becomes a source and uses it's stored energy to try to maintain the current into the original current direction (out on RS485_B_A and RS485B_B), but ont he other side there's the PC as a sender, who sends current on RS485B_A and RS485B_B in. So there is - like on the streets - a "collision" of the currents heading into different directions. So what might happen? Truck against city car; the stronger one wins and the weaker is damaged.

In most cases the Max3078 is likely to be the weaker part in this conflict and after ~10k data direction change cycles it starts malfunctioning and a few thousend cycles later it is defect.

So what's the solution? Well, simply remove the evil inductivity and  replace it by 0R resistors ;)

 

Here is a before/after image:

 

 ... before

 

 ... after

Well, I think after testing the second direction I'm ready to start porting the TBL-AVR code

[TBL-AVR] Hardware Test for functionality

Well, after I ran blindly into some debugging I realized after 15min wondering why the easiest things doesn't work that AVR-Studio somehow switched back to AVR-Simulator instead of JTAGICE3 for debugging - and I wondered that the program download was sooo fast ^^


Here's the first test Program.. Max485_t is a struct written by me that represents the UART and related RW-Toggle pin.

For further information look at:
http://avrlab.com/upload_files/MAX3082-1.pdf

 int main(void) 
 {      
      system_clocks_init(); 
      MAX485_t max; 
      max.Port = &PORTD; 
      max.RW_bp = PIN5_bp; 
      max.Usart = &USARTD1; 
      max.Baudrate = 38400; 
      max.Databytes = USART_CHSIZE_8BIT_gc; 
      max.Parity = USART_PMODE_DISABLED_gc; 
      max.TwoStopBits = 0; 
      max485_init(&max); 
      unsigned char test[] = "hallo thomas"; 
      max485_enable(&max); 
      max485_send(&max, test, sizeof(test)); 
      while(1) 
      { 
      }           
 } 

... source code of test function, sends "hallo thomas" on USART1 of PortD to the PC


Examining the Result on PC via Hterm I got this:

Well, that work's nice, but some mates may now see there's a 0x00 byte at the end that was never sent on purpose... Luckily I worked with this PCB before, so I don't have to spend another day of searching for the cause of this - it's some hardware fault ;)

explained in the next post...

[TBL-AVR] Porting weekend starts

Hey there,

I have to use some simulation equipment for my bachelor thesis, because real equipment is too expensive. Fortunately my former employer GFI (thx!) equipped me with a AtXMega128A1 board with loads of pheriphery on it.

I decided to link up the bachelor project with the TBL-Project and use the M3S Protocol for communication btw. PC and uC-Board.

The upcoming posts are going to describe the porting process from AVR-Architecture to AVR-Xmega architecture.

... the piece of hardware with JTAGICE3 and USB to RS485 converter attached

[Atmel Studio] [TBLAVR] Strange AVR-Studio 6.0 behaviour

I just experienced heavy troubles when using TBL-Library for AVR in Atmel Studio 6.0

I had a quite simple project set up which was last compiled in Atmel Studio 6.0 beta and includes tbl-Library (-ltbl).

As there came up another bug after a minor -completely unrelated - update with an older Toolchain (WINAVR2007525) from anouther Compnay using the library, I started debugging the library.

Previously compileable projects weren't any more. They showed some very strange error messages, such as

 'DevComSlave_t' has no member named 'SendFrame'  

Editor-Resolvment worked fine, so I took a look into DevComSlave.h (via rightclick on #include<tbl/DevComSlave.h> / Go to implementation and i saw the following:

 // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
      // ~~~~~~~~~~~~~~~~~~~~~~~~~~~ DevComSlave-Object ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
      // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            
      typedef struct devComSlaveStruct  
      {  
           unsigned char                    Address;                    // Slave Address  
           volatile unsigned char          MCAddress;                    // Multicast Address  
           unsigned short                    ID;                              // Device-ID, configurable by User, could be used to identify device types etc.  
           volatile unsigned char*          Data;                         // Pointer to valid Data            
           volatile unsigned char          DataUpperBound;               // Length-1 (highest index) of acceptable Data Packages. Set 0 if Data of any length up to 256 Bytes should be accepted  
           volatile unsigned char          NewReceived;               // 0 ... no Data available, != 0: New Received (see "New Received Bitmapping" below)  
           // RW-Output (if enabled)  
           volatile uint8_t*               RWPort;                         // Port, where RW-Wire is connected (e.g. for Buscoupler,...)  
           uint8_t                              RW_bp;                         // Bit Position, where RW-Wire is connected (Pn0...Pn7), e.g. PC3  
           unsigned char                    RWPolarity;                    // 0... when writing, RW-Wire is logic 0, 1 when reading    
                                                                            // 1... when writing, RW-Wire is logic 1, 0 when reading  
           DevComSlaveCommandHandler_t CommandHandler;                 
           // A callback-function, that handles all Commands that are NOT handled internally. Feedback Execution State (either DCS_CMDHANDLER_SUCCESS or DCS_CMDHANDLER_ERROR).  
           // parameters:  
           //          pCmd               Pointer to Command (pCmd[0]) and its parameters (pCmd[1]...pCmd[pUpperBound])  
           //          pLastCtrlByte     Controlbyte of the Frame the command was received in  
           //          pUpperBound          UpperBound of pCmd  
           //          pAllowsResponse     Indicates whether the command allows responding (Cmd received via Unicast) or not (Cmd received via Broad-/Multicast)  
           //  
           // return:  
           //          DCS_CMDHANDLER_SUCCESS          if Execution of Command was successful  
           //          DCS_CMDHANDLER_ERROR          if Execution of Command was unsuccessful or command is unknown  
           DevComSlaveFrameTransmitter_t SendFrame;  
      }   
      DevComSlave_t;  

Well, that is rather strange. For some reason I thought, why not try to open AVR-Studio 6.0 as Administrator and I did so.

Guess what? Compiled smoothly.

To be honest, I have not the slightest idea, why it didn't compile otherwise and even more important, why avr-gcc showed that strange - completely unrelated - error messages.

Any suggestions?