Olimex STM32-P107 board ( for ethernet! )

LeafLabs Garden » Development

Olimex STM32-P107 board ( for ethernet! )

(39 posts) (4 voices)

Started 4 years ago by dreamcat4
Latest reply from gbulmer

« Previous 123 Next »

dreamcat4
Member

How about the way those inaccessible interfaces impacts the software? Users who buy ethernet enabled board probably also want to run non-ethernet based programs / libraries. If we don't try to solve that may limit the accessibility of ethernet as one part of the available communications functionality. It would be great if we can make all Maple programs work well enough to keep software compatibility with and without ethernet.

Its something that broadly impacts program and library compatibility amongst the whole user base. Remember Arduino Mega - it has different SPI pins / wiring. Its essentially the same issue. Any solution has their own set of advantages and drawbacks.

For a focussed example, lets use the occupied SPI 1. As SPI is a common interface for many peripherals. Lets say we have written a library for the STM32 to control some specific SPI slave chip. Its a simple circuit. And lets just leave as undefined behaviour (depending on specifically unknown installation factors) whether the rest our the program might / might not optionally be reporting collected data over either USB or Ethernet. The SPI library knows nothing about our chosen data collection method.

1) Remap the labels (in software) so that on the ethernet board they skip over occupied interfaces: eg map SPI1 = SPI2. Then people won't understand why a silkscreen labeled SPI1 are actually connected to the pins of SPI2. And reading from the STM32 manuals (to do a direct manipulation of registers) would of course be troublesome without knowing about this.

2) On the other hand, say we choose that everyone uses only SPI2 onwards (avoiding SPI 1 to favor broader compatibility). Then also wiring to such interfaces starting SPI2 on the silkscreen (meaning no SPI 1). Would that be too tough on some? Loss of SPI 1 shouldnt be any significant concern for 144 and 172 LQFP. But would for example be an issue for the same program to run on the Maple Mini.

3) A software compatibility mode (that can be switched off if necessary). The compatibility mode would check for references to inaccessible ports (as called through approved API only). eg in this case using reference to SPI1, USART2,3 would break compatibility with an ethernet version. This would still allow users the option to take advantage of all possible IOs if they so wished. But would report the fact that their software won't work on eg Maple Mini. Or eg Ethernet variant, Discovery board and so on.

4) Do nothing, let people struggle to come up with their own specific software solutions. But recommend some best practices. On the Arduino what I have been doing is to specify local configuration initializers for which UART or SPI to use. And so the local configuration initializers too are set depending which is the board. It means that the wiring / circuit diagram must also be different.

Perhaps its not necessarily the most pressing consideration overall, but its worth bearing in mind for later on.

Posted 4 years ago #
gbulmer
Moderator

Those numbers for pin occupation are an overestimation.

The STM32F105/107 data sheet is specific, MII is 17 pins:
"2.3.20 Ethernet MAC interface with dedicated DMA and IEEE 1588 support
...
The STM32F107xx devices provide an IEEE-802.3-2002-compliant media access controller
(MAC) for ethernet LAN communications through an industry-standard media-independent
interface (MII) or a reduced media-independent interface (RMII). The STM32F107xx
requires an external physical interface device (PHY) to connect to the physical LAN bus
(twisted-pair, fiber, etc.). the PHY is connected to the STM32F107xx MII port using as many as 17 signals (MII) or 9 signals (RMII) and can be clocked using the 25MHz (MII) or 50 MHz (RMII) output from the STM32F107xx."

I don't really mind which LefLabs uses, but the MII interface has the advantage to me that it is only 25MHz, versus RMII at 50MHz. You might be a PCB whizz, but for me slower speeds are easier, especially on two layer PCBs.

Posted 4 years ago #
dreamcat4
Member

I'm not sure thats necessarily correct. Perhaps ST are quoting the worst case there and the actual clock required for a given PHY in RMII mode will vary depending on the PHY chip you selected. Because its up to the PHY how it implements its intenal clock / oscillator scheme. For example the Olimex board we were discussing here uses an STE101P. And the wiring digram in the Olimex schematic clearly shows their ETH_RMII_REF_CLK. Its 25Mhz, not 50.

Posted 4 years ago #
gbulmer
Moderator

dreamcat4 - I agree this is a serious issue.
I am opposed to complexity, or hiding information, so ...

Maple carries documentation, and that can vary on each board, so that seems clear. GPIO pin numbers can vary, but that is pretty much all that can be varied, after that there is a danger that ST Micro manuals, like RM0008 get broken.

