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 1 of 2  [1] 2  Next page →

#27311 — Embedded Ethernet

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?

[toc] | [next] | [standalone]

#27312

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?

something based on wiznet chips ?

I think there is some ready solution from them

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

#27313

On 22/09/17 17:52, pozz wrote:
> There are many MCUs with embedded Ethernet (MAC). It seems most of the 
> open-source examples are lwip-based.

Yes - LWIP is very popular, and works well.

> 
> 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?

We have used Kinetis K64F, with LWIP.  But a lot will depend on the 
other features you need, speed, development resources, etc.  Don't skimp 
on the ram size for the microcontroller you get - it's a lot easier to 
use big buffers than to try to fine-tune them to exactly what you think 
you need.

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

#27421

Il 22/09/2017 20:27, David Brown ha scritto:
> On 22/09/17 17:52, pozz wrote:
>> There are many MCUs with embedded Ethernet (MAC). It seems most of the 
>> open-source examples are lwip-based.
> 
> Yes - LWIP is very popular, and works well.

Other questions on Embedded Ethernet based on lwip stack solution.

Actually I'm using a demo board with LPC1769 (with integrated MAC) and 
LAN8720 (Ethernet PHY). I arranged a simple HTTP server and it works (I 
started from example in LPCOpen libraries).

Now the problem is how to increase the security of communication over 
Internet. This isn't a simple task. In my application, it means adding 
HTTP authorization, strong encryption and so on.
Unfortunately lwip HTTP server doesn't support authentication (even the 
basic method) and encryption, so it must be added.

I think authentication and encryption is not a problem only with HTTP 
applications, but for all communication protocols over public networks 
(so MQTT, SMTP, SNMP and so on).

