Re: [lwip-users] Port to Stellarisware

[Philipp Tölke]

Hi all,

On 12/21/2017 1:23 AM, Ben Stuyts wrote:

TivaWare is TI's driver library / bare bones framework for the TM4C
family. It's stuck on lwIP version 1.4.1. As far as I know TI did
not express any interest in updating TivaWare to use newer lwIP.


LM3S series is NRND, and I wouldn’t touch the TM4C series with a ten
feet pole because of that. But we have a couple of designs with an
LM3S8938 that I’d like to update to get access to the latest lwIP
features.


The TM4C-Series is actually pretty decent. They have completely changed 
the peripherals that made the most problems (Ethernet, SSI, Flash).


Most relevant here, the Ethernet is much more fun especially if you want 
to support IEEE1588 (PTP) as we do.



We want to upgrade our code to 2.0.3 as well. If anyone knows of a
working port for this platform or what adaptations must be made
then please point us to it. Ben, if none exists then perhaps we can
combine our efforts.


Definitely interested. But if anybody has already done some work on
it, please let us know.


We are using a git-HEAD of a few month ago both with LM3S and TM4C; I 
will try to find time today or tomorrow to pull out relevant parts of 
our repository.


I have published our LM3S port in 
 a few years ago. 
I should update it.


Stay tuned!

Regards,
Philipp
--
Philipp Tölke
Head of Data Analytics
+49 89 99954258 | philipp.toe...@fos4x.de

--


fos4X GmbH | www.fos4x.de
Thalkirchner Str. 210, 81371 Munich, DE

Commercial Register: Amtsgericht Muenchen, HRB 189 218
Managing Director: Dr. Lars Hoffmann
Place of Business: Munich, DE

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Crash when doing stresstest with ppp and sockets/UDP

[zulu4711]

Thanks for input Simon!
Yes, it seems like a threading violation like I had before and this is
surely because of me not having a full insight to what is legal to call and
what is not legal to call in the stack when running in threaded mode.

I checked, and I called ppp_close() from another thread than I called
ppp_input() and I guess thats a big "no-no" ?

If only the functions where resistant to that when running with RTOS it
would have been great, but I guess a mechanism that would warn/assert
against this would also be very nice.
It seems that 75% of the problems newcomers like myself is due to threading
problems.




--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Crash when doing stresstest with ppp and sockets/UDP

[Sylvain Rochet]

Hi zulu4711,


On Thu, Dec 21, 2017 at 03:06:14AM -0700, zulu4711 wrote:
> 
> Yes, it seems like a threading violation like I had before and this is
> surely because of me not having a full insight to what is legal to call and
> what is not legal to call in the stack when running in threaded mode.
> 
> I checked, and I called ppp_close() from another thread than I called
> ppp_input() and I guess thats a big "no-no" ?

Of course it is, almost all ppp_* functions are *NOT* thread safe. You 
have to use pppapi_* functions outside the lwIP core thread.

While we are at it, I did not bother reading your code for correctness 
on this part, please check your PPP input function, only 
pppos_input_tcpip input method is thread safe.

You really should read the PPP documentation.


> It seems that 75% of the problems newcomers like myself is due to 
> threading problems.

Because threading is hard, it is really, really hard. This is why each 
time you call a function you have to ask yourself whether you are 
allowed to call it in this context or not.

On a more general note, that not necessarily apply here, before starting 
a project you should ask yourself whether a RTOS is actually necessary, 
generally it's not, from a not necessary at all to can be easily avoided 
range. Not using an RTOS makes everything an order of magnitude simpler, 
despite the overall belief of the contrary.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Port to Stellarisware

[Ben Stuyts]

> On 21 Dec 2017, at 10:08, Philipp Tölke  wrote:
> 
> Hi all,
> 
> On 12/21/2017 1:23 AM, Ben Stuyts wrote:
>>> TivaWare is TI's driver library / bare bones framework for the TM4C
>>> family. It's stuck on lwIP version 1.4.1. As far as I know TI did
>>> not express any interest in updating TivaWare to use newer lwIP.
>> LM3S series is NRND, and I wouldn’t touch the TM4C series with a ten
>> feet pole because of that. But we have a couple of designs with an
>> LM3S8938 that I’d like to update to get access to the latest lwIP
>> features.
> 
> The TM4C-Series is actually pretty decent. They have completely changed the 
> peripherals that made the most problems (Ethernet, SSI, Flash).