When I want to understand what is possible on the STM32F, or get stuck, or want to do something not in the library, RM0008 is the place to go to find the details. It is definitive, and costs LeafLabs nothing to maintain. So all peripheral device names must remain compatible or code will break/be too hard to write. As bad, 3rd party code can't be used unchanged.

Maple libraries have their own documentation. Peripheral libraries can carry some documentation, say a small table, which says which peripherals exist on which board. Not very big, or onerous to maintain, and is a direct index into RM0008; SPI 1 -> SPI 1.

A pin table says which peripheral lives on pins. It only need to be updated when a new board is released, so it isn't a continuous effort.

option 1 - as you have analysed, this seems to have several problems. It seems to break the ST Micro manuals. Because of that, it seems to create a barrier for someone who might want to write new peripheral library functions, or use 3rd party code.

option 2 - seems to deprive folks of peripherals that they have bought. Further, it is for a scenario that the majority of users won't experience for the majority of time; IMHO moving a program to a different, incompatible board will be a minority activity of Maple users.

option 3 - maybe I have misunderstood this, but like 2, it seems to deprive users of peripherals which they have on their board. It seems to be a piece of software infrastructure who's only purpose is to alert a user that they are doing something that works on their board but not on a different board. There is also the question of how it works. What does it do, throb the blue LED if the program uses a peripheral that isn't available on another member of the Maple family? How do they track this error down and fix it? How do they know their program has that error, and not a different one?

It appears to be most helpful to people who haven't written software yet, but intend to make it portable to other boards once it works. It doesn't add functionality to the Maple, its goal is to assist in porting. Is that correct?

I'd prefer effort instead be put into providing rich libraries to use all the STM32F peripherals.

option 4 - seems low effort. Let's wait and see what problems arrive and solve them!

There is option 5, which I think is, to some extent, what wire-ish aims for. Wire-ish gives a simple abstraction so that changing peripherals isn't a lot of work.

In this specific SPI case, that seems easy.
A program that contained:
HardwareSpi Spi(1);
is to be moved to a board which doesn't have SPI 1.
The user discovers there is no SPI 1 when they try to wire up the circuit and can't find any SPI 1 pins on their board.
So it is changed to be
HardwareSpi Spi(2);
There are no other changes to code, and the pin map tells them what pins to use for SPI 2.

(Of course, the performance impact of mixing SPI and ethernet might be a problem, but that seems beyond this proposals scope, and IMHO is plain hard.)

Further, if the SPI library doesn't do everything needed, the user can look around for code for SPI. They might even find some for SPI 2, and it should all carry the right addresses, and offsets, with a plausible chance of working.

The rules for peripherals need to be easy to explain:
1. All the peripherals on your board use the same names across all other boards when they are the same thing. So if you want to move a program to a new 'target' board, and it has the same set of peripherals as you use on your board, the program will move easily, and if the 'target' doesn't have the same peripheral numbers, but it it has enough peripherals of the same type it will need a little bit of work.
2. All the peripherals on every board use different names when they are different. So the ground will never change under your feet.
3. All the names on every board match all the ST Micro documentation, so if you want to do something more, you know the names to use in ST Micro documents, on this forum, on any ST Micro forum, and with google (Edit: Bing, Yahoo, etc. are okay search engines too)

(full disclosure: I am not a member of LeafLabs staff)

Posted 4 years ago #
gbulmer
Moderator

dreamcat4 -

... the actual clock required for a given PHY in RMII mode will vary depending on the PHY chip you selected. Because its up to the PHY how it implements its intenal clock / oscillator scheme. For example the Olimex board we were discussing here uses an STE101P. And the wiring digram in the Olimex schematic clearly shows their ETH_RMII_REF_CLK. Its 25Mhz, not 50.

Cool, as long as I can work at the slower frequency end, I am happy.

I glanced at a few results from a google for MII vs RMII. Foks seemed to say RMII uses fewer pins because it runs at 50MHz rather than 25MHz, and hence can transfer 2x more data in the same time, and hence can use fewer pins. But, that was a quick look, and google does not discriminate between popular rubbish, and unpopular fact :-(

(full disclosure: I am not a member of LeafLabs staff)

Posted 4 years ago #
dreamcat4
Member

Another reason to skip over MII: as the newer (and cheaper) breed PHYS come out many may not even support MII anymore. Its a trend which has already begun with one such PHY manufacturer. Their newest (and improved) PHY - is RMII only. Thats if you are talking about value PHYs (<$3). The more expensive ones (> $10) generally still support MII.

Posted 4 years ago #
gbulmer
Moderator

dreamcat4 - so does that value PHY (<$3) include a socket and the 'magnetics'?
I would expect those for $10.

Posted 4 years ago #
dreamcat4
Member

No. Thats for just the silicon in an SMT package, ignoring magnetics. Those are boundary prices where we find a cost jump and we can see a divide between those 2 categories (value and expensive). There appears a gap because:

1) Can be older generation, it was more expensive back then
2) Include support for older connection interface
3) Lower latency
4) They come in larger packages, more pins because of 2)
5) Non cost-orientated manufacturer preferences (i.e. larger manufacturer wants to charge a higher price, lower expected volume, they provide quirky features that add the price but we dont usually need).

