Netburner modules in real products?

snipped-for-privacy@gwdg.de (Anguel Stankov) wrote in message


Where did you read about this restriction? Early versions had a 1
TCP/IP socket per task restriction, but this is no longer the case.
-Brian

Hi Brian!

Check this
http://rabbitsemiconductor.com/documentation/SamplesRoadmap/tcpip-roadmap.htm#88919

It sais:
"Currently, at most one task can call any socket functions, and that
task's stack must be at least 2K in size. "

Regards,
Anguel

snipped-for-privacy@zworld.com (Brian Murtha) wrote in message

snipped-for-privacy@gwdg.de (Anguel Stankov) wrote in message

http://rabbitsemiconductor.com/documentation/SamplesRoadmap/tcpip-roadmap.htm#88919


Thanks, we need to update that. Tasks using sockets still need large
stacks (uC/OS-II stacks come from extended memory in our port, so this
isn't a problem), but the one socket per task limit is no longer true.

Hello Anguel,

I am a software developer for a company that uses the Netburner SB72
in a commercial product.  I wrote the application code that runs on
the Netburner board, using the Netburner supplied port of the GNU
toolchain.  I have about two years of fairly concentrated experience
with their board.

I am not a principal in my company so I would rather not name my
employer, but I can tell you that we have had good success integrating
the Netburner SB72 in our telecommunications product to add LAN and
Internet access where we previously only had serial and modem access.

We do more than just bridge Ethernet to serial using the Netburner
board.  Our application software running on the SB72 supports many
client PCs communicating via TCP and UDP (Ethernet), simultaneous with
other direct connected serial clients, to operate telecommunications
functions in real time.  During a typical day, a single board might
service several hundred brief TCP connection requests and send several
thousand UDP packets.  We move perhaps 20-50 MB of data per day.
Often this occurs with continuous streaming of sustained
serial-to-Ethernet traffic with 10 uC/OS tasks running.  The Netburner
software has been stable and reliable.

The OS appears to be a port of a very early version of uC/OS, modified
by Netburner to integrate Netburner's home grown TCP/IP stack.  I am
running multiple tasks, sharing the TCP/IP stack, and it works well.
But note that there are fixed resource limits, number of simultaneous
connections, etc., so you will want to make sure your application will
fit within the resource limits.

One thing Netburner does that I like is that they compress your
application before writing it to flash, and then they decompress it at
boot time when loading it to SRAM.  The compresion ratio is pretty
good, so I can fit quite a lot of application code in the 512KB flash.
 But the application storage isn't unlimited, so consider carefully
whether your application, now and in the future, will fit.

I haven't had any problems with the Netburner supplied GNU toolchain.
The documentation is ok, not great, but good enough to get started.
Once my base application was running, I seldom found the need to refer
to the Netburner documentation.

I would say that the Netburner documentation is adequate for a
practicing software engineer, but I imagine the Rabbit documentation
(which I have looked at online in the past, but not recently) is
better for a student or engineering novice who needs more background
information to get started with a first serial or TCP/IP application.

My experience is based on writing a Netburner application in C, not
C++.  Netburner implemented a simple wrapper class that is used to
send a UDP packet, so you have to compile your application as a C++
application to keep the compiler happy, but it is no problem to go
ahead and write C code and benefit from the stricter checking in the
GNU C++ compiler.  You don't have to know C++ in order to use the
Netburner libraries that are compiled as C++.  Perhaps someone else
will report on their experience writing their application in C++,
making full use of the language.

I experimented with the GDB/Insight graphical debugger provided by
Netburner.  It worked, but I generally don't used single-step GUI
debuggers (I use printf trace logging to serial ports and/or telnet
sessions), so I can't really say whether it holds up under rigorous
use.

I use Netburner's serial, TCP, UDP, and SMTP integration, with
success.  I have not tried their SNMP or SSL support.

I am not aware of a Netburner discussion site.  If you locate one, I
would be interested in joining.

Based on my positive experience, I would use the Netburner SB72 again
in a future design.

Regards,

Jim


snipped-for-privacy@gwdg.de (Anguel Stankov) wrote in message

Hi Jim!

Thanks for all the info, it really helped me a lot! In the meantime
Netburner sent me some of their docs and they look ok. I am very
impressed by their examples with the integrated web server in the
tutorial. Things like user parameter storage in flash and autoupdate
show that the solution offers a lot of nice ready-made APIs. And
because we want to use A/D and D/A in our devices the Coldfire is a
great microcontroller.
By the way on the Motorola Coldfire website there is a webcast on
Netburner devices. Ok, of course it is by Netburner but it shows the
capabilities of the package:
http://seminar2.techonline.com/%7Efutureamdmotorola22/nov2701 /

Regards,
Anguel


snipped-for-privacy@aol.com (Jim) wrote in message

Please note that I work for  Netburner and thus my response is biased.


Please send Mail to Sales at netburner and provide some idea of what industry
you are in and they can provide apropriate references.



The Netburner uCos code has been very stable with very few changes in the last 5
years.



The NetBurner Stack is fully reentrant.
All I/O goes through a file descriptor interface, so you can use TCP, Serial and
self developed streams
in a uniform way with select, read, write close etc....



NetBurner only switches to newer GCC compilers when others have had a lot
experience with them.
We are kind of slow in our switchover.

In 5 years we have had exactly 3 GCC/NewLib problems. All were actualy in NewLib
    1)Printf did not support long long variables.
    2)malloc had a reentrancy problem.
    3)floating point printf reentrancy problem.



