http://forums.leaflabs.com/topic.php?id=738 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:09:04 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=738&page=3#post-4579 Thu, 12 May 2011 15:35:35 +0000 gbulmer 4579@http://forums.leaflabs.com/ <p>If money is no object, the Atmel H&amp;D WiFi SDIO card might be a candidate:<br /> <a href="http://store.atmel.com/PartDetail.aspx?q=p:10500186;c:100118" rel="nofollow">http://store.atmel.com/PartDetail.aspx?q=p:10500186;c:100118</a></p> <p>I got one when I went on a Atmel training course last year. Impressive, but a bit odd. Its firmware had to be loaded each time it was powered up.</p> <p>I'm more interested in 802.15.4 networks, it is much lower power. </p> http://forums.leaflabs.com/topic.php?id=738&page=3#post-4575 Thu, 12 May 2011 14:31:53 +0000 gbulmer 4575@http://forums.leaflabs.com/ <blockquote><p>Unfortunately I can't see any future announced ST MCUs which continue that integrated 802.15.4 capability. Perhaps they are dropping 802.15.4 entirely? Which is a shame but worth clarifying with an ST representative.</p></blockquote> <p>I got my STM32W development kit directly from ST Micro in the UK at the National Electronics Week Show last month.<br /> The UK MD said distributors like Farnell would have them around about now.<br /> They were pretty convincing that it isn't going to be dropped as a product.<br /> The fact that Farnell are now selling the chips, but weren't a month ago, helps me believe them. </p> http://forums.leaflabs.com/topic.php?id=738&page=3#post-4572 Thu, 12 May 2011 09:36:37 +0000 dreamcat4 4572@http://forums.leaflabs.com/ <p>The Marvell chip is better known as Libertas.</p> <p><a href="http://wiki.laptop.org/go/Libertas" rel="nofollow">http://wiki.laptop.org/go/Libertas</a><br /> <a href="http://wireless.kernel.org/en/users/Drivers/libertas" rel="nofollow">http://wireless.kernel.org/en/users/Drivers/libertas</a> </p> http://forums.leaflabs.com/topic.php?id=738&page=3#post-4571 Thu, 12 May 2011 08:12:24 +0000 dreamcat4 4571@http://forums.leaflabs.com/ <p>Perhaps if the Marvell AVASTAR series would ever become widely available. Thats a pretty decent wifi + bluetooth module over SDIO interface. I AVASTAR since its meant to replace the Marvell 8868 which supposedly already has an open GPL wifistack.</p> <p>If you can put an empty SDIO slot on the F207 board instead then that would allow the option to install a future SDIO wifi card. And perhaps without giving up the (very commonly used) SPI1 and so on. Which would be otherwise be permanently occupied when implementing an RMII interface.</p> <p>And if no appropriate wifi card materializes. We can still use the SDIO slot for extra storage. Another nice thing might be an smd spot to place extra RAM. </p> http://forums.leaflabs.com/topic.php?id=738&page=3#post-4570 Thu, 12 May 2011 06:13:02 +0000 dreamcat4 4570@http://forums.leaflabs.com/ <blockquote><p> What I mean is, when the STM32F is running a TCP/IP stack *ANYWAY* (to support 802.15.4 wireless) then there seems to be no resource benefit to using a UASRT-based ethernet instead of a local STM32F107-peripheral-based ethernet.</p> </blockquote> <p>Unfortunately I can't see any future announced ST MCUs which continue that integrated 802.15.4 capability. Perhaps they are dropping 802.15.4 entirely? Which is a shame but worth clarifying with an ST representative.</p> <p>There isn't any obvious successor for the WiShield device yet either. Its not as easy to find a manufacturer who will sell both the module plus suitable drivers. Indeed ST seem the only obvious party who would be interested in producing an 802.11 module with the drivers appropriate for the STM32. </p> http://forums.leaflabs.com/topic.php?id=738&page=3#post-4566 Wed, 11 May 2011 15:42:55 +0000 gbulmer 4566@http://forums.leaflabs.com/ <p>The STM32W implements an 802.15.4 radio.</p> <p>That is the radio under a bunch of different brandnames and protocol stacks, including ZigBee, 6LowPAN, HART, and ZigBee RF4CE<br /> (Edit: Radio Frequency for Consumer Electronics (RF4CE) merged with the ZigBee Alliance)</p> <p>I have this:<br /> <a href="http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/CD00297658.pdf" rel="nofollow">http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/CD00297658.pdf</a><br /> More info at <a href="http://www.st.com/internet/evalboard/product/251361.jsp" rel="nofollow">http://www.st.com/internet/evalboard/product/251361.jsp</a></p> <p>Which has a USB to wireless dongle with an STM32W108HBU63 and a small USB 'mote' with STM32W108CBU63<br /> <a href="http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00248316.pdf" rel="nofollow">http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00248316.pdf</a></p> <p>Edit: Farnell are selling the STM32W108CBU64TR chips here:<br /> <a href="http://uk.farnell.com/stmicroelectronics/stm32w108cbu64tr/mcu-rf-32bit-128k-flash-48vfqfpn/dp/1892383" rel="nofollow">http://uk.farnell.com/stmicroelectronics/stm32w108cbu64tr/mcu-rf-32bit-128k-flash-48vfqfpn/dp/1892383</a> </p> http://forums.leaflabs.com/topic.php?id=738&page=3#post-4565 Wed, 11 May 2011 15:23:59 +0000 poslathian 4565@http://forums.leaflabs.com/ <p>yea the NVIC on stm32 is quite flexible, with programmable priority for *most* of the 64 channels. There seems to be a bug in the hardware (seriously) that requires that the I2C peripheral run with the highest priority. You can always use high priority timers, or independent watchdog timers to guarantee some function is going to be run with a guaranteed period. </p> <p>There are also these stm32-W chips, which are kind of mysteriously unavailable but we've known about them for quite a while (a couple years now). They run a bit slower, 48MHz IIRC, but have an onboard radio PHY that works on a few different protocols (xbee included I think...) </p> http://forums.leaflabs.com/topic.php?id=738&page=3#post-4563 Wed, 11 May 2011 15:21:24 +0000 gbulmer 4563@http://forums.leaflabs.com/ <blockquote><p>The difference is that a UART ethernet solution doesn't let you the option of putting a TCP/IP stack onto the Maple.</p> </blockquote> <p>I assume I must have been unclear.<br /> I realise that the UART-based ethernet won't use the STM32F-hosted TCP/IP stack (I'd assumed that was obvious, but in retrospect I can see how I might have caused confusion).</p> <p>What I mean is, when the STM32F is running a TCP/IP stack <em>*ANYWAY*</em> (to support 802.15.4 wireless) then there seems to be no resource benefit to using a UASRT-based ethernet instead of a local STM32F107-peripheral-based ethernet.</p> <p>In this scenario:<br /> 1. I do NOT see any flash memory footprint benefit for any services which run (above the TCP/IP level) on an STM32F107 to a UART-ethernet (Put another way, the flash space for a TCP/IP stack is consumed anyway, so the UART-stack is only going to make it worse)<br /> 2. I think that the performance of reasonable code for the STM32F107-ethernet-peripheral (using DMA) is going to be in<br /> the same ball-park as code for a UART-based ethernet solution.<br /> 3. I think there may be some advantages for some edge cases, like NTP, of a STM32F107-peripheral-based ethernet.</p> <p>Clearly, I could do the experiments and measure the results of STM32F107 based solutions probably using ST code.<br /> I'd like to know what evidence folks might have to <em>disprove</em> assertion 1 or 2, so it is a bigger set of test results I'd like to understand.</p> <p>I can see that the time to develop UART-ethernet might be less than for an STM32F107-based ethernet. </p> http://forums.leaflabs.com/topic.php?id=738&page=3#post-4560 Wed, 11 May 2011 14:56:43 +0000 dreamcat4 4560@http://forums.leaflabs.com/ <p>I only have a Microchip Wifi module (WiServer) which is attached to an Arduino. Its hardly a fair comparison and the Wifi chip is really slow too (1Mbit). As expected, it performs pretty slowly. Its also proven to be pretty reliable however. The Wishield TCP/IP stack is pretty custom, built up on the uip stack which has a smaller footprint than LwIP which we are considering here for 100 mbit ethernet.</p> <p>WiShield (Uip) compiles into less than 32 kilobyte Flash and runs in only 2k RAM. Its also available on Maple and can't imagine the same Wishield setup creating much overhead on a Maple if you average it out. I believe performance concerns aught to be more about handling interrupts, and who gets runtime priority rather than the memory footprint, which should be acceptable since you can tune the size of LwIP buffers. Unlike our computer there's no swap disk. So your Maple programs aught to be in contention when sharing control timeslice and not be sharing memory with the stack. Please correct me if I'm wrong about that.</p> <p>I am unfamiliar with STM32 interrupt system. However if you set your program code off a callback fn() on a timer, isn't that at least guaranteed to be serviced on the timeout interval? Are there other ways to de-prioritize the servicing of ethernet / RMII interface over your own program code? </p> http://forums.leaflabs.com/topic.php?id=738&page=2#post-4559 Wed, 11 May 2011 14:39:14 +0000 dreamcat4 4559@http://forums.leaflabs.com/ <blockquote><p> When I try to look at it from a wireless + ethernet perspective, I think I'm going to end up running a TCP/IP stack locally anyway.<br /> In that scenario, I can't see much benefit from a UART/ethernet device in terms of flash memory footprint. Am I missing something?</p> </blockquote> <p>The difference is that a UART ethernet solution doesn't let you the option of putting a TCP/IP stack onto the Maple. It operates like those serial bluetooth device. It cant run whatever ftp server, web server, and so on as that requires a TCP/IP stack. Sometimes those UART devices try to support one or two of the most of popular internet services by some baked-in service which executes locally on the UART device. Of course they're not as flexible.</p> <blockquote><p> Is the processing overhead really much less on a UART than on-board?</p> </blockquote> <p>The 107 performance can be gauged today. It requires running one of the existing Olimex or ST examples on an existing (not-maple) board. Eg the Olimex board or other 107-based stamp board with ethernet. Sorry I cant help with determining this. Don't own the right hardware. We can be sure that whatever the 107 performance is, then the F2 series (and later on the Coretex M4) will be significantly better. </p> http://forums.leaflabs.com/topic.php?id=738&page=2#post-4553 Wed, 11 May 2011 11:27:44 +0000 gbulmer 4553@http://forums.leaflabs.com/ <p>This is a great N-dimensional analysis problem :-) </p> <blockquote><p>I hate to pull this in from left field, but what about foregoing all the complications of using onboard stm32 ethernet PHY and just throwing a complete ethernet-&gt;uart/spi chip on a ethernet-maple product.</p></blockquote> <p>I have no fundamental problem with that, a long as it doesn't impose greater limitations than using an F107, and isn't stupidly expensive.</p> <p>I am interested in ethernet, but I am more interested in wireless (802.15.4), and very interested in both.</p> <p>When I try to look at it from a wireless + ethernet perspective, I think I'm going to end up running a TCP/IP stack locally anyway.<br /> In that scenario, I can't see much benefit from a UART/ethernet device in terms of flash memory footprint. Am I missing something?</p> <p>Is the processing overhead really much less on a UART than on-board?<br /> I can see that something like an AVR running at 16MHz, handling every byte in software would be loaded, but I had imagined an STM32F107 with DMA, would be okay.</p> <p>I also wondered if there may be some benefits to having a direct ethernet connection. For example, would the Internet Network Time Protocol (NTP) be significantly more accurate if its talking directly to the ethernet hardware, rather than something which creates an extra level of latency? </p> http://forums.leaflabs.com/topic.php?id=738&page=2#post-4550 Tue, 10 May 2011 17:48:06 +0000 dreamcat4 4550@http://forums.leaflabs.com/ <p>If the best choice in each case depends upon the application, then that requirement is something which cannot so easily be predicted. I would then argue that for those client who really need to keep STM32 unloaded (by pushing out ethernet through through UART): it can still be achieved by adding a serial ethernet device externally. UART is only 2 wires. Wheras we can't take that same approach as easily the other way round. Because to make an external circuit of PHY + TCP/IP stack is a lot harder. Its just something to think about. </p> http://forums.leaflabs.com/topic.php?id=738&page=2#post-4549 Tue, 10 May 2011 16:33:30 +0000 poslathian 4549@http://forums.leaflabs.com/ <p>all good points. Plus, with the onboard PHY approach the network stack must run locally. This is a very non trivial overhead, but certainly something thats been done before pairing the asynclabs wifi shields with Maple. Im more concerned about performance hits rather than complexity. With the ethernet-&gt;uart you can DMA everything and move data around at very low cost in terms of application performance and bottlenecked only by the ethernet-&gt;uart transceiver. </p> <p>And correct, I only mean to talk of the f207 chips, I dont think an f107 is in the cards... </p> http://forums.leaflabs.com/topic.php?id=738&page=2#post-4548 Tue, 10 May 2011 16:08:56 +0000 dreamcat4 4548@http://forums.leaflabs.com/ <p>I would say that for many less demanding applications that arent quotes "true internet" (eg ftp server) - then sure serial ethernet generally works and is a convenient choice for the hobby community. Its fewer overheads, but historically, performance of previous devices shows less for (again i mention) latency. Additional line delays can often get incurred due to the serial aspect. That would be in addition to the other latencies I already talked about.</p> <p>If such a company is really interested in winning your business then they should understand why you need samples. To test the product thoroughly before you give any commitment to it. In other words - to be sure you actually know what the device's true operating performance is. If you're dependent on just that 1 manufacturer / deal, that would suggest that no-one else will be offering those devices cheaply / affordably.</p> <p>It would make sense that a manufacturer is unwilling to loose that potential market, since a serial UART ethernet device are typically only useful within that market. Commercial industry tend to use the solutions more close like we see are being recommended by ST. I think if you choose serial ethernet now you are pretty much stuck with that decision forever. That mean you are also stuck with that technology's performance, and dependance on it. Which can become an unknown if the company goes bust.</p> <p>If you go with ST's suggested approach then you aren't tied into a single device manufacturer. We already can be sure that the PHYs and ST MCU are improving gradually with time.</p> <p>Other side of the coin is that serial ethernet doesn't require you to give up SPI1, USART2,3, and CAN2. </p> http://forums.leaflabs.com/topic.php?id=738&page=2#post-4547 Tue, 10 May 2011 15:47:25 +0000 dreamcat4 4547@http://forums.leaflabs.com/ <p>I'm curious why this serial ethernet manufacturer has only approached you since I have started to quote hard costing figures here? Perhaps there is some correlation huh?</p> <p>The way I see it, theres a whole different set of pros and cons that come with either choice. The way I see it: until you can get an accurate costing of an option, then you cant finish evaluating it.</p> <p>The manufacturing cost (without special deals) aught to always be cheaper for ethernet PHY. The software development cost (without community help) aught to always be cheaper for serial ethernet UART device. That is what we have been going on so far.</p> <p>We are certainly aware of this hence my suggestions about getting started early. Its not to say that without due care and diligence, a software API for true ethernet stack cant be written once and largely forgotten. Or that without due care, the user API cant be as easy to use as a serial UART ethernet solution.</p> <p>If I understand the last comment, it just infers that Leaflabs still want to use the 107 regardless of ethernet choice. Because 107 also comes with extra CAN and USB. That makes sense when 107s are nearly the same price as 103s. So we should always use 107s regardless of our ethernet choice(s). I am guessing you really mean 207s there because F1-107s are memory-limited unlike the F2-207s. </p>