Of those, the most significant reasons for the cost gap seems to be 3) and 5). I say this after glazing over the data sheets of about 6-8 of the most promising PHYs. It seems that 5) can be avoided. But all manufacturer in all cases must pass on a higher cost for making a lower latency chip. Which of course makes sense.

However the manufacturers do make this aspect pretty hard to compare since all of the latency measurements they provide have no like-for like standard. Below I have just gone with their upper quoted latency in each case. Its not meant to be a precise figure, or even a "real world" figure. But its what they quote and to try to make some scale to put their figures into perspective: The manufacturer of the network card in my computer quotes an upper latency of about 250ns in their data sheet.

> $10 for a non-value part was estimated from the cheapest such part we can currently find. Its made by ST. The ST802RT1B which we know costs about $8. It latency is supposedly 160ns. Which means its even faster than my PC ! Thats also around the best you're ever going to get. There are some even more expensive parts (up to $40). But thats mostly due to 1) and 5). So no point paying that much.

On the opposite end end ($$ value PHYs) we have a bunch of pretty similar-looking PHYs in the range of $2 - $3. All the PHYs produced by SMSC have a quoted latency of 800ns. All Micrel PHYs have a quoted latency around 500ns.

Somewhere in-between is the STE101P (the one on the Olimex board) which is also meant to be fairly new to market. I have no price for the STE101P because its only available in bulk. Its quoted upper latency is about 300ns. For its pricing to be in line with the others then it aught to cost anywhere between $2 and $8.

Whether latency is significant depends on the embedded application. But since we can only choose one part and cannot determine the required latency beforehand, that suggests the STE101P as the best choice. Unless the STE101P proves to be either too expensive or too large for the board's intended form factor.

In which case then choose Micrel (500ns). The KSZ8041NL seems like a good choice for initial prototyping since there are suitable adaptors available. That would be the BGA adaptor for its 32 nolead package. Known as "PLCC 32".

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=300541531987
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=190527195819

But for SMT and manufacture, the Micrel KSZ8021RNL is best. That is - amongst those Micrel chips available from Micrel.

Of course, in future there may be more PHYs from other manufacturers come out in the future. These ones ^^ just seem to be the best known options as things stand at the moment.

Posted 4 years ago #
poslathian
LeafLabs

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->uart/spi chip on a ethernet-maple product. We were recently contacted by a well known company that makes these chips about a potential partnership. I wonder what you guys think. I have no idea of the cost estimate of this approach.

The 107 chips DO also have a second CAN bus, and USB OTG, both very desirable, so ethernet is not the only issue though.

Posted 4 years ago #
dreamcat4
Member

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?

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.

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.

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.

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.

Posted 4 years ago #
dreamcat4
Member

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.

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.

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.

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.

Other side of the coin is that serial ethernet doesn't require you to give up SPI1, USART2,3, and CAN2.

Posted 4 years ago #
poslathian
LeafLabs

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->uart you can DMA everything and move data around at very low cost in terms of application performance and bottlenecked only by the ethernet->uart transceiver.

And correct, I only mean to talk of the f207 chips, I dont think an f107 is in the cards...

Posted 4 years ago #
dreamcat4
Member

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.

Posted 4 years ago #
gbulmer
Moderator

This is a great N-dimensional analysis problem :-)

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->uart/spi chip on a ethernet-maple product.

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.

I am interested in ethernet, but I am more interested in wireless (802.15.4), and very interested in both.

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.
In that scenario, I can't see much benefit from a UART/ethernet device in terms of flash memory footprint. Am I missing something?

Is the processing overhead really much less on a UART than on-board?
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.

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?

Posted 4 years ago #
dreamcat4
Member

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.
In that scenario, I can't see much benefit from a UART/ethernet device in terms of flash memory footprint. Am I missing something?

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.

Is the processing overhead really much less on a UART than on-board?

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.

Posted 4 years ago #

RSS feed for this topic

« Previous 123 Next »

Reply »

You must log in to post.