Reply by Jas August 18, 20042004-08-18
The yahoo group for Netburner problems is now open ...

http://groups.yahoo.com/group/netburner_group/
Reply by Jas August 6, 20042004-08-06
> 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. > > > Paul Breed > CTO Netburner.
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
Reply by July 13, 20042004-07-13
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


In article <f0c5236f.0407071340.3d55568d@posting.google.com>, astanko@gwdg.de 
(Anguel Stankov) wrote:
>Hi all! > >I read a lot of discussions about Netburner vs. Rabbit. >No doubt - the Coldfire is a very nice microcontroller and the >Netburner prices are really great with all the software included >(RTOS, TCP/IP, etc.). On the other hand a few weeks ago I bought a >Systronix SaJe module with an aJile Java CPU (after reading some >hype-inspired articles) and was really disappointed how bad the >software is - it is just NOT usable for real products and now I don't >want to make the same mistake. >So my question is, if there is someone out there selling real-world >products with Netburner modules and software inside. On the Rabbit >site (competition) there are some references from companies using >their modules, on the Netburner site this is not the case. >So there are still some questions left regarding the Netburner >modules: >1. How stable is the RTOS, I know that it is the old uCOS I with >Netburner-made extensions. >2. How stable is the TCP/IP stack? Is it reentrant and how well does >it integrate with the RTOS? For example the Rabbit docs say that their >TCP/IP is reentrant but on the other hand there are some restrictions >like "don't call the TCP/IP from more than one task" - such things >make me think that there are still some incompatibilities :-( >3. How stable is the Netburner GCC compiler? Is the Coldfire port used >only by Netburner or also by other companies? How well is the >integration between the compiler and the Coldfire? >4. How good are the Netburner docs? I couldn't find any docs on their >site. The Rabbit site is full of docs. Does Netburner have any >discussion group? > >Thanks for any help! I hope that answers to these questions will also >help other people making a decision. > >Best regards, >Anguel
Reply by Brian Murtha July 9, 20042004-07-09
astanko@gwdg.de (Anguel Stankov) wrote in message news:<f0c5236f.0407090114.366a1f0e@posting.google.com>...
> 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. "
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.
Reply by Anguel Stankov July 9, 20042004-07-09
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

