Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27311 > unrolled thread

Embedded Ethernet

Back to article view | Back to comp.arch.embedded

Contents

  Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-09-22 17:52 +0200
    Re: Embedded Ethernet mmm <m.colandrea@libero.it> - 2017-09-22 18:00 +0200
    Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-09-22 20:27 +0200
      Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-11-17 10:25 +0100
        Re: Embedded Ethernet Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-11-17 10:39 +0000
          Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-11-17 12:25 +0100
        Re: Embedded Ethernet "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2017-11-17 11:36 +0100
          Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-11-17 12:54 +0100
        Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-11-17 15:23 +0100
        Re: Embedded Ethernet Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2017-11-18 11:29 +0200
    Re: Embedded Ethernet Joe Chisolm <jchisolm6@earthlink.net> - 2017-09-22 13:31 -0500
      Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-09-23 00:01 +0200
        Re: Embedded Ethernet raimond.dragomir@gmail.com - 2017-09-22 22:38 -0700
          Re: Embedded Ethernet raimond.dragomir@gmail.com - 2017-09-22 22:41 -0700
        Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-09-23 12:02 +0200
          Re: Embedded Ethernet Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-23 06:32 -0400
            Re: Embedded Ethernet Dimiter_Popoff <dp@tgi-sci.com> - 2017-09-23 15:31 +0300
              Re: Embedded Ethernet Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-25 13:07 -0400
                Re: Embedded Ethernet Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:31 -0500
                  Re: Embedded Ethernet Dimiter_Popoff <dp@tgi-sci.com> - 2017-09-27 01:50 +0300
            Re: Embedded Ethernet Les Cargill <lcargill99@comcast.com> - 2017-09-28 20:07 -0500
          Re: Embedded Ethernet upsidedown@downunder.com - 2017-09-23 14:48 +0300
          Re: Embedded Ethernet Les Cargill <lcargill99@comcast.com> - 2017-09-28 20:06 -0500
            Re: Embedded Ethernet Joe Chisolm <jchisolm6@earthlink.net> - 2017-09-29 09:41 -0500
            Re: Embedded Ethernet upsidedown@downunder.com - 2017-09-30 18:49 +0300
          Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-10-12 11:26 +0200
            Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-10-12 12:46 +0200
            Re: Embedded Ethernet Joe Chisolm <jchisolm6@earthlink.net> - 2017-10-12 10:49 -0500
        Re: Embedded Ethernet Grant Edwards <invalid@invalid.invalid> - 2017-09-23 20:40 +0000
          Re: Embedded Ethernet Joe Chisolm <jchisolm6@earthlink.net> - 2017-09-23 19:24 -0500
            Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-09-24 13:28 +0200
    Re: Embedded Ethernet Les Cargill <lcargill99@comcast.com> - 2017-09-22 21:12 -0500
    Re: Embedded Ethernet Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-09-24 11:01 +0300
    Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-10-16 14:10 +0200
      Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-10-16 15:10 +0200
        Re: Embedded Ethernet pozz <pozzugno@gmail.com> - 2017-10-16 17:54 +0200
          Re: Embedded Ethernet David Brown <david.brown@hesbynett.no> - 2017-10-16 23:45 +0200
            lwip/httpd: how to return dynamic data [was Re: Embedded Ethernet] pozz <pozzugno@gmail.com> - 2017-11-13 12:11 +0100
              Re: lwip/httpd: how to return dynamic data [was Re: Embedded Ethernet] David Brown <david.brown@hesbynett.no> - 2017-11-13 14:14 +0100

Page 2 of 2 — ← Prev page 1 [2]

#27331

Phil Hobbs wrote:
> On 09/23/2017 06:02 AM, David Brown wrote:
>> On 23/09/17 00:01, pozz wrote:
>>> Il 22/09/2017 20:31, Joe Chisolm ha scritto:
>>>> On Fri, 22 Sep 2017 17:52:01 +0200, pozz wrote:
>>>>
>>>>> There are many MCUs with embedded Ethernet (MAC). It seems
>>>>> most
>>> of the
>>>>> open-source examples are lwip-based.
>>>>>
>>>>> I have to design a board with one RS485 port and one
>>>>> Ethernet
>>> port. It
>>>>> could be seen as a serial-to-Ethernet converter, where the
>>> protocol on
>>>>> RS485 is proprietary. On Ethernet side I will contact a
>>>>> server
>>> (cloud)
>>>>> with a protocol that must be defined.
>>>>>
>>>>> At the moment, I don't need to implement a server, only a
>>>>> simple
>>> client.
>>>>>
>>>>> Do you suggest some hw/fw platforms that you think are
>>>>> better
>>> than others?
>>>>
>>>> How are you connecting to this "cloud" server?  Simple TCP or
>>>> UDP
>>> or is it
>>>> some type of web services?
>>> I can choose. I know UDP is much smaller than TCP, but I should
>>> add some TCP-features on top of UDP: mainly ack and
>>> retransmissions. So I can argue TCP is overall better than UDP.
>>
>> You certainly /can/ argue that!  TCP/IP has many advantages over
>> UDP. The key ones are that it saves you worrying about reinventing
>> the wheel here.  With UDP, you never know if your data got
>> transferred - so you need application layers to handle that.  With
>> TCP/IP, you know that either the data is transferred correctly, or
>> you end up with a timeout and broken connection.  It keeps it a lot
>> simpler.
>
> One issue is that (iirc) TCP's 'guarantee' uses only a 16-bit
> checksum, which might not be long enough for high speed data on less
> than stellar connections.
>

