Printable View
Hello,
I have been searching the forum for suggestions to be able to use a pic to connect to a wifi module and ultimately just broadcast an id that I could see in the windows wireless network. Is this possible or would this require "C" programming? Thanks for the suggestions.
Anything here give you some ideas?
http://www.picbasic.co.uk/forum/forumdisplay.php?f=35
Thank you Mackrackit, you have been very helpful. I have tried the live search prior to posting must be my wording. Again, many thanks.
73
I ordered the MRF24WB0MA with the daughterboard to play with. I thought it would come with more documentation that just the pinout of the board. After seeing a 2009 post on here about this same module that had no replies this is not looking to good.
The MRF24WB0MA is a very basic radio module with some encryption hardware.
It does not have a TCP/IP stack built-in, and requires the use of Microchip's TCP/IP stack that is only available in C.
Using it with PBP will be very difficult.
Thanks Darrel, well thats money down the drain. What would you recommend for something I can see on the pc wireless network that I could broadcast an ID every so often? That would be pretty cool for a fox hunt. But thank you for clarifying the dreadful "C" issue, I assumed automatically that because it was from Microchip....well you now know the rest of the story. Thanks again.
Could you clarify what "broadcast an ID every so often?" means.
Modules that can do an "Ad-hock" connection will broadcast it's SSID.
But I'm not sure if that's what you want.
yes, that would be fine. It would be nice if all I had to do was power up the module and the SSID would broadcast but I would have to time it out so my battery would not be exhausted prematurely. Thanks Darrel
Roving Networks, RN-131 or RN-171.
http://www.rovingnetworks.com/products/Wi_Fi_Modules
I'm currently using the 171.
Microchip Technology Acquires Roving Networks as of April 19th 2012.Quote:
Originally Posted by Darrel Taylor
Norm
I was just on mouser's web site thinking of order one Darrel after you mentioned adhoc, I've gotten pretty comfortable using the 16f628a in my projects and am looking at the 18f's to experiment with when I purchased the module mentioned earlier from Microchip the data sheet mentioned the 18F's prior to the TCP/IP V6 and thereafter 24F's? and higher. The '628 has really been fantastic for me to learn with any suggestions for the 18f's? I am curious about how to connect to ethernet but before I ask anymore questions on that I want to do a little more research.
Thanks again Mackrackit, Darrel and Normnet for your help.
"adhoc", I knew I should have looked up the spelling.
I thought I saw something about a Rabbit Hunt ... I think they would be perfect.
One module can connect to other modules, and it returns signal levels for each device it finds.
Zeroing in on something wouldn't be too hard at all.
They are not a Web Server. They don't serve up webpages. (Although your program can).
But you can connect to other things on the net.
Synchronizing time is automatic, so it's great for clocks.
I think the best part is that two modules can connect to each other without the need for a wireless router (adhoc).
I haven't seen a better way to connect two PICs wirelessly. 802.11/G, can't get much faster than that.
Of course you are limited to 1 megabaud from the USART, and it's not secure in adhoc mode.
The 16F628 will work fine with it.
A 12F1822 (8-PIN) will work just as well.
@ 4uA sleep current, it can keep your batteries in good shape.
Sorry for what sounds like a commercial, but I've been having fun with the RN-171.
And I guess Microchip knew a good thing when they saw it, and bought them. :) I didn't know that.
Hi Tazntex,Quote:
Originally Posted by tazntex
If you like the 628a, you will love the 16F648A, same chip same data sheet twice the memory for about 30 cents more.
Not too much information about these. Can anyone tell me if the RN-171 can connect to a smart phone via wifi? I'm guessing that would be ah-hoc mode?
After reading some, I can't figure out which module is better - RN-171 or MRF24WB0MB? I'll be using an 18F4550 and I'd like to run a simple webpage where I can control and monitor stuff. I'd also like the module to be a standalone unit where I can use my phone to connect to it. I've used the Netburner PINK ethernet module in the past but I doubt these two modules are similar. What is a better unit to use?
The Roving Networks RN-171 has the TCP/IP stack built in making it far easier to use than Microchips MRF24WB0MB unless you are coding in C and using Microchips free stack library.Quote:
Originally Posted by Christopher4187
Norm
Thanks for the reply. I'm just entering the world of wifi with my projects so I have a few more questions.
Am I not reading the datasheet correctly or does the RN-171 not have SPI? If not, can I use something other than a USART to communicate with it? The reason I ask is because I'm using the USART for another chip. I don't know if it's like SPI where the USART pins go to high impedance mode when the CS line is deasserted.
I can't code in C but is it needed for the MRF24WB0MB?
Regarding the TCP/IP stack, both datasheets state they include one. Why is it so much harder to use the Microchip MRF24WB0MB as opposed to the RN-171?
For both models, can you use them to communicate with a identical model (peer to peer) and also through the internet?
Hi Christopher,
Looking at the datasheet for the MRF24WB0MB it's my understanding that it does NOT contain the TCP/IP stack. On page 7 it saysQuote:
The MRF24WB0MA/MRF24WB0MB modules are designed to be used with Microchip’s TCP/IP software stack.
So if I don't read that completely wrong you need to run a TCP/IP stack in the PIC you're using to drive the MRF24WB0MB. Alternatively you can pair it up with the MCW1001A which I suspect is just a PIC preprogrammed with Microchips TCP/IP stack and some user interface code. What you'll end up with would then be something like this.Quote:
The combination of the module and a PIC running the TCP/IP stack results in support for IEEE Standard802.11 and IP services.
You don't NEED to code in C to use MRF24WB0MB directly with a PIC but the free Microchip TCP/IP stack is written in C and to use THAT you'll need to write your application in C. Obviously you COULD develop your own TCP/IP stack in PBP but that is a monumental task and then some. Fred Eady (I think) has posted some TCP/IP code for PBP on this forum in the past but I have no idea what's implemented and in what state it is.
The RN-171 on the other hand does seem to have the TCP/IP stack already implemented within the module and if you look at the features you'll seeAnd in the datasheet it saysQuote:
•Hardware interfaces: UART and SPI Slave
Please note that I don't have any experience with either module. I do have a MRF24WB0MB + MCW1001A module but haven't done anything with it.Quote:
• Host data rates up to 921 Kbps TX, 500 Kbps RX for the UART, up to 2 Mbps over the SPI slave
/Henrik.
Henrik,
Thanks for the information. I'm not up to the task of writing any coding for TCP/IP since I know almost nothing about it. Regarding the MRF24WB0MB, what I meant was that Microchip provides it so it's "there." However, if it requires me to modify it with C, that option is out for me.
Regarding the RN-171, the reason why I asked about SPI is due to the fact that the sheets 4, 5 and 6 in the datasheet all state NOT to connect the SPI interface, which is on pins 15, 16, 17 and 18. Also, I thought that SPI is quicker than using the UART, no?
You're right, that IS confusing.
It says right there that it supports SPI slave but then in the table over the pins it says Unused/Do not connect on the SPI pins. I Googled real quick and it seems like we're not the only ones that are confused..... If you find an answer please let us know!
SPI can be (and generally is) conciderably faster then asynchronous (UART) but it depends on what the master AND slave devices are capable of. For example, if you set the USART up for 250kbit that will be conciderably faster then using bit-banged SPI (SHIFTOUT/SHIFTIN) but slower than using the MSSP module to do "hardware SPI" - which of course is the recommended way.
Using the MRF24WB0MB + MCW1001A combo doesn't allow SPI between the PIC and network module either - it's asynchronous (UART) only I'm afraid.
/Henrik.
Ok, so here's a question I can't seem to find an answer to. I'm currently using RF modules that use the USART on my 18F4550 (Pins 1 and 44). Is the USART similar to the SPI where you can attach a number of devices and have the data lines go to high impedance mode when the CS line is driven high?
My ultimate problem is that the RF devices use the USART, the MCP2515 uses the SDO pin and the RN-171 uses the USART (although I assume based upon what you are saying I may be able to use some other pins but the speed would be slower).
In re-reading the datasheet, do you think this line:means that using the UART is faster than software SPI?Quote:
• Host data rates up to 921 Kbps TX, 500 Kbps RX for the UART, up to 2 Mbps over the SPI slave
No, not in the way that SPI works. However with a bit of hardware you can do it. For example you can use a CD4066 to switch between devices. Another option is to use a PIC with two usarts. It all depends....
Perhaps you can use the USART for the RN-171, use SHIFTIN/SHIFTOUT (or the MSSP module) for the MCP2515 and use SERIN/SEROUT for the RF-module. It all depends....
The speed of the bit-banged SPI (ie SHIFTOUT/SHIFTON) commands depends on the osciallator. The manual says 50kHz dependant on oscillator (I suspect 4MHz) and that the active state is held to a minimum of 2us. I interpret that as no matter how fast the PIC runs the active state will always be 2us, assuming that the clock is symetric that means 4us per bit or max 250kHz. I think that in reallity it'll be quite a bit less than that. So, if you're comparing the USART to bit-banged SPI I'd say it's likely that the using the USART will be faster and because receving and transmitting is handled by hardware the PIC can do other things - if used properly.
SHIFTIN/SHIFTOUT can be used on any pins of the PIC - not just the SDI/SDO pins.
Using the MSSP module to do "hardware SPI" requires the use of the SDI/SDO pins since that is the pins to which the MSSP module is connected. SHIFTIN/SHIFTOUT does not use the MSSP module.
SERIN/SEROUT can be used on any pins of the PIC - not just the TX/RX pins.
Using the USART to do "hardware asynchronous" communications requires the use of the TX/RX pins since that is the pins to which the USART module is connected. SERIN/SEROUT does not use the USART. HSERIN/HSEROUT does.
I've given this some thought. I think I'm going to get rid of the RF devices and just use the MCP2515 on the SPI (I want to keep this because I can add other SPI devices with ease) so that leaves where to put the RN-171. Isn't the MSSP on the same pins as the SPI? If so, what about using the SC16IS750 for the RN-171? I've never used it but it looks like it should work. What do you think?
Hi,
I think we're just talking above each other heads here.
Yes the MSSP module IS the module doing SPI so of course the MSSP-module uses the SPI pins on the PIC. But, again, if you're using SHIFTIN/SHIFTOUT to do your SPI communications then your are NOT using the MSSP module - even if you happen to have the MCP2515 connected to those pins.
If you're ditching the RF-module that frees up the USART to be used with RN-171 does it not?
The exeternal one you linked to has one advantage though and that's its internal 64 byte buffer giving you some flexibillity.
If you're still in a position where you can add external circuitry why not simply change the PIC to one with two USARTS (the 18F45J50 for example (there are plenty)) instead of messing with external ones? Or, again, use SERIN/SEROUT for one of the modules and the USART for the other.
/Henrik.
Regarding the SPI, I'm using the SSPBUF to send and receive data. That's not shiftin/shiftout, is it?
I've thought about using another PIC but then I'd have to redesign. In addition, the 18F45J50 doesn't have dedicated ICSP pins. I'm not opposed to it but I've put a lot of work into this product. However, if I'm going to redesign, I might as well go for it all and use a PIC24, PIC32 or DSPIC33 because they have CAN, USB, SPI and USART. Does PBP even support them?
I feel like I've painted myself into a corner.
Hi,
No it's not. If you're manually putting your bytes into the SSPBUF regisiter then you are using the MSSP module for SPI - great! Thanks for clearing that up!Quote:
Regarding the SPI, I'm using the SSPBUF to send and receive data. That's not shiftin/shiftout, is it?
I don't follow here. Don't you need to redesign in order to add the RN-171 and your external UART chip?Quote:
I've thought about using another PIC but then I'd have to redesign. In addition, the 18F45J50 doesn't have dedicated ICSP pins.
On the 18F45J50 PGC and PGD are on PortB.6 and PortB.7 respectively - exactly the same place as on the 18F4550 you're currently using. What do you mean by dedicated?
No it does not. PBP supports PIC10, 12, 16 and 18 series. Rumour has it that there'a version for PIC24 in the works but I have no idea if or when that'll be available.Quote:
Does PBP even support them?
There are several PIC18 series devices with CAN built in but unfortunately none of them have USB-support too. PIC18F66K80 for example have 2 USARTS, 1 MSSP module and 1 CAN-module.
I think that all you need to do is take a moment with a pen and a piece of paper and really think thru what you need. It sounds like a pretty complicated product if it requires USB, CAN, WiFi, RF-link and what not - but that's cool.
/Henrik.
It's cool but it's becoming a huge headache. BTW, the RF-link I think I can replace with the wifi module. It's like everytime I look around for something to fit the requirements, I get excited but then figure out it's missing one critical thing. I could move over to MikroElectronika stuff because they have pic24 and pic32 stuff, but then I have to buy all new stuff and learn their version of Basic.Quote:
I think that all you need to do is take a moment with a pen and a piece of paper and really think thru what you need. It sounds like a pretty complicated product if it requires USB, CAN, WiFi, RF-link and what not - but that's cool.
I was planning to make the RN-171 an add-on board with SPI connections on the header. The 18F4550 has dedicated ICSP pins. I don't use PortB.6 or PortB.7 for ICSP. You see how the 18F45J50 has N/C on pins 12, 13 and 33? The 18F4550 has dedicated ICSP connections on 12, 13 and 33, which allows you to use PortB.6 and PortB.7 pins for whatever you want. I could workaround that by using an input or output that's high impedance during programming so it's a minor issue for me.Quote:
I don't follow here. Don't you need to redesign in order to add the RN-171 and your external UART chip?
On the 18F45J50 PGC and PGD are on PortB.6 and PortB.7 respectively - exactly the same place as on the 18F4550 you're currently using. What do you mean by dedicated?
The requirements I need are SPI, CAN, USB and one USART that doesn't use any of the SPI pins.
Right now I'm using the 18F4550. I have an MCP4912 and an MCP2515 connected to it. I'm also using the USB function and I need to use the RN-171.
There's no easy answer unless I move to a PIC32. It looks like there would be a huge learning curve but it would enable me to remove the MCP2515 and possibly the MCP2551 but I wasn't able to confirm that.
If the RN-171 only had SPI all of this thinking wouldn't be needed.......
I had another thought. The SPI doesn't use the TX portion of the USART. If I was using the RN-171 as a transmit only device, it would work fine. When the MCP2515 or MCP4912 aren't being used, the RX portion of the USART is in high impedance mode. This simply means that I only have to figure out what to do with the RX pin. A reed relay should work, no?
Hi Christopher,
Oh, the USART and MSSP module share the same pin on the 4550, that kind of sucks.
Honestly, I'd really look into using another device - but that's me.
/Henrik.
I've been thinking about this. What about if I bought some 16F720's and used them to transfer data from the RN-171 to the 18F4550? How difficult of a task would this be?
Hi,
Like RN-171<->USART-(16F729)-SPI 18F4550 you mean?
If you think it'll be easier than changing the PIC then fine. You may need to buffer the data in the 16F729 if you're in the middle of a SPI transfer with another device. What are you using the USB for? Perhaps you could you use a PIC with a MSSP module (SPI), built in CAN and 2 USARTS. Use one USART for the RN-171 and the other for FTDI USB chip or simmilar? (PIC18F45K80 is an example). Honestly, I don't know enough about your project so the only thing I can do is throw ideas up in the air and at this point I'm running out of them.
/Henrik.