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