If it's Ethernet, the MAC CRC is 32 bits and quite respectable.

-- 
Les Cargill



> Cheers
>
> Phil Hobbs
>
>

[toc] | [prev] | [next] | [standalone]

#27321

On Sat, 23 Sep 2017 12:02:17 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 23/09/17 00:01, pozz wrote:
>> Il 22/09/2017 20:31, Joe Chisolm ha scritto:
>>  > On Fri, 22 Sep 2017 17:52:01 +0200, pozz wrote:
>>  >
>>  >> There are many MCUs with embedded Ethernet (MAC). It seems most of the
>>  >> open-source examples are lwip-based.
>>  >>
>>  >> I have to design a board with one RS485 port and one Ethernet port. It
>>  >> could be seen as a serial-to-Ethernet converter, where the protocol on
>>  >> RS485 is proprietary. On Ethernet side I will contact a server (cloud)
>>  >> with a protocol that must be defined.
>>  >>
>>  >> At the moment, I don't need to implement a server, only a simple 
>> client.
>>  >>
>>  >> Do you suggest some hw/fw platforms that you think are better than 
>> others?
>>  >
>>  > How are you connecting to this "cloud" server?  Simple TCP or UDP or 
>> is it
>>  > some type of web services?
>> I can choose. I know UDP is much smaller than TCP, but I should add some 
>> TCP-features on top of UDP: mainly ack and retransmissions. So I can 
>> argue TCP is overall better than UDP.
>
>You certainly /can/ argue that!  TCP/IP has many advantages over UDP. 

The justification for two separate protocols depends on the usage.

For UDP (or raw Ethernet framing):
* Need hard real time performance: if a frame is lost or arrives too
late, just ignore it (e.g. audio/video samples). Retransmissions not
wanted. A frame sequence number should be enough.
* A local LAN segment is enough.

For TCP/IP:
* Reliable data transfer is required,  
* Unpredictable delays allowed (retransmissions).

>The key ones are that it saves you worrying about reinventing the wheel 
>here.  With UDP, you never know if your data got transferred - so you 
>need application layers to handle that.  

Only if every message needs to be reliably transferred.

>With TCP/IP, you know that 
>either the data is transferred correctly, or you end up with a timeout 
>and broken connection.  It keeps it a lot simpler.

Depends if you need reliable transfer or not.

>Also, TCP/IP is /far/ easier and more reliable when you have routing, 
>firewalls, VPNs, ssh tunnels, and all the other types of connections 
>that make IP networking so flexible and fun.

Fully agree on that.


>So use UDP if you need an absolute minimal system with minimal traffic 
>and latencies, but within a simple local LAN only.  Otherwise, go for 
>TCP/IP.

If you use really small devices ("IoT"), you might use UDP on the LAN
and if there is a bigger machine, such as a PC, you could use it as a
gateway to proper TCP/IP network. With IoT, you really need to think,
how and where to implement the data security issues

 
>>  > What are your encryption requirements?
>> Another question? ;-)

If you haven't thought about data security, you should really do it
now.

>> 
>> 
>>  > What type of processing power do you need for this protocol to be 
>> defined?
>> "processing power for the protocol"? It should be very simple, maybe 
>> MQTT. I would avoid HTTP.
>> 
>> 
>>  > What ethernet speed do you need / want?
>> I think this depends only to the PHY used... right?
>> 
>
>No, you need a MAC that handles the speed, as well as the PHY.  The MAC 
>is usually in the microcontroller.  For most flash-based 
>microcontrollers, MAC speeds will be 100 Mbit - Gbit MACs are more 
>common on bigger and faster embedded processors.  If you are thinking 
>bare metal or FreeRTOS, you are probably thinking 100 Mbit - if you want 
>Gbit, you are probably thinking Linux.
>
>Obviously you will also need a faster processor for Gbit to make sense. 
>(There is no problem using 100 Mbit devices on an otherwise Gbit network.)

Then there should not be a problem using 10 Mbit devices.


>>  > What is your power budget?
>> No problem.

So 10 or 10/100 PHY should be OK.

[toc] | [prev] | [next] | [standalone]

#27330

