You are here

Using the 6936 as a wireless RS232 device | Cypress Semiconductor

Using the 6936 as a wireless RS232 device

Summary: 10 Replies, Latest post by csai on 09 Dec 2009 02:23 AM PST
Verified Answers: 0
Last post
Log in to post new comments.
rxdesign's picture
User
9 posts

I am designing a product around an Atmel micro and a CY6936 WLUSB module. This module is complete and sold by Unigen (and others) so I'm not working with the chip itself - just using the SPI interface to it.

I believe I can set a bunch of registers to make this work - the manual says that transaction mode is autonomous. However tech support at Cypress has been a bit lacking - seeming to think that this is going to be very difficult to do. I'm pressing on anyway.

I believe I have all the registers defined in what they need to be but am a bit confused by a few points. First register TX_IRQ_Status bit 1 [TXC IRQ] and 0 [TXE IRQ]. The wording is, well shall we say it leaves a bit of uncertainty. One would think that you could read this and if, when read, TXC were set then TXE would be valid - since indeed the transaction is done! However there is something about if it reads TXC=1 TXE=0 that you then have to read it again! I'm not exactly sure why. I believe it's saying that one can get a completed transaction and have an error in the transmission but not have the TXE set! If so then what use is it??

Essentially all I am trying to do is to use it in transaction mode (by the way nowhere in the manual does it say specifically HOW to get it INTO transaction mode except a veiled statement for bit 7 of XACT_Cfg), load the tx buffer, send 3 bytes, receive an ACK (which is automatic in transaction mode) and just confirm that I have received an ACK - then repeat 100mS later. Simple. Is there a better way to detect that a packet was successfully sent?

Stub for 4858768's picture
User
18 posts

Hi rxdesign,

Sorry, we do not support using our RF devices with non-Cypress MCUs.

rxdesign's picture
User
9 posts
Originally posted by: syf

Hi rxdesign,

Sorry, we do not support using our RF devices with non-Cypress MCUs.

forive me but that is a real dumb statement!

This has nothing to do with the MCU connected to it - this question is about the Cypress device! Do you not support your own devices??????

Do you honestly believe that ONLY your MCU's will be connected to this device? That would SEVERELY limit your market would it not? I mean people have existing tools/knowledge base on other processors - ones they might have LOTS of investment in already - and you're telling them if they use your RF device they now have to change all this and reinvent the wheel on their tools/MCU???

Good luck with that attitude.

rxdesign's picture
User
9 posts
Originally posted by: rxdesign

I am designing a product around an .......................it INTO transaction mode except a veiled statement for bit 7 of XACT_Cfg), load the tx buffer, send 3 bytes, receive an ACK (which is automatic in transaction mode) and just confirm that I have received an ACK - then repeat 100mS later. Simple. Is there a better way to detect that a packet was successfully sent?

PS: Cypress support did respond to this question indicating that I have to do the read of both registers twice... I thanked them for the response.

Stub for 4858768's picture
User
18 posts

rxdesign,

Creating a low-level driver for the radio transceiver is a cumbersome process, and we have seen many customers over the years have issues with doing that for their MCUs. We have done the job already by providing an excellent radio driver and protocol based on Cypress's family of PSoC devices. We simply cannot deal with the volume of support calls of designers trying to replicate this work on their own MCUs.

Using Cypress's PSoC devices in conjunction with our radio transceivers is the easiest, most transparent way to get a radio design up and running very quickly. You have to ask yourself, as the design engineer, how long it will take you to replicate all the work that Cypress has already put into getting the MCU and radio to talk to each other properly. Your time obviously costs money too. You will likely find that the overall cost for your project (including BOM of the final design) will be lower if you simply chose a PSoC device (perhaps one of the lower cost ones) to run the radio communication.

I really am saying this to help you. Believe me, after figuring out just how to get the SPI interface to work, you will have to learn the extensive register map of the radio, and how to get the radio to do exactly what you want. But even then, you're not done - you would have to come up with a new RF protocol that optimizes reliability and power. That is not a trivial engineering task, and in fact it has taken Cypress several years of refining for us to be able to offer what we believe is an excellent, easy-to-use solution.

Your best bet is to select one of our smaller, lower-cost PSoC devices to run the RF protocol stack. You can then configure that PSoC with an I2C or SPI or UART interface to talk to your Atmel MCU. This truly will be the easiest, and cheapest, way to finish your design.

Let me know your thoughts.

rxdesign's picture
User
9 posts
Originally posted by: syf

rxdesign,

