Samstag, 17. November 2012

[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

Mittwoch, 8. August 2012

[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?

Samstag, 4. August 2012

[Android] Create Eclipse Project for OpenCV in Native Code

Going to come later..

Eclipse IDE for Native OpenCV development on Android

As my new internship requires me to do Android-development, I'm trying to build myself a clean Eclipse-IDE and easy-to-follow Step-by-Step instructions on how to do that, so I can fall back to this clean environment whenenver I messed up my working one. Therefore I extract all components into one Root-Directory and create a script to set needed Environment-Variables whenever changing or deploying it to a new machine.

Please note I used Eclipse Indigo, although Juno is already available, because Juno has some serious problems when combined with Android NDK, they're currently working on that.

  1. Get yourself Java JDK  from http://www.oracle.com/technetwork/java/javase/downloads/index.html. I fetched Java SE 7. Of course you have to install JDK after the download succeeded.
  2. Create a root-folder (I called it androidEclipse) and download the following items to this location:
    1. Get Eclipse for Java Develpers EE from http://www.eclipse.org/downloads/. I downloaded Indigo for Windows 64bit. Extract it somewhere on your system, but make sure you have no spaces in the absolute path to avoid possible complications with NDK and OpenCV later on.
    2. Get Native Development Kit for Android http://developer.android.com/tools/sdk/ndk/index.html (android-ndk-r8b-windows.zip in my case)
    3. Get OpenCV4Android in latest version from http://opencv.org/downloads.html (2.4.2 here) 
  3. Extract all archives and place it together in a Folder, e.g. androidEclipse
  4. Install CDT (C and C++ Development)
    1. Go to Help => Install new Software
    2. Enter the p2 repository url which could be found at http://www.eclipse.org/cdt/downloads.php. In my case it was http://download.eclipse.org/tools/cdt/releases/indigo. Select CDT Main and Optional features and install it after agreeing the terms and conditions.
      Note: Probably it doesn't work because of conflicting dependencies. In this case (when installing Indigo, never experienced that in Juno) install CDT Main Features,TCF and Uncategorized, restart Eclipse and then install CDT Optional features.
      Install new Software: CDT

    3. Restart Ecplise
    4. Test if you can create a new C or C++ project and compile a Hello-World project.
  5. Install ADT (Android Development Tools) Plugin to eclipse.
    Refer to http://developer.android.com/tools/sdk/eclipse-adt.html and install similar to CDT via Repository URL https://dl-ssl.google.com/android/eclipse/. Please keep in mind, if this repository is extraordinary slow or not working, just drop the s in https - this is also recommended from developer.android.com.
    You need to install Developer Tools and NDK Plugins, but I'm not quite sure the second one is necessary.
  6. Now we have to adjust the Environment of our IDE. We have to create two environment-variables:
    NDKROOT ... Path to root of ndk-Folder (e.g. D:\AV\androidEclipse\android-ndk-r8b)
    OPENCVROOT ... Path to root of android-openCV-Folder (e.g. D:\AV\androidEclipse\OpenCV-2.4.2-android-sdk)

    You have to restart Eclipse (best your whole System, Windows is often a bit unpredictable in these manners) in order to get it to know the new environment variables. Windows console knows them immediately, but some other applications (such as eclipse) don't.
  7. Depending on which Android platform you're developing on, you have to install further API Support. To do so, go to SDK-Manager and select the desired packages. I additionally installed API 10 SDK Platform Android 2.3.3 and the Google APIs for API 10.
  8. Good, you're done and your IDE is (or should be) ready. Please refer the next post on how to create a Project that features JNI and OpenCV - and the combination of those two.

    Click here for the next post

Mittwoch, 18. Juli 2012

[TBL][M3S] M3S-Sniffer-Hardware


We often want to have a look on the ongoing data traffic on RS485-Bus when developing and debugging new applications or when we determine faults in already running systems.

It's quite important to NOT connect an USB-RS485-Converter directly to the bus, as it has high influence through possibly connected 120R-Termination-Resistors or Pullup/Pulldown.

Therfore i soldered together a small PCB that is a Sniffer-Connector for RS485 busses with high impedance inputs. This should minimize the influence of sniffing parts and give you the ability to watch the bus as it may work without the debugging equipment.

Needed Parts:
-PCB
- Soldering stuff
- TL084P
- FTDI USB-RS485-Converter Cable
- some wires for bus connection


Following circuit is used:

Circuit of M3S-Analyzer-Snifferhardware


And this is how it looks like:

Complete device





Detail view


Probably someone experienced trouble with influencing debugging equipment on RS485 busses as well, this may solve your problem ;)



Mittwoch, 23. Mai 2012

[Dreamplug] Change DNS-Hostname

One may want to identify the Dreamplug via DNS-Hostname in the network. Per default, it always is "dreamplug", which is quite useful if ten dreamplugs are in the same net.

In my previous releases (which are based upon NewIT-Debian Squeeze Release) the hostname is easily configureable via hostname command, but the DNS-Name always remains "dreamplug".

To alter the DNS-Name, you have to edit dhclient.conf:

 nano /etc/dhcp/dhclient.conf  

At the top of the document there's the line where you have to apply changes:

 send host-name "dreamplug";  

change here to whatever your DNS-Name should be and restart networking.

 /etc/init-d/networking restart  

Done - pretty easy when you know where to look for it ;)