David Brown wrote:
> On 23/09/17 00:01, pozz wrote:
>> Il 22/09/2017 20:31, Joe Chisolm ha scritto:
>>> On Fri, 22 Sep 2017 17:52:01 +0200, pozz wrote:
>>>
>>>> There are many MCUs with embedded Ethernet (MAC). It seems most
>>>> of
>> the
>>>> open-source examples are lwip-based.
>>>>
>>>> I have to design a board with one RS485 port and one Ethernet
>> port. It
>>>> could be seen as a serial-to-Ethernet converter, where the
>> protocol on
>>>> RS485 is proprietary. On Ethernet side I will contact a server
>> (cloud)
>>>> with a protocol that must be defined.
>>>>
>>>> At the moment, I don't need to implement a server, only a
>>>> simple
>> client.
>>>>
>>>> Do you suggest some hw/fw platforms that you think are better
>>>> than
>> others?
>>>
>>> How are you connecting to this "cloud" server?  Simple TCP or
>>> UDP
>> or is it
>>> some type of web services?
>> I can choose. I know UDP is much smaller than TCP, but I should
>> add some TCP-features on top of UDP: mainly ack and
>> retransmissions. So I can argue TCP is overall better than UDP.
>
> You certainly /can/ argue that!  TCP/IP has many advantages over
> UDP. The key ones are that it saves you worrying about reinventing
> the wheel here.  With UDP, you never know if your data got
> transferred - so you need application layers to handle that.

I just last week had to put a dead man timer in a client to
detect whether the server had gone offline using TCP.

You'll end up rippling the protocol up to the app
layer no matter what :) You'll get a more performant
system with UDP.

<snip>
-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#27332

On Thu, 28 Sep 2017 20:06:15 -0500, Les Cargill wrote:

> David Brown wrote:
>> On 23/09/17 00:01, pozz wrote:
>>> Il 22/09/2017 20:31, Joe Chisolm ha scritto:
>>>> On Fri, 22 Sep 2017 17:52:01 +0200, pozz wrote:
>>>>
>>>>> There are many MCUs with embedded Ethernet (MAC). It seems most
>>>>> of
>>> the
>>>>> open-source examples are lwip-based.
>>>>>
>>>>> I have to design a board with one RS485 port and one Ethernet
>>> port. It
>>>>> could be seen as a serial-to-Ethernet converter, where the
>>> protocol on
>>>>> RS485 is proprietary. On Ethernet side I will contact a server
>>> (cloud)
>>>>> with a protocol that must be defined.
>>>>>
>>>>> At the moment, I don't need to implement a server, only a
>>>>> simple
>>> client.
>>>>>
>>>>> Do you suggest some hw/fw platforms that you think are better
>>>>> than
>>> others?
>>>>
>>>> How are you connecting to this "cloud" server?  Simple TCP or
>>>> UDP
>>> or is it
>>>> some type of web services?
>>> I can choose. I know UDP is much smaller than TCP, but I should
>>> add some TCP-features on top of UDP: mainly ack and
>>> retransmissions. So I can argue TCP is overall better than UDP.
>>
>> You certainly /can/ argue that!  TCP/IP has many advantages over
>> UDP. The key ones are that it saves you worrying about reinventing
>> the wheel here.  With UDP, you never know if your data got
>> transferred - so you need application layers to handle that.
> 
> I just last week had to put a dead man timer in a client to
> detect whether the server had gone offline using TCP.
> 
> You'll end up rippling the protocol up to the app
> layer no matter what :) You'll get a more performant
> system with UDP.
> 
> <snip>

+1

UDP is very applicable in many situations and many times much better
than TCP.  Unless you understand the pitfalls of TCP, it can bite you
in the ass.  You have to understand when you need blocking vs
non-blocking.  Delay tolerance and the list goes on.  With UDP you 
have to understand, and plan for, the lost packet.  Though this is
not as prevelant as it was many years ago.  Understand your network
environment, LAN only vs satellite WAN.

Consider the case where the TCP implementation has minimal buffering
or the app is pushing.  The app writes 3 buffers to the TCP socket.
The receive window is large enough for all 3 writes so you have 3
segments in flight.  Segment 1 gets the ACK and then the remote system
catches fire and dies a horiable death.  The client has to wait some
long time for a normal TCP timeout and then the question is "what of
the 3 buffers did the remote get"

If a simple UDP send/ack the client knows.  As previously mentioned
you also have the case of the client does not care if a packet is lost.

No one size fits all apps.  TCP has it's place and so does UDP.   

-- 
Chisolm
Republic of Texas

[toc] | [prev] | [next] | [standalone]

#27333

On Thu, 28 Sep 2017 20:06:15 -0500, Les Cargill
<lcargill99@comcast.com> wrote:

>David Brown wrote:
>> On 23/09/17 00:01, pozz wrote:
>>> Il 22/09/2017 20:31, Joe Chisolm ha scritto:
>>>> On Fri, 22 Sep 2017 17:52:01 +0200, pozz wrote:
>>>>
>>>>> There are many MCUs with embedded Ethernet (MAC). It seems most
>>>>> of
>>> the
>>>>> open-source examples are lwip-based.
>>>>>
>>>>> I have to design a board with one RS485 port and one Ethernet
>>> port. It
>>>>> could be seen as a serial-to-Ethernet converter, where the
>>> protocol on
>>>>> RS485 is proprietary. On Ethernet side I will contact a server
>>> (cloud)
>>>>> with a protocol that must be defined.
>>>>>
>>>>> At the moment, I don't need to implement a server, only a
>>>>> simple
>>> client.
>>>>>
>>>>> Do you suggest some hw/fw platforms that you think are better
>>>>> than
>>> others?
>>>>
>>>> How are you connecting to this "cloud" server?  Simple TCP or
>>>> UDP
>>> or is it
>>>> some type of web services?
>>> I can choose. I know UDP is much smaller than TCP, but I should
>>> add some TCP-features on top of UDP: mainly ack and
>>> retransmissions. So I can argue TCP is overall better than UDP.
>>
>> You certainly /can/ argue that!  TCP/IP has many advantages over
>> UDP. The key ones are that it saves you worrying about reinventing
>> the wheel here.  With UDP, you never know if your data got
>> transferred - so you need application layers to handle that.
>
>I just last week had to put a dead man timer in a client to
>detect whether the server had gone offline using TCP.
>
>You'll end up rippling the protocol up to the app
>layer no matter what :) You'll get a more performant
>system with UDP.
>
><snip>