The ADC in the LM3S series was also seriously spec'ed down in an errata. 
Extremely high offset values if I remember correctly.

We have been seriously let down by TI regarding the LM3S series, so we're not 
designing in any cpu’s from them. Mainly using ST and NXP for new designs now.

> Most relevant here, the Ethernet is much more fun especially if you want to 
> support IEEE1588 (PTP) as we do.
> 
>>> We want to upgrade our code to 2.0.3 as well. If anyone knows of a
>>> working port for this platform or what adaptations must be made
>>> then please point us to it. Ben, if none exists then perhaps we can
>>> combine our efforts.
>> Definitely interested. But if anybody has already done some work on
>> it, please let us know.
> 
> We are using a git-HEAD of a few month ago both with LM3S and TM4C; I will 
> try to find time today or tomorrow to pull out relevant parts of our 
> repository.
> 
> I have published our LM3S port in 
>  a few years ago. I 
> should update it.
> 
> Stay tuned!

Sounds good, thanks!

Ben

> 
> Regards,
> Philipp
> -- 
> Philipp Tölke
> Head of Data Analytics
> +49 89 99954258 | philipp.toe...@fos4x.de
> 
> -- 
> 
> 
> fos4X GmbH | www.fos4x.de
> Thalkirchner Str. 210, 81371 Munich, DE
> 
> Commercial Register: Amtsgericht Muenchen, HRB 189 218
> Managing Director: Dr. Lars Hoffmann
> Place of Business: Munich, DE


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Crash when doing stresstest with ppp and sockets/UDP

[zulu4711]

Thanks for input!
I'm sorry, but I need to take a couple of steps back now (english is not my
native language...)
First of all the initialization sequence.

In my main() I changed now to:

dial the modem
starts a thread that will eventually feed serial data to
pppos_input() once everything is up and running.

sys_sem_new(_sem, 0);
tcpip_init(test_init, _sem);
// we have to wait for initialization to finish 
sys_sem_wait(_sem);
sys_sem_free(_sem);

As the test_init() must run in the main tcpip thread (as it calls the ppp
functions), correct ?

After this the worker threads are started (that will to
netcon_send/netcon_receive of UDP, and send/recv of socket data)