Mittwoch, 16. Mai 2012

[Dreamplug] DebianSqueeze_TBConfig_V0.3 GFI-Edition released

This Debian 6.0 distribution runs on sheeva.with-linux.com's 3.3.4 Kernel and comes with preinstalled
  • Apache 2 (PHP5 and MySQL+phpmyAdmin included), Document root /dev/sdb1/www (which is on external SD-Card)
  • Mono 2.10 Framework complete
  • Support for standard USB2Serial / USB2RS485 converters such as FTDI-products
  • Automount External SD /dev/sdb1 and runs init_setup_ext.sh shellscript there. If not mountable, an internal M3S-uSlave on Port 62626 is launched. For further examination send M3S-Request 'a' to Slave #10
  • Note: This is a GFI Edition only, root password set accordingly
Further I created an USB-Stick image with Ubuntu 9.04 with included setup-Script to copy the install the above described distribution on internal SD-Card. Please note you may want to activate auto-installation whenever Dreamplug is started from this stick. To do so, boot from Stick and edit /root/init_setup.sh and uncomment the GFI-line (almost at the end of the file there). This starts the gfi_setup.sh script when booting and signals finished installation with the blue LEDs.

Edit: In provided Stick-Installation the shellscript /root/gfi_setup/gfi_dp_setup_debian6.sh has to be modified; At the bottom change version number of the Image from *v0-2.tar.gz to *v0-3.tar.gz, I mistakingly forgot to apply the changes. New Image is currently being uploaded but that takes half a night with my internet connection...

Files:

Bootable Stick for Installation on internal SD

 Operation System files for internal SD

Montag, 30. April 2012

[Dreamplug] DebianSqueeze_TBConfig_V0.2 released

This Debian 6.0 configuration runs on sheeva.with-linux.com's 3.3.4 Kernel and comes with preinstalled
- Apache 2 (PHP5 and MySQL + phpMyAdmin included)
- Mono 2.10 Framework
- Support for diverse USB2Serial / USB2RS485 converters such as FTDI-Chips

Kernel Files (uploaded on my server for persistence, originally via Bashscript from www.sheeva.with-linux.com)
  • uImage (Kernel Version 3.3.4 from www.sheeva.with-Linux.com)
  • Sysconfig stuff 
OS Files
  • Debian 6.0 TBConfiguration V 0.2 (30.04.2012)

Sonntag, 29. April 2012

[Dreamplug] Getting FTDI-Converters to work

[Note]:  Equipment is Dreamplug with NewIT-2.6.?-dirty Kernel, installed Debian 6.0 (NewIT-Edition) and Mono 2.10 / Apache 2 installed.

Currently I'm desperately working on getting an FTDI-USB-to-RS485-Converter operating on my Dreamplugs (using Debian 6.0).

I found out NewIT-Dreamplug-Kernel is not supporting USB-Serial Converters, so I have to find alternatives where these modules are included or compileable.

I stumbled upon  http://sheeva.with-linux.com/, where a myriad of kernels is located.

The Author was so kind as to supply a shellscript doing all the work for you.

Just download the Script from the Website using wget and make it executable


  root@debian:~# wget http://sheeva.with-linux.com/sheeva/README-DREAM-UPDATE.sh  
  root@debian:~# chmod 777 README-DREAM-UPDATE.sh  

Afterwards you just have to execute the Shellscript and giving the desired kernel Version as a parameter

  ./README-DREAM-UPDATE.sh 3.3.4  

The update process terminates with the following lines:

 Extracting modules  
 Writing kernel to /boot  
 ****************************************************************  
  update your bootcmd to load dream-3.3.4-uImage  
  or create a link from /boot/dream-3.3.4-uImage to /boot/uImage  
 ****************************************************************  