pbreed@netburner.com wrote in message news:<cecre01jaug7gu68srpljmij2m41db3dtl@4ax.com>...
> Please note that I work for Netburner and thus my response is biased. > > >So my question is, if there is someone out there selling real-world > >products with Netburner modules > Please send Mail to Sales at netburner and provide some idea of what industry you are in and they can provide apropriate references. > > > >1. How stable is the RTOS, I know that it is the old uCOS I with > >Netburner-made extensions. > The Netburner uCos code has been very stable with very few changes in the last 5 years. > > >2. How stable is the TCP/IP stack? Is it reentrant and how well does > >it integrate with the RTOS? For example the Rabbit docs say that their > >TCP/IP is reentrant but on the other hand there are some restrictions > >like "don't call the TCP/IP from more than one task" - such things > >make me think that there are still some incompatibilities :-( > > 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.... > > > >3. How stable is the Netburner GCC compiler? Is the Coldfire port used > >only by Netburner or also by other companies? How well is the > >integration between the compiler and the Coldfire? > 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. > > >4. How good are the Netburner docs? I couldn't find any docs on their > >site. > > 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. > > >Does Netburner have any > >discussion group? > 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. > > > >Thanks for any help! I hope that answers to these questions will also > >help other people making a decision. > Thank you for considering our product. > > Paul Breed > CTO Netburner.
Reply by Anguel Stankov July 9, 20042004-07-09
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


jfathman@aol.com (Jim) wrote in message news:<6dfb5332.0407080929.ad83f2f@posting.google.com>...
> 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
Reply by Anguel Stankov July 9, 20042004-07-09
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

bmurtha@zworld.com (Brian Murtha) wrote in message news:<c29d7dc6.0407080917.3c7273b0@posting.google.com>...

> 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
Reply by July 8, 20042004-07-08
Please note that I work for  Netburner and thus my response is biased.

>So my question is, if there is someone out there selling real-world >products with Netburner modules
Please send Mail to Sales at netburner and provide some idea of what industry you are in and they can provide apropriate references.
>1. How stable is the RTOS, I know that it is the old uCOS I with >Netburner-made extensions.
The Netburner uCos code has been very stable with very few changes in the last 5 years.
>2. How stable is the TCP/IP stack? Is it reentrant and how well does >it integrate with the RTOS? For example the Rabbit docs say that their >TCP/IP is reentrant but on the other hand there are some restrictions >like "don't call the TCP/IP from more than one task" - such things >make me think that there are still some incompatibilities :-(
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....
>3. How stable is the Netburner GCC compiler? Is the Coldfire port used >only by Netburner or also by other companies? How well is the >integration between the compiler and the Coldfire?
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.
>4. How good are the Netburner docs? I couldn't find any docs on their >site.
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.
>Does Netburner have any >discussion group?
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.
>Thanks for any help! I hope that answers to these questions will also >help other people making a decision.
Thank you for considering our product. Paul Breed CTO Netburner.
Reply by Jim July 8, 20042004-07-08
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


astanko@gwdg.de (Anguel Stankov) wrote in message news:<f0c5236f.0407071340.3d55568d@posting.google.com>...
> Hi all! > > I read a lot of discussions about Netburner vs. Rabbit. > No doubt - the Coldfire is a very nice microcontroller and the > Netburner prices are really great with all the software included > (RTOS, TCP/IP, etc.). On the other hand a few weeks ago I bought a > Systronix SaJe module with an aJile Java CPU (after reading some > hype-inspired articles) and was really disappointed how bad the > software is - it is just NOT usable for real products and now I don't > want to make the same mistake. > So my question is, if there is someone out there selling real-world > products with Netburner modules and software inside. On the Rabbit > site (competition) there are some references from companies using > their modules, on the Netburner site this is not the case. > So there are still some questions left regarding the Netburner > modules: > 1. How stable is the RTOS, I know that it is the old uCOS I with > Netburner-made extensions. > 2. How stable is the TCP/IP stack? Is it reentrant and how well does > it integrate with the RTOS? For example the Rabbit docs say that their > TCP/IP is reentrant but on the other hand there are some restrictions > like "don't call the TCP/IP from more than one task" - such things > make me think that there are still some incompatibilities :-( > 3. How stable is the Netburner GCC compiler? Is the Coldfire port used > only by Netburner or also by other companies? How well is the > integration between the compiler and the Coldfire? > 4. How good are the Netburner docs? I couldn't find any docs on their > site. The Rabbit site is full of docs. Does Netburner have any > discussion group? > > Thanks for any help! I hope that answers to these questions will also > help other people making a decision. > > Best regards, > Anguel
Reply by Brian Murtha July 8, 20042004-07-08
astanko@gwdg.de (Anguel Stankov) wrote in message news:<f0c5236f.0407071340.3d55568d@posting.google.com>...
> Hi all! > > I read a lot of discussions about Netburner vs. Rabbit. > No doubt - the Coldfire is a very nice microcontroller and the > Netburner prices are really great with all the software included > (RTOS, TCP/IP, etc.). On the other hand a few weeks ago I bought a > Systronix SaJe module with an aJile Java CPU (after reading some > hype-inspired articles) and was really disappointed how bad the > software is - it is just NOT usable for real products and now I don't > want to make the same mistake. > So my question is, if there is someone out there selling real-world > products with Netburner modules and software inside. On the Rabbit > site (competition) there are some references from companies using > their modules, on the Netburner site this is not the case. > So there are still some questions left regarding the Netburner > modules: > 1. How stable is the RTOS, I know that it is the old uCOS I with > Netburner-made extensions. > 2. How stable is the TCP/IP stack? Is it reentrant and how well does > it integrate with the RTOS? For example the Rabbit docs say that their > TCP/IP is reentrant but on the other hand there are some restrictions > like "don't call the TCP/IP from more than one task" - such things > make me think that there are still some incompatibilities :-(
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