I thought it was a standard practice to loop a test message from the
client application layer to the server application layer and back to
client application. Of course, the server needs to modify the message
in a predictable way, such as adding a constant (typically 1) or
negating the value (2's complement) before sending it back to the
client. 

Assuming the client increments the loopback value between
transmission, lost messages are easily detected as well as the two-way
propagation delay. This also makes it possible to generate alarms on
both client as well as server end for lost messages and typically
switch to a redundant channel etc.

It is important that the server/slave changes the loopback value. 

I once had a serial line system, in which the message was sent back as
such. The loopback messages indicated that the connection was OK, but
no application data did not get through. The problem was that the
request and reply loopback had the same format and a short between Tx
and Rx wires physically echoed the message, instead of going through
the server application level.

[toc] | [prev] | [next] | [standalone]

#27376

Il 23/09/2017 12:02, David Brown ha scritto:
 >> [...]
>> Is there an RJ45 connector with integrated magnetics and PHY in order 
>> to reduce PCB space? I don't think there MCUs with integrated MAC+PHY.
> 
> You want the MAC inside the MCU.  But you want an external PHY unless 
> you are desperate for board space.  There are a few MCU's with internal 
> PHY's, but these cost more than separate chips and have poorer 
> performance (power, speed, etc.).  Basically, the type of die stackup 
> you want for an MCU and a MAC is geared towards fast, low-power digital 
> switching.  But the PHY is quite high power and analogue, and is best 
> done with a different die stackup and feature size.  Thus if you put 
> both on the same die, you have serious compromises.
> 
> External PHY's can be very small, if you can handle the package types.
> 
> RJ45 with magnetics and LEDs are easily available.  They cost a little 
> more than separate parts, but not much more.

What about the PCB requirements with MAC and PHY separated? I understood 
there are two standards: MII and RMII.  RMII requires fewer lines.

Is it possible to design a simple two-layers PCB with MAC embedded in 
the MCU and an external PHY?  Do you know of examples of gerber/layout?

[toc] | [prev] | [next] | [standalone]

#27377

On 12/10/17 11:26, pozz wrote:
> Il 23/09/2017 12:02, David Brown ha scritto:
>  >> [...]
>>> Is there an RJ45 connector with integrated magnetics and PHY in order 
>>> to reduce PCB space? I don't think there MCUs with integrated MAC+PHY.
>>
>> You want the MAC inside the MCU.  But you want an external PHY unless 
>> you are desperate for board space.  There are a few MCU's with 
>> internal PHY's, but these cost more than separate chips and have 
>> poorer performance (power, speed, etc.).  Basically, the type of die 
>> stackup you want for an MCU and a MAC is geared towards fast, 
>> low-power digital switching.  But the PHY is quite high power and 
>> analogue, and is best done with a different die stackup and feature 
>> size.  Thus if you put both on the same die, you have serious 
>> compromises.
>>
>> External PHY's can be very small, if you can handle the package types.
>>
>> RJ45 with magnetics and LEDs are easily available.  They cost a little 
>> more than separate parts, but not much more.
> 
> What about the PCB requirements with MAC and PHY separated? I understood 
> there are two standards: MII and RMII.  RMII requires fewer lines.

Yes.  For 100 Mb Ethernet, MII has 4 Rx and 4 Tx lines running at 25 
MHz.  RMII has 2 Rx and 2 Tx lines at 50 MHz.  RMII also reduces the 
number of extra lines (collision detect, data valid, etc.).

> 
> Is it possible to design a simple two-layers PCB with MAC embedded in 
> the MCU and an external PHY?  Do you know of examples of gerber/layout?

I don't do much pcb design myself these days.  But it is rare that we do 
two layer pcbs.  Four layers (with one ground plane and 3 routing) makes 
it /far/ easier to meet EMC requirements with fewer filter components, 
as well as getting good quality on the analogue parts.  You can use 
smaller components, a denser layout, and a smaller board overall. 
Considering both design and production, and the cost of EMC testing and 
certification, we find four layer boards are usually cheaper than two 
layer ones, and faster and easier to design, as well as being a better 
product in the end.  We typically only use two layer boards for the very 
highest volume boards, or the very simplest boards.

I would not expect an MCU with built-in MAC on a two layer board to be 
significantly cheaper or easier than an external MAC and a four layer 
board, and you will be much more restricted on your choice of MCU.  It 
is up to you to figure out the economics here, of course - it depends on 
quantities, costs, production facilities, development times and costs 
(don't forget to consider differences in software development times when 
using the hardware designer's choice of MCU rather than the software 
designer's choice!).

[toc] | [prev] | [next] | [standalone]

#27384

On Thu, 12 Oct 2017 11:26:11 +0200, pozz wrote:

> Il 23/09/2017 12:02, David Brown ha scritto:
>  >> [...]
>>> Is there an RJ45 connector with integrated magnetics and PHY in order 
>>> to reduce PCB space? I don't think there MCUs with integrated MAC+PHY.
>> 
>> You want the MAC inside the MCU.  But you want an external PHY unless 
>> you are desperate for board space.  There are a few MCU's with internal 
>> PHY's, but these cost more than separate chips and have poorer 
>> performance (power, speed, etc.).  Basically, the type of die stackup 
>> you want for an MCU and a MAC is geared towards fast, low-power digital 
>> switching.  But the PHY is quite high power and analogue, and is best 
>> done with a different die stackup and feature size.  Thus if you put 
>> both on the same die, you have serious compromises.
>> 
>> External PHY's can be very small, if you can handle the package types.
>> 
>> RJ45 with magnetics and LEDs are easily available.  They cost a little 
>> more than separate parts, but not much more.
> 
> What about the PCB requirements with MAC and PHY separated? I understood 
> there are two standards: MII and RMII.  RMII requires fewer lines.
> 

The SMSC (now Microchip) LAN8720 and LAN8740 PHYs are simple to use.  The
8720 talks RMII only.  An external PHY will not add significally to your
board cost.  The issue is do you have the space given your board size
constraints.  The 8720/8740 have built in LDOs so you only have to feed
them 3.3V.  You need to check the PHY power requirements.  You are gonna
need a 25Mhz or 50Mhz clock to feed the PHY or possibly a XTAL depending
on the PHY.

> Is it possible to design a simple two-layers PCB with MAC embedded in 
> the MCU and an external PHY?  Do you know of examples of gerber/layout?

You might be able to get by with a 2 layer but you will probably run out
of routing space.  You can be a little sloppy with the MII lines.  With
these newer PHYS you can route the cable side RX/TX pairs around a board
and still get error free results.  I have a board that brings the RX/TX
pairs from a back plane connector, to a front side MUX. There is also 
a front side RJ45.  Depending on the config the uC flips the mux to 
either the backplane port or front RJ45.

Look at the data sheets and design refs for the various PHYs.  There
is a lot of information out there.  Also software support for your
uC.  Picking a PHY that has a code base for your given uC and OS will
save you a lot of time.

-- 
Chisolm
Republic of Texas

[toc] | [prev] | [next] | [standalone]

#27323

On 2017-09-22, pozz <pozzugno@gmail.com> wrote:

> I can choose. I know UDP is much smaller than TCP,

UDP is also far less likey that TCP to make it safely through
firewalls and routers.

> but I should add some TCP-features on top of UDP: mainly ack and
> retransmissions.

If you're going to have to re-invent TCP, then just use TCP and avoid
all of the headaches you'll have with UDP and firewalls/routers.

-- 
Grant Edwards               grant.b.edwards        Yow! Am I having fun yet?
                                  at               
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#27324

On Sat, 23 Sep 2017 20:40:04 +0000, Grant Edwards wrote:

> On 2017-09-22, pozz <pozzugno@gmail.com> wrote:
> 
>> I can choose. I know UDP is much smaller than TCP,
> 
> UDP is also far less likey that TCP to make it safely through
> firewalls and routers.
> 
>> but I should add some TCP-features on top of UDP: mainly ack and
>> retransmissions.
> 
> If you're going to have to re-invent TCP, then just use TCP and avoid
> all of the headaches you'll have with UDP and firewalls/routers.

TCP wont necessarly fix a firewall issue.  All depends on the
firewall configuration for inbound traffic.  The firewall could
be configured to allow UDP traffic to a specific dest addr/dest port
For outbound many firewalls will allow a inbould UDP packet directed
to the same src addr/src port that generated the outgoing packet.

But I agree if you need close to guaranteeded data delivery a TCP
app is easier to build.  FreeRTOS/lwip is a reasonable choice.


-- 
Chisolm
Republic of Texas

[toc] | [prev] | [next] | [standalone]

#27326

On 24/09/17 02:24, Joe Chisolm wrote:
> On Sat, 23 Sep 2017 20:40:04 +0000, Grant Edwards wrote:
> 
>> On 2017-09-22, pozz <pozzugno@gmail.com> wrote:
>>
>>> I can choose. I know UDP is much smaller than TCP,
>>
>> UDP is also far less likey that TCP to make it safely through
>> firewalls and routers.
>>
>>> but I should add some TCP-features on top of UDP: mainly ack and
>>> retransmissions.
>>
>> If you're going to have to re-invent TCP, then just use TCP and avoid
>> all of the headaches you'll have with UDP and firewalls/routers.
> 
> TCP wont necessarly fix a firewall issue.  All depends on the
> firewall configuration for inbound traffic.  The firewall could
> be configured to allow UDP traffic to a specific dest addr/dest port
> For outbound many firewalls will allow a inbould UDP packet directed
> to the same src addr/src port that generated the outgoing packet.

Of course it all depends on the firewall setup.  And yes, you can get
UDP to work through firewalls.  But it is very difficult to get a
firewall setup that is secure and reliable, and safely lets through the
traffic you want and blocks traffic you don't want.  And it is even more
difficult when you have VPNs, tunnels, or other routes involved.  Such
routing is /really/ useful when you are testing and debugging network
systems - when you are sitting back in your office, connecting securely
to the customer network on the other side of the world, you will be glad
everything is running over TCP/IP.

> 
> But I agree if you need close to guaranteeded data delivery a TCP
> app is easier to build.  FreeRTOS/lwip is a reasonable choice.
> 
> 

[toc] | [prev] | [next] | [standalone]

#27316

pozz wrote:
> There are many MCUs with embedded Ethernet (MAC). It seems most of
> the open-source examples are lwip-based.
>
> I have to design a board with one RS485 port and one Ethernet port.
> It could be seen as a serial-to-Ethernet converter, where the
> protocol on RS485 is proprietary.

You mean the bits on the wire? RS485 is RS485 because it's an
actual standard.

> On Ethernet side I will contact a
> server (cloud) with a protocol that must be defined.
>
> At the moment, I don't need to implement a server, only a simple
> client.
>
> Do you suggest some hw/fw platforms that you think are better than
> others?

Can you use a USB to Ethernet converter? It won't be very fast but
it'll be Ethernet.


-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#27325

On 22.9.17 18:52, pozz wrote:
> There are many MCUs with embedded Ethernet (MAC). It seems most of the 
> open-source examples are lwip-based.
> 
> I have to design a board with one RS485 port and one Ethernet port. It 
> could be seen as a serial-to-Ethernet converter, where the protocol on 
> RS485 is proprietary. On Ethernet side I will contact a server (cloud) 
> with a protocol that must be defined.
> 
> At the moment, I don't need to implement a server, only a simple client.
> 
> Do you suggest some hw/fw platforms that you think are better than others?


I have built such things with the TI/Stellaris LM3S6965 with both
Ethernet MAC and PHY (10/100 Mbit/s) built-in. The chip is a
Cortex-M3, but according to TI, it is obsolete now, and they offer
the TMC4C129 instead. It has a development kit at about 25 USD,
the EK-TM4C129EXL.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#27401

Il 22/09/2017 17:52, pozz ha scritto:
> There are many MCUs with embedded Ethernet (MAC). It seems most of the 
> open-source examples are lwip-based.
> 
> I have to design a board with one RS485 port and one Ethernet port. It 
> could be seen as a serial-to-Ethernet converter, where the protocol on 
> RS485 is proprietary. On Ethernet side I will contact a server (cloud) 
> with a protocol that must be defined.
> 
> At the moment, I don't need to implement a server, only a simple client.
> 
> Do you suggest some hw/fw platforms that you think are better than others?

Another question related to embedded Ethernet.

If I implement a simple Web Server to remotely control the device from a 
standard Web Browser, I need some non volatile memory space to store web 
pages (html, css, images...).

It's difficult to estimate the amount of data I will need for "web 
server filesystem", however I think it's highly probable the internal 
Flash memory of MCU will not be sufficient.

So I need an external Flash memory. Of course I can use a parallel or 
serial Flash memory: parallel is faster, but it needs more space on PCB 
and more signals to route. Serial Flash are cheaper and simpler to 
integrate in the board, however they are slower... will it be sufficient?

I saw some LPC MCUs have a SPIFI peripheral that lets you use a serial 
SPI Flash and see it in the normal address space. I think it is a nice 
feature.

Do you have other suggestions how to increase storage size for web pages?

[toc] | [prev] | [next] | [standalone]

#27402

On 16/10/17 14:10, pozz wrote:
> Il 22/09/2017 17:52, pozz ha scritto:
>> There are many MCUs with embedded Ethernet (MAC). It seems most of the
>> open-source examples are lwip-based.
>>
>> I have to design a board with one RS485 port and one Ethernet port. It
>> could be seen as a serial-to-Ethernet converter, where the protocol on
>> RS485 is proprietary. On Ethernet side I will contact a server (cloud)
>> with a protocol that must be defined.
>>
>> At the moment, I don't need to implement a server, only a simple client.
>>
>> Do you suggest some hw/fw platforms that you think are better than
>> others?
> 
> Another question related to embedded Ethernet.
> 
> If I implement a simple Web Server to remotely control the device from a
> standard Web Browser, I need some non volatile memory space to store web
> pages (html, css, images...).
> 
> It's difficult to estimate the amount of data I will need for "web
> server filesystem", however I think it's highly probable the internal
> Flash memory of MCU will not be sufficient.
> 

That depends entirely on the MCU in question, and the complexity of the
web page.  I have no problem with webpages in the MCU I am using (512 KB
flash).

Note also that static data, such as images, javascript libraries, html
files, can easily be taken from an independent webserver as long as the
client has internet access - maybe you need nothing more than a "loader"
index.html and dynamic json "files" on your internal webserver.

> So I need an external Flash memory. Of course I can use a parallel or
> serial Flash memory: parallel is faster, but it needs more space on PCB
> and more signals to route. Serial Flash are cheaper and simpler to
> integrate in the board, however they are slower... will it be sufficient?

Parallel flash is not necessarily faster - serial flash can run quickly
if you have a fast SPI.  If your MCU supports quad SPI, it is probably
faster than you can get with an external parallel flash.  Plus, the
serial types are smaller, cheaper, and more flexible (it's easier to add
more storage without changing the board design).

Note also that even if your static data is sent slowly, it only needs to
be sent once - the client will cache it.  Keep your dynamic data nicely
separated, and you'll be fine.

> 
> I saw some LPC MCUs have a SPIFI peripheral that lets you use a serial
> SPI Flash and see it in the normal address space. I think it is a nice
> feature.
> 
> Do you have other suggestions how to increase storage size for web pages?

[toc] | [prev] | [next] | [standalone]

#27403

Il 16/10/2017 15:10, David Brown ha scritto:
> On 16/10/17 14:10, pozz wrote:
>> Il 22/09/2017 17:52, pozz ha scritto:
>>> There are many MCUs with embedded Ethernet (MAC). It seems most of the
>>> open-source examples are lwip-based.
>>>
>>> I have to design a board with one RS485 port and one Ethernet port. It
>>> could be seen as a serial-to-Ethernet converter, where the protocol on
>>> RS485 is proprietary. On Ethernet side I will contact a server (cloud)
>>> with a protocol that must be defined.
>>>
>>> At the moment, I don't need to implement a server, only a simple client.
>>>
>>> Do you suggest some hw/fw platforms that you think are better than
>>> others?
>>
>> Another question related to embedded Ethernet.
>>
>> If I implement a simple Web Server to remotely control the device from a
>> standard Web Browser, I need some non volatile memory space to store web
>> pages (html, css, images...).
>>
>> It's difficult to estimate the amount of data I will need for "web
>> server filesystem", however I think it's highly probable the internal
>> Flash memory of MCU will not be sufficient.
>>
> 
> That depends entirely on the MCU in question, and the complexity of the
> web page.  I have no problem with webpages in the MCU I am using (512 KB
> flash).

Thanks for sharing your experience.


> Note also that static data, such as images, javascript libraries, html
> files, can easily be taken from an independent webserver as long as the
> client has internet access - maybe you need nothing more than a "loader"
> index.html and dynamic json "files" on your internal webserver.

Good suggestion.


I have other two doubts.

RTOS (Free-RTOS) or not? I usually don't use RTOS and I never found it 
is necessary in my applications. However TCP/IP, HTTP server and a 
filesystem management could be tricky without an OS.

I studied the contrib example httpserver_raw in lwip project (an HTTP 
server without an OS). It uses a script (makefsdata) to create a virtual 
filesystem as a C source code. Is it ok for simple web pages?


The other question. What about dynamic content? The example seems show 
only static content.

[toc] | [prev] | [next] | [standalone]

#27405

On 16/10/17 17:54, pozz wrote:
> Il 16/10/2017 15:10, David Brown ha scritto:
>> On 16/10/17 14:10, pozz wrote:
>>> Il 22/09/2017 17:52, pozz ha scritto:
>>>> There are many MCUs with embedded Ethernet (MAC). It seems most of the
>>>> open-source examples are lwip-based.
>>>>
>>>> I have to design a board with one RS485 port and one Ethernet port. It
>>>> could be seen as a serial-to-Ethernet converter, where the protocol on
>>>> RS485 is proprietary. On Ethernet side I will contact a server (cloud)
>>>> with a protocol that must be defined.
>>>>
>>>> At the moment, I don't need to implement a server, only a simple 
>>>> client.
>>>>
>>>> Do you suggest some hw/fw platforms that you think are better than
>>>> others?
>>>
>>> Another question related to embedded Ethernet.
>>>
>>> If I implement a simple Web Server to remotely control the device from a
>>> standard Web Browser, I need some non volatile memory space to store web
>>> pages (html, css, images...).
>>>
>>> It's difficult to estimate the amount of data I will need for "web
>>> server filesystem", however I think it's highly probable the internal
>>> Flash memory of MCU will not be sufficient.
>>>
>>
>> That depends entirely on the MCU in question, and the complexity of the
>> web page.  I have no problem with webpages in the MCU I am using (512 KB
>> flash).
> 
> Thanks for sharing your experience.
> 
> 
>> Note also that static data, such as images, javascript libraries, html
>> files, can easily be taken from an independent webserver as long as the
>> client has internet access - maybe you need nothing more than a "loader"
>> index.html and dynamic json "files" on your internal webserver.
> 
> Good suggestion.
> 
> 
> I have other two doubts.
> 
> RTOS (Free-RTOS) or not? I usually don't use RTOS and I never found it 
> is necessary in my applications. However TCP/IP, HTTP server and a 
> filesystem management could be tricky without an OS.
> 
> I studied the contrib example httpserver_raw in lwip project (an HTTP 
> server without an OS). It uses a script (makefsdata) to create a virtual 
> filesystem as a C source code. Is it ok for simple web pages?
> 

An RTOS is not necessary for a web server.  Use one if you think it 
makes things easier for you, or not if you don't.  FreeRTOS is probably 
the most popular RTOS around, and is a good choice.  You can use LWIP 
with or without FreeRTOS.

In my most recent project with a webserver, I used LWIP but no RTOS.  I 
used a similar principle to makefsdata, but with my own scripts for 
putting the static content files into C const arrays of data.  I am 
quite happy making such scripts (in Python), so that suited me - but I 
am sure the LWIP demo and makefsdata will work fine too.

> 
> The other question. What about dynamic content? The example seems show 
> only static content.
> 

I handled that with JSON files.  So my static index.html file has 
(static) javascript, using jQuery, that regularly polls the board 
webserver for a file "data.json".  This is generated dynamically 
(basically just a big snprintf statement with the required data added), 
and the javascript running on the client then puts the data in the right 
places in the html.

[toc] | [prev] | [next] | [standalone]

#27419 — lwip/httpd: how to return dynamic data [was Re: Embedded Ethernet]

Il 16/10/2017 23:45, David Brown ha scritto:
[...]
>> The other question. What about dynamic content? The example seems show 
>> only static content.
>>
> 
> I handled that with JSON files.  So my static index.html file has 
> (static) javascript, using jQuery, that regularly polls the board 
> webserver for a file "data.json".  This is generated dynamically 
> (basically just a big snprintf statement with the required data added), 
> and the javascript running on the client then puts the data in the right 
> places in the html.

I'm trying to do exactly this: jQuery, polling, JSON data requests.
However I'm a little confused how to manage dynamic content with lwip 
and its httpd server.

I think dynamic content can be generated in a simple way by setting 
LWIP_HTTPD_CUSTOM_FILES and defining the function fs_open_custom() that 
snprintf() to a static string and set file content to that string.

int fs_open_custom(struct fs_file *file, const char *name) {
  if (!strcmp(name, "/data.json")) {
     static char json_data[1024];
     unsigned int idx = 0;

     idx += snprintf(&json_data[idx], sizeof(json_data) - idx, "{");

     idx += snprintf(&json_data[idx], sizeof(json_data) - idx,
         ...);

     idx += snprintf(&json_data[idx], sizeof(json_data) - idx, "}");

     return 1;
   }
   return 0;
}

The only problem is I can't access to query string params in 
fs_open_custom(). For example, I could have "/data.json?array=1" or 
"/data.json?array=23" or similar things.


Another problem is with CGI. After setting LWIP_HTTPD_CGI_SSI, I can 
define the CGI callback:

void httpd_cgi_handler(const char* uri, int iNumParams, char **pcParam,
     char **pcValue)
{
   if (!strcmp(uri, "/led.cgi")) {
     if ((iNumParams >= 1) &&
           !strcmp(pcParam[0], "status")) {
       if (!strcmp(pcValue[0], "on") led_on();
       if (!strcmp(pcValue[0], "off") led_off();
   }
}

Here there's another problem. How to return dynamic data to a CGI 
request, for example a result code, maybe in JSON format?
httpd_cgi_handler() doesn't return any data.

I could leave "/led.cgi" outside the static files and manage it as a 
custom file. However fs_open_custom() is called *before* 
httpd_cgi_handler(), so it's impossible to return a status code that 
depends on the CGI processing result.

Any help?

[toc] | [prev] | [next] | [standalone]

#27420 — Re: lwip/httpd: how to return dynamic data [was Re: Embedded Ethernet]

On 13/11/17 12:11, pozz wrote:
> Il 16/10/2017 23:45, David Brown ha scritto:
> [...]
>>> The other question. What about dynamic content? The example seems
>>> show only static content.
>>>
>>
>> I handled that with JSON files.  So my static index.html file has
>> (static) javascript, using jQuery, that regularly polls the board
>> webserver for a file "data.json".  This is generated dynamically
>> (basically just a big snprintf statement with the required data
>> added), and the javascript running on the client then puts the data in
>> the right places in the html.
> 
> I'm trying to do exactly this: jQuery, polling, JSON data requests.
> However I'm a little confused how to manage dynamic content with lwip
> and its httpd server.
> 
<snip>
> Any help?

Sorry - I wrote my own (simple and limited) httpd implementation.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web