Creating a low-level driver for the radio transceiver is a cumbersome process, and we have seen many customers over the years have issues with doing that for their MCUs. We have done the......................................I really am saying this to help you. Believe me, after figuring out just how to get the SPI interface to work, you will have to learn the extensive register map of the radio, and how to get the radio to do exactly what you want. But even then, you're not done - you would have to come up with a new RF protocol that optimizes reliability and power. That is not a trivial engineering task, and in fact it has taken Cypress several years of refining for us to be able to offer what we believe is an excellent, easy-to-use solution.

Your best bet is to select one of our smaller, lower-cost PSoC devices to run the RF protocol stack. You can then configure that PSoC with an I2C or SPI or UART interface to talk to your Atmel MCU. This truly will be the easiest, and cheapest, way to finish your design.

Let me know your thoughts.

Thanks for your considered response - this is basically what I have been told all along - "its very complicated and you have to use our "stuff" to get it to work..."... however the manual does say and I quote "in each case the entire packet transaction takes place without any need for MCU firmware action"! What I read here is if I use it in transaction mode (again another vagueness of the manual - how to put it into transaction mode) that once I get the registers set up - it's a simple process of sending a byte - all else including CRC, ACK and return to sleep mode is taken care of! There's no added complication around on-going changing of ANY of the registers! Set once and move on. So WHY is it so complicated???? I don't NEED a complicated protocol - all I want to do is to send ONE BYTE and confirm it was recieved! That's it. Why is it so difficult to then tell me "set this register to this and this one to this... then just load the tx buffer and check the ack confirm bit to be sure it was received? I understand that there are exception handlers when it does receive a byte due to distance or interference - that's my code and I can work that out if I am told the best way to confirm exceptions. I know I will set it to 32 chip and DDR for a 62K xfer rate - that's fine... I know I can set the CRC to a 0 seed - that's fine... there are defaults suggested for the other registers (radio protocol setup). Why is this so difficult?

The manual is like a prelimary manual - it gives just some basics (and is missing some detail altogether). Refer to some other say Zigbee chip manuals by others and they not only give this they give application information as well - from simple point to point "RS232 replacement" to complex networking. They too can have a complicated protocol - they're designed FOR use of a complicated protocol - but they're not limited to this!

What am I missing? Truly - what am I missing!?

If I succeed in doing what I want to do I will post the results - so at least others, and I am sure there are MANY of them (this IS a common application afterall - sending simple data) can see it can be done. I would have thought this would have been done LONG ago by the engineering department - "document how to do a simple WL RS232 replacement"... why it has not been is beyond me.... I might well come to a dead end - but so far I see nothing, other than a vague manual, that limits its use for this application. [or is this "stonewall" a marketing issue?!]

I'll post when I have more. I hope to have the radios working in a few days. If I'm wrong I will man-up and apologize - and then move on to another device that CAN support what I want (like maybe the TI device!).

rxdesign's picture
User
9 posts

STILL NEED HELP PLEASE!

Ok... me again.

I've done the following:

still not getting any comms between the two devices...

I have the SPI working fine - confirmed what I write gets written...

I have a receiver module and a transmitter.

I start by doing a reset Mode_override = 1 and waiting 1mS.

I am setting the following (in BOTH receiver module and transmitter module) :

char Cypress_data_low [24] = {0x80,16, 0x81,1, 0x82,0, 0x83,0x15, 0x85,0, 0x86,0x48, 0x8B,0, 0x8C,3, 0x8D,0, 0x8E,0, 0x8F,0x80, 0x90,0xA4 };

Channel_Adr = 16

TX_Length = 1 [1 byte is all I want to get across at the moment changing to 3 when done]

TX_Ctrl = 0

TX_Cfg = 0x15 [setting 32 chip and DDR modes]

RX_Ctrl = 0

RX_Cfg = 0x48 [LNA, Fast Turn EN] tried Fast Turn = 0 with no luck

Pwr_ctrl = 0

Xtal_Ctrl = 3 [this also allowed me to confirm the SPI is working as the freq goes from the default of 0.75 to 1.5Mhz after this instruction]

IO_Cfg = 0

GPIO_Cfg = 0

Xact_Cfg = 0x80 [ I assume, although the manual is very vague, that THIS is what puts it into transaction mode - correct?]

Framing_Cfg = 0x90 [SOP EN, LEN EN, SOP TH = 4 per manual]

char Cypress_data_high [22] = {0x91,0x05, 0x95,0, 0x96,0, 0x9C,0x05, 0x9D,0, 0x9E,0, 0x9F,0, 0xA6,0x08, 0xA7,0, 0xB2,0x3C, 0xB5,0x14} ;

Data32_Thold = 5

CRC_Seed_LSB = 0

CRC_Seed_MSB = 0

TX_Offset_MSB = 5