I ignored that hints and attached my bootable Ubuntu-Stick (9.04 dreamplug version), i usually use for updates, and copied the content from /boot to the stick's /home folder after mounting.

 mount /dev/sdc2 /mnt/dp_system  
 cd dp_system/home  
 cp -r /boot ./  
 cd /  
 sync  
 umount /dev/sdc2  

Afterwards I booted from this USB-Stick (don't forget to change uBoot Environment accordingly) and copied the new uImage and sheeva-sysfile to /dev/sda1 (fat16 file system of internal SD)

See also: http://semicolon-expected.blogspot.com/2012/04/dreamplug-backup-your-system-from.html

After successful reboot from freshly updated internal SD you could run uname -a command and should see your new kernel version number.

 root@debian:~# uname -a  
 Linux debian 3.3.4 #1 PREEMPT Fri Apr 27 16:11:35 MDT 2012 armv5tel GNU/Linux  


Because this kernel comes with serial-usb-converter modules  you simply can plug in your FTDI-Chip and you should get some output like that

 root@debian:~# usb 1-1.3: new full-speed USB device number 6 using orion-ehci  
 ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected  
 usb 1-1.3: Detected FT232RL  
 usb 1-1.3: Number of endpoints 2  
 usb 1-1.3: Endpoint 1 MaxPacketSize 64  
 usb 1-1.3: Endpoint 2 MaxPacketSize 64  
 usb 1-1.3: Setting MaxPacketSize 64  
 usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0  

If not, run the following command (which "enables" the ftdi_sio module manually)

 root@debian:~# modprobe ftdi_sio  
 usbcore: registered new interface driver usbserial  
 USB Serial support registered for generic  
 usbcore: registered new interface driver usbserial_generic  
 usbserial: USB Serial Driver core  
 USB Serial support registered for FTDI USB Serial Device  
 usbcore: registered new interface driver ftdi_sio  
 ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver  

You may then finally test the command and send out something (1st command) and/or read the response (second command)

 root@debian:~# echo "hello world!" > /dev/ttyUSB0  
 root@debian:~# tail -f /dev/ttyUSB0  


Sonntag, 15. April 2012

Exchange files with Virtual Machine (Ubuntu Server)

I've written a little gothrough for exchanging files with VM (Ubuntu Server) for my OS-classes.

Available as PDF-Document here

Cheers

Dienstag, 10. April 2012

[Dreamplug] Backup your System from internal SD

When working on a system, you may want to make a snapshot of the whole thing. Luckily that's quite easy when using Linux.

First of all, create a bootable USB-Stick (see different Dreamplug-Manuals for OS-Installation) with enough free space on it.

Then boot your Dreamplug from this USB-Stick by changing environment variables in Marvell Bootloader accordingly.

After your System from stick has started (I use Ubuntu 9.04 because it comes with more tools installed), mount the root filesystem of internal SD-Card.

 root@ubuntu~: mkdir /mnt/dp_system  
 root@ubuntu~: mount /dev/sda2 /mnt/dp_system  
 root@ubuntu~: cd /mnt/dp_system  

When you list this directory you should see the whole filesystem of your internal SD-card. After executing these commands you are located "inside" the filesystem, now simply use tar to pack and compress the whole filesystem (use * here) to a single file, I stored that at the /home of currently running Ubuntu on the USB-Stick.

 ubuntu:/mnt/dp_system# tar -cvzf /home/dreamplug_debianSqueeze_Mono2.10.tar.gz * 

After that, safely unmount the sda2 partition of internal SD-card and your snapshot of internal installed OS is successfully done. Quite easy right?

Samstag, 7. April 2012

[Dreamplug] Debian Squeeze Mono 2.10

Because installing mono-complete via apt-get fails (there are problems with xpath while installing monodoc), I decided to build Mono 2.10 from source directly on Dreamplug running Debian Squeeze (Initial Distro got from downloadsnewit.co.uk/)

First of all, you have to make sure you're using latest compiler and header stuff:

 root@debian:~# apt-get update   
 root@debian:~# apt-get install gcc libtool bison pkg-config libglib2.0-dev gettext make bzip2 g++  

Afterwards create a working directory, I created /src and download Mono Sources there. Mono 2.10 Source is available at http://origin-download.mono-project.com/sources/mono/mono-2.10.tar.bz2 (07.04.2012)

 root@debian:~# mkdir /src  
 root@debian:~# cd /src  
 root@debian:/src# wget http://origin-download.mono-project.com/sources/mono/mono-2.10.tar.bz2  

Now we have to create a directory where we can extract the source files to. I created monoSource and extracted the Sourcefiles from mono-2.10.tar.bz2 there. This works best (in my opinion) through unzipping to stdout (option -cd stands for decompress to stdout) and pipe this output into tar (option -xv stands vor extract verbose).

The extraction process may take a few minutes as there are loads of files...

 root@debian:/src# mkdir monoSource  
 root@debian:/src# cd monoSource  
 root@debian:/src/monoSource# bzip2 -cd ../mono-2.10.tar.bz2 | tar -xv  

Last step before compiling is to configure the source package. To do so, move to the folder tar made for you and run configure with long option --prefix=/usr. This defines the installation path of the whole mono package, it'll be located in /usr/mono respectivly /usr/lib/mono mostly then.

Further the configure process checks if all building utilities that'll be used later on are available on your system. If not, something went wrong in the first step when updating/installing build tools. Further it builds a lot of makefiles and does some other things for you in order to prepare the compilation process.

 root@debian:/src/monoSource# cd mono-2.10  
 root@debian:/src/monoSource/mono-2.10# ./configure --prefix=/usr  

After configuration is done, you simply type make to start compilation. After that it's time for a cup of coffee, some outdoor activity (if the weather is better than whilst writing this) or other stuff. Dreamplug will be busy for several hours with compiling Mono...

 root@debian:/src/monoSource/mono-2.10# make  

If you get a glimps every now and then at the terminal output while compiling framework files (*.cs, compiling here is already done with mono-compiler!) you may recognize a lot of warnings of unreachable code and unused variables... That's nothing you should worry about too much.

When compilation succeeded finally, type make install to transplant the fresh compiled mono framework into your system. The Installation process shouldn't take too long, just long enough to make me nervous whether this whole thing may be successful or not.

 root@debian:/src/monoSource/mono-2.10# make install  

After this last step has completed, Mono is successfully installed on your operating system. You may check installation by checking mono --version or executing some .NET applications.


 root@debian:/src/monoSource/mono-2.10# mono -- version  


Please note, .NET applications couldn't be started like normal executables, but have to be passed to mono as a parameter, e.g. if you want to start an executable named "testMono.exe", you type

 root@debian:~# mono testMono.exe 

Also note, Console.ReadLine() or Console.ReadKey does not work as you may expect it to. With these methods you read something else, but not the input from BASH. If your programm contains such lines, you are going to freeze complete BASH, because everything you enter (include CTRL+C) and stuff is "absorbed" by the mono application and the application get's stuck with it's not existing virtual Console.

I'm planning to do an article on that next week... Link may be found here soon

[Dreamplug] Mono 2.6

As I developed a pretty bad-ass (IMHO) DLL in C# for RS485 communication and other funny things, I want to use that on my dreamplug for some industrial application.

Big problem: The provided Ubuntu and Debian distributions don't come with suitable mono-framework installed. So I had to get Mono working.

1. Problem: with Debian: Debian Squeeze for Dreamplug is available and also apt-get install mono-complete seems to be working - as long as the installation doesn't reach the point where monodoc is installed. There seems to be something in XPath missing. I cancelled installation there but I don't think that was a good idea...

2. Problem: because I was frustrated by Debian I gave Ubuntu 9.04 a try. Because this distribution is a few years old, it isn't longer supported by ubuntu.com and also the latest available Framework for this distribution is Mono 2.0, which is also ooooold! So I downloaded sources for Mono 2.6 and compiled the framework on my own.


It seemed the only way out was to compile Mono Framework on the dreamplug from source to get an working copy of the framework running.


Before starting compilation you should make sure you use the latest available tools.

 root@ubuntu:~# apt-get update   
 root@ubuntu:~# apt-get install gcc libtool bison pkg-config libglib2.0-dev gettext make bzip2 g++  



After update was done I performed the compilation itself according to an entry in plugcomputers.org-Forum by profnimrod:
1. Make sure the following package are already installed: bison, gcc, gettext, pkg-config glib-2.0.  There may be others required.  If the configuration step (4) fails the error message will indicate what package is missing;
2. Use 'wget' to download the mono-2.6.1.tar.gz from the Mono website;
3. Unzip with 'bzip2 -cd mono-2.6.1.tar.gz' | tar xvf -' in a directory of your choosing;
4. 'cd' into the Mono folder that is created, and execute './configure --prefix=/usr';
5. Execute 'make'.  This may take several hours;
6. Execute 'make install'.  All done.  Check version with 'mono -V' to make sure you are up to date.

Sources are available there: http://origin-download.mono-project.com/archive/2.6/sources/

After make install succeeded and initial checks were done, you may delete the sources and buildfiles in Folder /src. They aren't needed anymore.

Note #1: You can't run mono-applications from bash with ./executable.exe , you have to call a Mono-Application, let's say initialTest.exe as shown below:

 mono initialTest.exe  

Note #2: (later a post will follow...): Mono-Framework is a bit tricky if you want to read from bash. The C# System.ReadlLine() and System.ReadKey() is NOT linked to the GNU-Readline(). So for initial tests you should use console-applications without reading from C# console.

 namespace InitialTestMono  
 {  
      class Program  
      {  
           public static void Main(string[] args)  
           {  
                Console.WriteLine("Hello World!");  
                // TODO: Implement Functionality Here  
                Console.Write("Press any key to continue . . . ");  
                Console.ReadKey(true);  
           }  
      }  
 }  

This piece of code doesn't work, because there's the Console.ReadKey(true); If you run that program you freeze your Dreamplug because it get's stuck somewhere in Mono.Console.ReadKey(). If you attempt to terminate by pressing CTRL+C that's lost somewhere in Mono and not redirected to Bash, so you have no chance to get back to bash-prompt again. You have to cycle power on your Dreamplug...

Freitag, 6. April 2012

[Dreamplug-Ubuntu] apt-get won't work

ARM-Processors only are supported by Ubuntu jaunty (9.04 is standard with Dreamplug) and Ubuntu no longer supports Jaunty, you have to alter the Sources for apt-get, otherwise you won't be able to update or install new things.

To do so you have to edit /etc/apt/sources.list

 root@ubuntu:~# vi /etc/apt/sources.list  

Replace the ubuntu.com/ubuntu with http://old-release.ubuntu.com/ubuntu/
Your file should now look like this:


 deb http://old-releases.ubuntu.com/ubuntu/ jaunty main restricted universe multi  
 verse  
 deb http://old-releases.ubuntu.com/ubuntu/ jaunty-updates main restricted univer  
 se multiverse  
 deb http://old-releases.ubuntu.com/ubuntu/ jaunty-security main restricted unive  
 rse multiverse  


After you saved the file you should be able to successfully run apt-get update. Afterwards installation should work as expected.

[Dreamplug] Deaktivate AccessPoint and Bluetooth

When using Ubuntu 9.04 on Dreamplug standard configuration is WLAN-Access Point. I experienced networking issues because the AP was configured with the same IP as my Router (192.168.1.1), so it's quit obvious this network wouldn't work as desired.

I found out when looking at ifconfig when I saw the uap8 entry with the IP and I stumbled over some Internet stuff saying Dreamplug comes with AccessPoint-configuration.

To deactivate you have to edit /root/init_setup.sh

 root@ubuntu:~# vi /root/init_setup.sh  

I excluded all lines from modprobe uab8xxx towards /etc/init.d/bluetooth start. This shellscript is called whilst startup and initializes the Access Point. If excluded, the initialization isn't done and therefore no IP conflict will happen again.

Altered init_setup.sh:

 #!/bin/sh  
   
 # This is called from /etc/rc.local to perform the initial setup.  
   
 # We always bootup in AP mode. Delete any stale files  
   
 rm -f /etc/wlanclient.mode  
 SSID=DreamPlug-uAP-`ifconfig uap0 | awk -F ":" '/HWaddr/ {print $6$7}'`  
   
 #modprobe uap8xxx  
 #ifconfig uap0 192.168.1.1 up  
 #/usr/bin/uaputl sys_cfg_ssid $SSID  
 #/usr/bin/uaputl bss_start  
 #iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE  
 #iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE  
 #echo 1 > /proc/sys/net/ipv4/ip_forward  
 #/etc/init.d/udhcpd start  
 #/etc/init.d/dnsmasq start  
 #iptables -A INPUT -i uap0 -p tcp -m tcp --dport 80 -j ACCEPT  
   
 # Re-enable bluetooth. In the earlier case, it didn't find the firmware.  
 # rmmod libertas_sdio libertas btmrvl_sdio btmrvl bluetooth 2>/dev/null  
 rmmod btmrvl_sdio btmrvl  
   
 #/etc/init.d/bluetooth start  
   
 modprobe btmrvl_sdio  
 hciconfig hci0 up  
 hciconfig hci0 piscan  
   
 blinkled >> /dev/null  
   
 # Set leds  
 echo 1 > `eval ls /sys/class/leds/guruplug\:green\:wmode/brightness`  
 echo 0 > `eval ls /sys/class/leds/guruplug\:red\:wmode/brightness`  

Now just save the file and and restart the dreamplug. The accesspoint shouldn't be setup any more.