//
//
static void test_init(void * arg) { /* remove compiler warning */
const char *username = NULL, *password = NULL;
sys_sem_t *init_sem;
username = PPP_USERNAME;
password = PPP_PASSWORD;

init_sem = (sys_sem_t*)arg;


/* init randomizer again (seed per thread) */
srand((unsigned int)time(0));

ppp = pppos_create(_netif, ppp_output_cb, pppLinkStatusCallback, 
NULL);
if (ppp == NULL) {
messageDebug(DBG_INFO, __MODULE__, __LINE__, "pppos_create 
error");
} else {
ppp_set_auth(ppp, PPPAUTHTYPE_ANY, username, password);
pppapi_connect(ppp, 1);
}

netif_set_default(_netif);
netif_set_status_callback(_netif, status_callback); 
pppapi_set_notify_phase_callback(ppp, notify_phase_cb);
netif_set_link_callback(_netif, link_callback);

sys_sem_signal(init_sem);
}


The thread that is started that takes the SIO data and feeds them to
pppos_input() was something
I did as I understood from Simon that if PPP_INPROC_IRQ_SAFE is 1, that was
safe to do.

Can you explain to me if these assumptions are correct ?

Then I can try and explain afterwards the idea around bringing the line
up/down etc once all is running.




--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Port to Stellarisware

[Ben Stuyts]

> On 21 Dec 2017, at 04:54, Nathan Hartman  wrote:
> 
> On Dec 20, 2017, at 7:23 PM, Ben Stuyts  > wrote:
> 
>> Hi Nathan,
>> 
>>> On 20 Dec 2017, at 16:31, Nathan Hartman >> > wrote:
>>> 
>>> On Dec 20, 2017, at 10:17 AM, Ben Stuyts >> > wrote:
 
 TI’s Stellarisware library for the LM3S series chips uses lwIP v1.3.1. By 
 any chance, has anybody ported lwIP v2.0.3 to Stellarisware?
 
 They basically #include all the lwIP *.c files into a single lwiplib.c 
 file and compile that. Also not sure if their own interface/porting layer 
 code is compatible with v2.0.3.
>>> 
>>> Not sure if LM3S is the same family or related to TI's Tiva-C a.k.a. TM4C 
>>> family (TI bought Stellaris and renamed it to Tiva) but what Ben describes 
>>> is exactly how TivaWare implements lwIP.
>> 
>> Yes, same thing. Cortex M3 vs M4 core is the main difference. TI ran into 
>> manufacturing problems with the LM3S series and developed the TM4C as a 
>> successor. TI stopped support for Stellarisware for the LM3S series and then 
>> renamed/forked it to TivaWare (or some such) for the TM4C chips. In the 
>> beginning it was more or less compatible, but I believe (!) it has diverged 
>> quite a bit now.
>> 
>>> TivaWare is TI's driver library / bare bones framework for the TM4C family. 
>>> It's stuck on lwIP version 1.4.1. As far as I know TI did not express any 
>>> interest in updating TivaWare to use newer lwIP. 
>> 
>> LM3S series is NRND, and I wouldn’t touch the TM4C series with a ten feet 
>> pole because of that. But we have a couple of designs with an LM3S8938 that 
>> I’d like to update to get access to the latest lwIP features.
>> 
>>> We want to upgrade our code to 2.0.3 as well. If anyone knows of a working 
>>> port for this platform or what adaptations must be made then please point 
>>> us to it. Ben, if none exists then perhaps we can combine our efforts.
>> 
>> Definitely interested. But if anybody has already done some work on it, 
>> please let us know.
> 
> Are you familiar with e2e? Some searching has revealed this post:
> 
> I haven't studied in depth yet (will hopefully tomorrow morning) but 
> supposedly someone named John Piliounis has gotten 2.0.2 to work.
> 
> I'll see what else I can dig up. Perhaps the thing to do is to go naively and 
> replace the 1.4.1 files with 2.0.3 and see what happens.
> 
> The link:
> 
> https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/587288/2157245 
> 
No, I had not seen that. Thanks!

Ben

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Crash when doing stresstest with ppp and sockets/UDP

[zulu4711]

Thanks for input Sylvain!

I'm sure that I'm doing something wrong, I just need to find out what ;)
In the project this will eventually go into, I have around 300.000 lines of
C code and more than 50 separate threads running so a "non RTOS" operation
is not possible.

I was led to believe (not paying enough attention) that once you decide that
you want to run lwip in "RTOS mode", most will be protected and thread safe
and this is clearly not the case (my fault!)
(and I have actually been reading the documentation on lwip/ppp, but maybe
I'm just not getting all the hints in the various documents, I'm sure I'm
not alone in that)

The test I have running was/is organized as follows:

"sio thread":
  loops and:
calls pppos_input() with data from serial port (only when ppp != null,
ie ppos_create() etc has been called)
Note: PPP_INPROC_IRQ_SAFE is set to 1
when re-connecting is needed (signalled using flags) it calls
ppp_close() (when DCD goes away) and then ppp_connect() (when DCD comes
again)

"UDP worker thread":
  call netconn_send() and netconn_receive in a loop forever
  
"TCP worker thread":
  call send() and receive in a loop forever
  
Both the "UDP worker" and the "TCP worker" threads are each started twice
(so 4 "worker" threads are running)


"main thread":
  at startup/initialization it:
  starts the "SIO thread"
  dials the modem and waits for DCD (connected)
  calls tcpip_init(), pppos_create(), ppp_connect()
  waits for first time connection, then starts the other threads
  
  after this nothing more is done in the "main thread"!
  
This crashed (after 2 to 5 reconnect sessions).
I then changed the ppp_close() and ppp_connect() in the "SIO thread" to
pppapi_close() and pppapi_open(). 
This seems to work, at least it has been running much longer than without
using pppapi_ functions.

Once again, thanks for a nice project and all the help :)

Carsten




--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Crash when doing stresstest with ppp and sockets/UDP

[goldsimon]

goldsimon wrote:
> Core locking is really for the you layer only.

That should have been API layer!

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users