Mode_Override = 0

RX_Override = 0

TX_override = 0

Xtal_Cfg = 8 [the instructions for this are REALLY vague... do I have to set this or not? Is it saying I HAVE to set it and then during init or is it saying IF I set it I have to do it during init???? If I don't have to then I'll leave it at default.]

Clk_Override = 0

Auto_Cal_Time = 0x3C [ have no idea what this is/does... but it says I HAVE to set this! Again - do I have to set it or is it saying that IF I want to I have to do it during init??? What is it?! NOTHING in the manual on this!]

Auto_Cal_Offset = 0x14 [same as above - vagueness in manual text. ]

That's it... I have "checked" various parameters to confirm that after reset they're set to the manual declared default values?

For example I am using defaults for SOP_Address, Data_Code, Preamble. I see in your API code you set these items - but your API is kind of a "universal system" allowing one to set any and all parameters - mine is a one time "fixed" application - I don't need this flexibility.

Am I correct that this is ok or do I need to set any of these?

[Note when I get it going it is my plan to allow the user to program the channel (one of 32) and a 3 bit code that will be used to set different SOP codes allowing more/better inter module interference rejection (I'll have 20-30 of these spread out over a 10 - 500' radius).

Ok... here's the situation... I tried all this and I cannot get any comms.... I DO get a "Start of packet detect" on the receiver (bit 6/RX_Irq_status). I am never getting a Packet Receive Complete on the receiver. I DO get Receive errors and they're usually Bad CRC and the Receive Data Mode is often set to the wrong mode (8DDR or invalid and never DDR as preset). I am also getting, at times, RX Buffer full and half full status values - confusing as I've tried both RX_Cfg RXOW EN set and cleared - no difference in what I get I believe.

SO... I started to work on JUST the receiver - no transmitter (no other 6936 on)... even in this configuration I STILL get "Start of Packet detect" and CRC/mode errors! I thought maybe it's because of the wireless mouse on my computer (2.4G) or my router... so I tried three different addresses - all the same results.

But for now I need to have a receive system that is not "detecting" a packet when none should be there to detect.

Note I am not setting ANY other registers other than what I have shown here.

Thanks in advance. Sorry for the length but I'm getting down to the end stuff - I know from your manual that in auto transaction mode this SHOULD all be pretty well automatic.

[UPDATE: I have now stripped the transmitter of everything - all it is doing is loading the registers (only the ones listed above) and then sitting in a loop checking to be sure the TX_GO is off, then it sets TX_GO and TX_CLR, then immediately it loads one byte into the buffer... then it waits 50mS and repeats this. According to your manual THIS should transmit a byte!

I have the receiver load the same registers, it makes sure RX_GO is off - then it just sits there in a loop waiting for RXC to get only... with the transmitter off it now does not show "start of packet detected"... however with the tranmitter on it still always shows RXC and RXE with errors being badCRC and wrong mode!

PLEASE - HELP!!!!

Gary Myers

RXDesign

rxdesign's picture
User
9 posts

GOT IT! I had a couple small bugs in my code - I KNEW I had to be close. It's working just fine now it appears.

THAT STATED... hopefully someone can go through my request above and respond to the questions - I still want to know about defaults and the meaning of some of the variables...

I still have to do lots of testing - interference testing from a unit to a pair - how SOP_codes and/or channels effect this, range (PA level) (I want no more than 10M but UP to ~6M minimum to keep it low current and no incidence of interference)... but I'm one happy puppy!

It CAN be used as a simple WL RS232 device!

petejolibois's picture
User
1 post

Just wanted to confirm that others are in need of this same information. I am trying to link two Cypress radio modules with an non-Cypress processor. It is sad to know that Cypress is not willing to offer support for their products. This alone speaks poorly of the Cypress support. I am certainly not encouraged to start using Cypress components base on this blunt example of non-service.

csai's picture
Cypress Employee
32 posts

CYRF6936 is a ASIC (radio) which communicates using SPI interface. This ASIC does not have processor inside it. CYRF6936 has only ~36 registers. You just need to configure the registers and make it work accordingly. Its customers wish to make it use in their own way. As cypress also manufactures MCUs, we recommend customers to develop projects using PSoC.

As per my experience i feel CYRF6936 is a cool device having less number registers to be configured and send digital data wireless.

Stub for 4858768's picture
User
18 posts

Hi Gary,

I'm glad you got it to work. Of course it can be used as a wireless RS232 device

Did you see the CY3271 FirstTouch Kit? http://www.cypress.com/firsttouch
Why don't you buy this (it's very cheap), and see how much faster all of this could have been if you used PSoC?

Log in to post new comments.