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