Our documentaion is release specific so we are hesitant to post a generic
document not linked to a specific
release.  I have asked the WebMaster to post a copy of our programmers guide (it
is less release specific)  on the support page of the main site.
It should be up on the site  by this afternoon.
http://www.netburner.com/support/support.htm

If you send an E-Mail  request to dschiff at netburner with a spefcific module
type SB72, MOD5282 etc..,
she will send you a copy of all the apropriate docs. Be aware that they are
windows help files and also contain several large PDF documents.
The doc set is about  15Mbytes.

You can also look at some of the example articles under the support tab on our
website.


I personally monitor comp.arch.embedded ;-)

Seriously  NetBurner has already setup a Yahoo group, but we were not going to
announce it until some time next week.
We want to make sure that the people and processes are in place to monitor it an
provide a timely response.



Thank you for considering our product.

Paul Breed
CTO Netburner.

Hi Paul!

Thanks a lot for the info! It looks like you really have a very nice
product. So why not put some more product info and some more docs on
your site ;-)
Your webcast presentation found through the Motorola website also
gives many interesting details on your products, which I could not
find on your site.

Best regards,
Anguel

snipped-for-privacy@netburner.com wrote in message

you are in and they can provide apropriate references.

5 years.

and self developed streams

experience with them.

NewLib

document not linked to a specific

(it is less release specific)  on the support page of the main site.

http://www.netburner.com/support/support.htm

type SB72, MOD5282 etc..,

windows help files and also contain several large PDF documents.

website.

announce it until some time next week.

an provide a timely response.

announce it until some time next week.

an provide a timely response.


Paul,

It's now August, have you announced this Yahoo group yet?

Here's my 2pence worth :

I have been using the MCF5282 for a few months now, and I'm really
impressed both with the Coldfire MPU and the Netburner Development
Kit.

Support is 1st class too.


Thanks,

Jim Ramsay
UK

The yahoo group for Netburner problems is now open ...

http://groups.yahoo.com/group/netburner_group /

Anguel,
We use the Netburner products to give our analyzers a web browser interface
and they are very stable.
The software is good and well documented, and support is good.
Had a few problems of incompatibility between versions, but non that took over
a few hours to solve.
The hardware is also reliable and the prices are ok.
If at some point you decide to use your own hardware they offer a license that
is bether than most comercial RTOs that I know.

Regards,
Alberto Pasquale


(Anguel Stankov) wrote: