Jump to content
  • 0

Cmod A7 communication with Arduino


smarano

Question

hi, i have a question.
 

I need to communicate with my Cmod A7 35T using arduino. I know that it is can't communicate directly but i found a middle chip that could be a solution. 
This component is : 

http://www.hobbytronics.co.uk/usb-host-serial

with new firmware i can set on this chip the right communication port.
My design is something like this, arduino send serial data to usb host that convert and send them to cmod, i have setted the right coomunication port and the right boudrate but there is an issues. I can see the datas flow (using the led) but  USB-UART bridge can't read it. I set ISR with only one function that take each byte and print it. But nothing is read by uart.

i don't know if i have explained the problem, but i ask some information about it.

regards Stefano

Link to comment
Share on other sites

11 answers to this question

Recommended Posts

I think that this can't resolve my problem. there is an updating, if i set packet interface on Uart Host something change on my CMOD. Infact data is send to cmod (leds blink) and i can read something. the problem is that if i send Hello Word the debug display only a 0XFF bytes. I can't undestand why

 

Stefano

Link to comment
Share on other sites

@smarano,

Let's back up a moment: why can't your arduino communicate directly with the CModA7?  Do you have a 5V serial port?  The A7 should be able to handle the 3.3V wires of a  serial port directly if you are using a 3.3V standard.

Either way, your current process needs some engineering discipline applied.  You have the problem where you would like A (arduino) to talk to B (USB host) to talk to C (CMod A7) and it's not working and you can't figure out why.  The problem could be that A&B aren't talking together properly, that B isn't properly configured, or that B & C aren't talking to each other properly.  At this point, you can't tell which is going on.  Something may be miswired, something may be misconfigured, you might be struggling to get interrupts running properly, etc.  You must first break this cycle so that you know what is and isn't working to then debug things.

Perhaps I might suggest that you connect C to B to C (Cmod to USB host to Cmod).  The CMod can easily be made to have two serial ports, the Cmod doesn't struggle with interrupts and whether or not they are routed correctly, etc.  Even better, connect your PC -> C -> B -> C -> PC so you can see what's happening (PC to CMod to USB host back to CMod back to PC).  That should make your programming even easier.  The CMod "program" might look as simple as:

module cmodtest(input i_pc_uart, output wire o_pc_uart, input i_usb_uart, output wire o_usb_uart);
// Forward the UART from the PC to the USB host
wire o_usb_uart = i_pc_uart;
// Forward the UART output from the USB host back to the PC
wire o_pc_uart = i_usb_uart;
endmodule

If you struggle to  get that working, then just try an echo program with the PC.  That is, ignore the x_usb_uart wires and just drive o_pc_uart with i_pc_uart.

Once you get this working, you can then try connecting the USB host to  your Arduino to transmit from the Arduino, through the CMod, to your PC.  If you can read the results on your PC terminal, then try to get the reverse link working.

Once that works, then you can turn around and remove the PC from your processing steps and set the CMod to run on its own.

Would that work for you?  It'd break you out of the cycle you are in of not being able to know where your bug is.

Dan

Link to comment
Share on other sites

Realy thank you @D@n for reply.

my design has three uart. 2 uart 16550 and an uart lite. First uart 16550 is conneted to main usb port (with ft2232h chip), the other is connected to internal pmod connectors. Uart lite is connected to external pmod connectors and is set as stdin/stdout with bsp. 

my first test is very simple, i have connected pc to main usb sending data and routhing them to internal pmod connectors and viceversa. It's very simple and it work fine. 

later i have send data to external pmod connectors through internal pmod connectors. using a ftdi for debug i can ready the right data. 

now, i have tried to connect  PC -> C -> B -> C -> PC  in this configuration : 
 

1) an FTDI cable from pc to Internal Pmod Connectors(this has a uart 16550), The submitted data is routed to the external pmod connectors.
2) the external Pmod connectors are connected to USB-HOST.  
3) USB-HOST is connected to CMOD through main usb port (the usb with double port), The submitted data is routed to the internal pmod connectors.

Using putty i have opened a port to internal pmod connectors, using ftdi cable. In this way i could send and read the data processed by this uart. 

i can see the data flow through usb-host to cmod because i can see the leds blinking but i can't read anything with internal pmod. is something like : the data is send but ft2232h can't read them. 

any suggestion?

Link to comment
Share on other sites

@smarano,

Hmm ... I'm getting  lost in your explanation and the poor notation I created above.  May I try to adjust the notation?  Let's use A for your Arduino, PC for ... well, the PC, CMod for the CMod, CMod(p) for pins on the CMod (without any logic behind them), CMod(L) for the same thing but with logic behind them, and USBHost for your USBHost product.  ... Just to keep things clear.  Further, are you using a processor on your PMod, such as a MicroBlaze?  (Well call this P for processor)

Let's see if I understand you: PC -> CMod -> PC works?  Was that PC -> CMod(p) -> PC or PC -> CMod(L) -> PC?  In other words, does it work through the UART modules within the CMod, or just via a straight pin echo?  It sounds like you used a UART16550 for this test, rather than a straight pin echo, did I catch that right?  And if you used CMod(L) (Cmod, with a UART/logic port like a Uart 16550 or a UartLite), did you use anything on the CMod to process the data or just forward it via logic?  As in, was your test really a PC -> CMod(L) -> P -> CMod(L) -> PC test?

You said you sent data through to an external PMod through internal PMod connectors.  I'm not sure what an "internal PMod connector" is.  Does this mean you tested PC -> CMod(L) -> CMod(L) -> PC via some form of loopback structure?

Did you ever test PC -> CMod -> USBHost -> PC?  Is this what you meant by "using a ftdi for debug I can read the right data"?

It sounds like you are struggling with CMod -> USBHost -> CMod.  Did you ever try PC -> USBHost -> CMod?

One final/quick question: Have you turned off hardware flow control?

Dan

Link to comment
Share on other sites

@smarano

One other thought: You are using LED's.  This is good.  What conditions are you checking for via LED?  Here are some conditions to consider:

1. If the UART line in question ever goes to logic zero

2. What's the maximum time the UART line stays in logic zero?  i.e., are you receiving a break condition?  Are you receiving data at the wrong baud rate?

3. If you send only one character to the device, from the time the UART goes to logic zero (start bit), how long does it take before it goes back to logic one and stays there (stop bit)?

I'll also point out that this was specifically the sort of reason why I built a wishbone scope (and it's AXIlite counterpart--although I've never tested that piece since I don't personally use AXI): it allows me to look at any 32-bits within my logic design and watch how they are toggling to know what's going on.  While an LED is a good start, sometimes you just don't get enough data from an LED to answer the question at hand--as you are discovering above.

Dan

Link to comment
Share on other sites

i try to explain my situation.

1) yes, my design has a microblaze.
2) yes i have tested the communication between pc and Cmod. In this way on the main USB port i have put an uart 16550 with 9600 baudrate. i have achived an C application that communicate with Cmod exchanging data. It work very well. 
3) For internal PMod connector i mean : in the rear part of the board there is a Pmod Connectors with two pin lines, for internal pmod i mean the line closest to the buttons, and for external the other one. 

 


4) so PC -> CMod(p) -> PC work fine and it work through the UART modules within the CMod. 
5) "was your test really a PC -> CMod(L) -> P -> CMod(L) -> PC test?" yes. I use a CMod(L) to send/receive data from/to pc and use microblaze for computation, something like matrix square ecc. This realy work fine. 
6) my first version of design consist in : Arduino is connected to Cmod without any logic, only with Tx and Rx connection, this connection uses pmod connectors pins. And another connection is made from PC to Cmod through main usb port
  (the port with ft2232h chip, the usb-uart bridge because it is faster.). Arduino does some authentication operatation and than pc do the rest of program. It work fine. Now i need to have only one connetion to the Cmod, so i need to 
  connect my arduino to main usb port using USB-Host because ft2232h chip has two port,the first port for programming and the other one for communication. This usb-host allow me to select the right port to send data. 
7) i try to explain my test better : i have three uart, 2 16550 and an uart lite. Main usb has Uart A with ISR_A() as handler, when some bit is sent to Uart_A, the ISR_A is activated in this way

XUartNs550 *UartNs550Ptr = (XUartNs550 *) CallBackRef;
    byte = ReceiveByte(UartNs550Ptr->BaseAddress);
    SendByte(XPAR_PMOD_AXI_UART16550_1_BASEADDR,byte);
    
    PMOD_AXI_UART16550_1 is another 16550 uart connected to pc using a ftdi-cable, so i send data from pc to Uart_A this data is sent to Uart_B and i can read them with putty. 
    
    Uart_B has a ISR_B() that does the same thing of ISR_A. So i can read data in both direction : PC<->Uart_A<->Uart_B<->PC. 
    
8) to test the communication using usb-host i have change this design. PC is connected to Cmod through Uart_B via ftdi-cable. ISR_B is changed in "byte = ReceiveByte(UartNs550Ptr->BaseAddress); xil_printf("%x",byte);" because i need to
send data to uartlite that is set as std in/out. the uartlite is connected to usb-host with two wire. Then i have connected usb-host to Uart_A (because i need to test the communication on this port, the port with ft2232h chip). 
So conceptually, using putty i send data, with 8 bit data, no parity and 1 stop bit at 9600 baudrate, to uart_b that take it and send them to uartlite that is connected to uart_a, everytime that some byte is sent to uart_a the led
blink, so if i send A i can see the blinking but conceptually when some data arrives on uart_a the isr_a take it and send it to uart_b, in this way i should see it on my terminal. But I can see the blinking but nothins is sent to uart_b

cmod.png

Link to comment
Share on other sites

@smarano,

Ok, so this is different: now you are telling me that your serial port works, but that the software you are running on your Xilinx MicroBlaze platform is not working?  The serial port is thus actually receiving the data you wish to receive, but you aren't getting the interrupt in your microblaze software?

Dan

Link to comment
Share on other sites

@smarano,

Ok, let's try this, let me ask you of a variety of tests, to see if you have done any of them that might help:

  • PC -> CMod(p) -> PC (This may seem too simple, but it's important for what happens next)
  • PC -> USBHost -> CMod(p) -> PC (Notice that we're just routing pins in your design here--no MicroBlaze, no Uart16550, etc., just a design so simple as to route pins)
  • A -> USBHost -> CMod(p) -> PC (to see if the Arduino can set up the UART on the USB host properly)
  • PC -> CMod(p) -> USBHost -> PC (Testing the reverse link)
  • PC -> CMod(p) -> USBHost -> A (Reverse link, but into the Arduino)
  • A -> USBHost -> CMod(p) -> USBHost -> A (Arduino to arduino, input UART wire connected directly to output UART wire)
  • A -> USBHost -> CMod(L) -> CMod(L) -> USBHost -> A (An echo server, using your UART logic, to make certain that you can read/write from your Arduino.  Please note that the MicroBlaze processor is *not* a part of this test--lest it be your microblaze software that is at fault)
  • A -> USBHost -> CMod(L) -> P -> CMod(L) -> USBHost -> A (If the previous test passed, and this test fails, then you know the problem is in your microblaze software).

Please note that none of these tests use any UART logic on the CMod, neither do they use the microblaze processor.  They are designed to take those unknowns out of the equation, and to just make certain the wires are set up properly and the protocols are set up properly -- on everything but the CMod.

Dan

Link to comment
Share on other sites

my last test is : Arduino with a simple loop that send every 2 seconds "hello word" to usb host that is connected to main usb port of Cmod. 
Cmod has an isr that print each byte that is received. i can see the output but it is not correct. i see 0xFF for each byte that is received. 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...