I understood *the solution* is TLS/SSL (I think HTTPS means HTTP over 
TLS). And TLS/SSL means strong encryption that needs some crypto hw 
engine (that LPC1769 doesn't have).

I know I can build the system from low-level blocks (lwip, ssl, 
http...), but it isn't simple for me.

So the final question is: is there some Silicon vendors that show secure 
communication examples on their demo boards with a ready-to-use example? 
Or some examples from other sources that shows how to achieve what I want?

Do you solve those problems in some way?

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

#27422

pozz <pozzugno@gmail.com> wrote:
> So the final question is: is there some Silicon vendors that show secure 
> communication examples on their demo boards with a ready-to-use example? 
> Or some examples from other sources that shows how to achieve what I want?

ARM owns/manages/encourages (or whatever, it's open source) mbedTLS, so
there are presumably examples for running it on a Cortex M.

I don't know whether that would be the right form factor for you, if you're
expecting to buy a module that 'does HTTPS', rather than placing a
microcontroller, MAC, PHY, etc yourself.

There might be an example for a microcontroller with integrated MAC, which
would simplify the hardware.

Theo

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

#27424

Il 17/11/2017 11:39, Theo Markettos ha scritto:
> pozz <pozzugno@gmail.com> wrote:
>> So the final question is: is there some Silicon vendors that show secure
>> communication examples on their demo boards with a ready-to-use example?
>> Or some examples from other sources that shows how to achieve what I want?
> 
> ARM owns/manages/encourages (or whatever, it's open source) mbedTLS, so
> there are presumably examples for running it on a Cortex M.

I found a ready-to-use example[1] from ST. I don't think I have found 
other similar examples from MCU vendors.
However I'll have to search better.


> I don't know whether that would be the right form factor for you, if you're
> expecting to buy a module that 'does HTTPS', rather than placing a
> microcontroller, MAC, PHY, etc yourself.
> 
> There might be an example for a microcontroller with integrated MAC, which
> would simplify the hardware.

I will use MCU with integrated MAC. Only the PHY (and RJ45) will be 
external.
However the problem here isn't hw, but only sw (the hw issue is only 
related to a crypto engine useful in encryption used by TLS).

[1] 
https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-standard-peripheral-library-expansion/stsw-stm32057.license%3d1510913831055.product%3dSTSW-STM32057.html

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

#27423

Op Fri, 17 Nov 2017 10:25:25 +0100 schreef pozz <pozzugno@gmail.com>:
> Il 22/09/2017 20:27, David Brown ha scritto:
>> On 22/09/17 17:52, pozz wrote:
>>> There are many MCUs with embedded Ethernet (MAC). It seems most of the  
>>> open-source examples are lwip-based.
>>  Yes - LWIP is very popular, and works well.
>
> Other questions on Embedded Ethernet based on lwip stack solution.
>
> Actually I'm using a demo board with LPC1769 (with integrated MAC) and  
> LAN8720 (Ethernet PHY). I arranged a simple HTTP server and it works (I  
> started from example in LPCOpen libraries).
>
> Now the problem is how to increase the security of communication over  
> Internet. This isn't a simple task. In my application, it means adding  
> HTTP authorization, strong encryption and so on.
> Unfortunately lwip HTTP server doesn't support authentication (even the  
> basic method) and encryption, so it must be added.
>
> I think authentication and encryption is not a problem only with HTTP  
> applications, but for all communication protocols over public networks  
> (so MQTT, SMTP, SNMP and so on).
>
> I understood *the solution* is TLS/SSL (I think HTTPS means HTTP over  
> TLS).

Nowadays yes. HTTP over SSL is deprecated.

> And TLS/SSL means strong encryption that needs some crypto hw engine  
> (that LPC1769 doesn't have).

All it *needs* is extra memory. It *benefits from* hw-crypto.

> I know I can build the system from low-level blocks (lwip, ssl,  
> http...), but it isn't simple for me.

Well-written APIs and good documentation usually helps. But embedded  
software is rarely simple.

> So the final question is: is there some Silicon vendors that show secure  
> communication examples on their demo boards with a ready-to-use example?  
> Or some examples from other sources that shows how to achieve what I  
> want?

Why silicon vendors?

> Do you solve those problems in some way?


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

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

#27425

Il 17/11/2017 11:36, Boudewijn Dijkstra ha scritto:
 >> [...]
>> And TLS/SSL means strong encryption that needs some crypto hw engine 
>> (that LPC1769 doesn't have).
> 
> All it *needs* is extra memory. It *benefits from* hw-crypto.

So the problem without an hw crypto engine is only RAM space?


>> I know I can build the system from low-level blocks (lwip, ssl, 
>> http...), but it isn't simple for me.
> 
> Well-written APIs and good documentation usually helps. But embedded 
> software is rarely simple.

Another good thing that helps is a ready-to-use example from MCU vendor 
that works on a demo board.


>> So the final question is: is there some Silicon vendors that show 
>> secure communication examples on their demo boards with a ready-to-use 
>> example? Or some examples from other sources that shows how to achieve 
>> what I want?
> 
> Why silicon vendors?

MCU (Silicon) vendors usually sells demo boards to show all the feaures 
of its products. And usually give many ready-to-use examples that works 
without any change on the demo boards.

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

#27426

On 17/11/17 10:25, pozz wrote:
> Il 22/09/2017 20:27, David Brown ha scritto:
>> On 22/09/17 17:52, pozz wrote:
>>> There are many MCUs with embedded Ethernet (MAC). It seems most of
>>> the open-source examples are lwip-based.
>>
>> Yes - LWIP is very popular, and works well.
> 
> Other questions on Embedded Ethernet based on lwip stack solution.
> 
> Actually I'm using a demo board with LPC1769 (with integrated MAC) and
> LAN8720 (Ethernet PHY). I arranged a simple HTTP server and it works (I
> started from example in LPCOpen libraries).
> 
> Now the problem is how to increase the security of communication over
> Internet. This isn't a simple task. In my application, it means adding
> HTTP authorization, strong encryption and so on.
> Unfortunately lwip HTTP server doesn't support authentication (even the
> basic method) and encryption, so it must be added.
> 
> I think authentication and encryption is not a problem only with HTTP
> applications, but for all communication protocols over public networks
> (so MQTT, SMTP, SNMP and so on).
> 
> I understood *the solution* is TLS/SSL (I think HTTPS means HTTP over
> TLS). And TLS/SSL means strong encryption that needs some crypto hw
> engine (that LPC1769 doesn't have).

I recommend you read a bit about how these work (start with wikipedia).
 SSL is the older standard - TLS 1.0 was effectively SSL 3.0.  But the
names are often used interchangeably.

TLS provides encryption, but only a limited form of authentication.  You
/can/ use TLS certificates for identification, but usually they are only
used for the client to check that the server has a signed certificate
that is valid for its DNS name.  If you want usernames, passwords, etc.,
you need to do that in other ways - and TLS just means you can transfer
them securely.

TLS is big and complicated.  It takes a good deal of code, and a good
deal of processor resources.  (It does not /need/ crypto hardware, but
some TLS implementations can take advantage of it.)  The implementations
that I know of are either very big and flexible and under licenses such
as the GPL, or efficient for small systems but have paid commercial
licenses.  I don't know if that is an issue for you.

> 
> I know I can build the system from low-level blocks (lwip, ssl,
> http...), but it isn't simple for me.
> 
> So the final question is: is there some Silicon vendors that show secure
> communication examples on their demo boards with a ready-to-use example?
> Or some examples from other sources that shows how to achieve what I want?
> 
> Do you solve those problems in some way?

We have simply not used TLS/SSL.  For some systems, the networking is
within a closed local network - encryption and authentication is not an
issue.  Any remote access will be via gateways with VPN's and the like.

For other systems, we do it independently of the connection.  For
example, one system downloads firmware updates from a server using
normal http.  The package itself is encrypted and digitally signed, so
the receiving system can check that it is valid.  That way there is no
need to support the vast monstrosity of TLS and all its options and
certificates - we can have one simple encryption and authentication
routine in the embedded system.  I don't remember off-hand what it is -
probably AES.

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

#27427

pozz <pozzugno@gmail.com> writes:

> Now the problem is how to increase the security of communication over
> Internet. This isn't a simple task. In my application, it means adding
> HTTP authorization, strong encryption and so on.
> Unfortunately lwip HTTP server doesn't support authentication (even
> the basic method) and encryption, so it must be added.
>
> I think authentication and encryption is not a problem only with HTTP
> applications, but for all communication protocols over public networks
> (so MQTT, SMTP, SNMP and so on).
>
> I understood *the solution* is TLS/SSL (I think HTTPS means HTTP over
> TLS). And TLS/SSL means strong encryption that needs some crypto hw
> engine (that LPC1769 doesn't have).

We're using TLS with client side (and server side) certificates to do
authentication (i.e. knowing who the other party is and create a secure
channel). Keys can be kept on a separate TPM chip.

Authorization (who is allowed to do what) is more complex issue,
basically our server is allowed to do almost anything, except update
firmware. Firmware is signed with separate key.

We're running Linux on AM3352, though. I found references of mbedTLS
being able to use client side certificates, but setting up the whole
system may not be that easy. On Linux stunnel is a nice way to tunnel
traffic if you don't want to do TLS connections from your
application.

Separate crypto engine is not necessarily needed, it just gives you more
security (key storage) or performance (crypto functionality).

--
mikko

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

#27314

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?
What are your encryption requirements?
What type of processing power do you need for this protocol to be defined?
What ethernet speed do you need / want?
What is your power budget?

-- 
Chisolm
Republic of Texas

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

#27315

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.

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


 > 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?


 > What is your power budget?
No problem.


I usually use Atmel/Microchip SAM Cortex-M MCUs. I saw SAM E70 and 
similar devices. They have an internal MAC controller with RMII 
interface for external PHY. There are some examples with lwip.

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.

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

#27317

> Is there an RJ45 connector with integrated magnetics and PHY in order to 

Plenty.

MC001515
MC001514
JXD2-0010NL
LMJ2138814S0L1T1C
and many more...

> reduce PCB space? I don't think there MCUs with integrated MAC+PHY.

TM4C129X family from TI
Wiznet W7500

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

#27318

sâmbătă, 23 septembrie 2017, 08:38:18 UTC+3, raimond....@gmail.com a scris:
> > Is there an RJ45 connector with integrated magnetics and PHY in order to 
> 
> Plenty.
> 
> MC001515
> MC001514
> JXD2-0010NL
> LMJ2138814S0L1T1C
> and many more...
> 
> > reduce PCB space? I don't think there MCUs with integrated MAC+PHY.
> 
> TM4C129X family from TI
> Wiznet W7500

I mean W7500P whith the "P" standing for "PHY".

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

#27319

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.

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.

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.

> 
>  > What are your encryption requirements?
> Another question? ;-)
> 
> 
>  > 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.)

> 
>  > What is your power budget?
> No problem.
> 
> 
> I usually use Atmel/Microchip SAM Cortex-M MCUs. I saw SAM E70 and 
> similar devices. They have an internal MAC controller with RMII 
> interface for external PHY. There are some examples with lwip.
> 

That will probably be fine.  I haven't use Atmel's ARM devices, but I 
believe they are a perfectly reasonable choice.

> 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.

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

#27320

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.

Cheers

Phil Hobbs


-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

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

#27322

On 23.9.2017 г. 13:32, Phil Hobbs wrote:
> On 09/23/2017 06:02 AM, David Brown wrote:
> ......
>>
>> 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.

It is a non-issue really. The 16 bit checksum is just within tcp, but
the IP layer is either embedded within Ethernet frames which have
a robust enough CRC or within a PPP frame which typically has 32 bit
CRC. Not sure one can encounter a situation where this would be
an issue - but then it is a wide world, who knows. Certainly no
issue over Ethernet though.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

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

#27327

On 09/23/2017 08:31 AM, Dimiter_Popoff wrote:
> On 23.9.2017 г. 13:32, Phil Hobbs wrote:
>> On 09/23/2017 06:02 AM, David Brown wrote:
>> ......
>>>
>>> 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.
> 
> It is a non-issue really. The 16 bit checksum is just within tcp, but
> the IP layer is either embedded within Ethernet frames which have
> a robust enough CRC or within a PPP frame which typically has 32 bit
> CRC. Not sure one can encounter a situation where this would be
> an issue - but then it is a wide world, who knows. Certainly no
> issue over Ethernet though.

Good to know, thanks.

Cheers

Phil Hobbs


-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

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

#27328

On Mon, 25 Sep 2017 13:07:43 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>On 09/23/2017 08:31 AM, Dimiter_Popoff wrote:
>> On 23.9.2017 ?. 13:32, Phil Hobbs wrote:
>>> On 09/23/2017 06:02 AM, David Brown wrote:
>>> ......
>>>>
>>>> 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.
>> 
>> It is a non-issue really. The 16 bit checksum is just within tcp, but
>> the IP layer is either embedded within Ethernet frames which have
>> a robust enough CRC or within a PPP frame which typically has 32 bit
>> CRC. Not sure one can encounter a situation where this would be
>> an issue - but then it is a wide world, who knows. Certainly no
>> issue over Ethernet though.
>
>Good to know, thanks.


At least in the past, there have been cases where frames/packets have
been damaged *inside* routers or switches.  There's a lot to be said
for an end-to-end checksum, even if it isn't super strong.

In any event, if you want a much stronger check (although not one
providing recoverability), you can just insist on an SSL/TLS
connection.

An area where the 16-bit TCP/IP checksum clearly show itself to be
inadequate was with some high-error-rate links without their own
protection.  Dial-up SLIP was a good example.  PPP's checksum (when
used on dial-up) was also too weak (but far better than the
non-existent one on SLIP), but most of the time it got combined with
error correcting modems underneath, and since it was a different
checksum than TCP/IP used, the net result was better than either
alone.

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

#27329

On 25.9.2017 г. 23:31, Robert Wessel wrote:
> On Mon, 25 Sep 2017 13:07:43 -0400, Phil Hobbs
> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>
>> On 09/23/2017 08:31 AM, Dimiter_Popoff wrote:
>>> On 23.9.2017 ?. 13:32, Phil Hobbs wrote:
>>>> On 09/23/2017 06:02 AM, David Brown wrote:
>>>> ......
>>>>>
>>>>> 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.
>>>
>>> It is a non-issue really. The 16 bit checksum is just within tcp, but
>>> the IP layer is either embedded within Ethernet frames which have
>>> a robust enough CRC or within a PPP frame which typically has 32 bit
>>> CRC. Not sure one can encounter a situation where this would be
>>> an issue - but then it is a wide world, who knows. Certainly no
>>> issue over Ethernet though.
>>
>> Good to know, thanks.
>
>
> At least in the past, there have been cases where frames/packets have
> been damaged *inside* routers or switches.  There's a lot to be said
> for an end-to-end checksum, even if it isn't super strong.
>
> In any event, if you want a much stronger check (although not one
> providing recoverability), you can just insist on an SSL/TLS
> connection.
>
> An area where the 16-bit TCP/IP checksum clearly show itself to be
> inadequate was with some high-error-rate links without their own
> protection.  Dial-up SLIP was a good example.  PPP's checksum (when
> used on dial-up) was also too weak (but far better than the
> non-existent one on SLIP), but most of the time it got combined with
> error correcting modems underneath, and since it was a different
> checksum than TCP/IP used, the net result was better than either
> alone.
>

It has been about 15 years since I last implemented tcp/ip and ppp
but I think ppp - with 32 bit CRC as I used to have it most of the
time IIRC - was fairly robust. The phone line I had back then was
pathetic, 4 phones switched into a twisted pair by a box out in
the rain, whatever the modem I got 14400 bps max. Then again I
can't swear I never had a damaged packet but having one at 32 bit
CRC which then makes it through the tcp segment checksum seems
really unlikely. I do find the tcp checksum as it is quite adequate.
I have never done SLIP so I can't comment on that, but if it relied
solely on the modem error correction well, this may have been
insufficient.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web