--- In r..., Scott Henion wrote:
>
> allsoft01a wrote:
> > How about the new 5k modules? Are they going to be any easier
to
> > work with?
> >
> >
> In my opinion, the 4k CPU is a big dud. Not any faster than the 3k
and
> you lose functionality due to less available I/O pins (up to 20
less.)
> Why they added 10 pins for ethernet, 8 pins lost for 16-bit RAM
support
> but still stuck with the 128-pin package is a mystery. A 160-pin
would
> have made it able to support the same amount of I/O as the 3k and
still
> have the added features.
>
> From what I see, the 5K just fixes the problems by providing more
pins.
> I did not see any new instructions mentioned. It also can run up to
> 100mHz. So it does have advantages over the 3k modules.
>
> We'll see about the 5k, it has built-in 10/100 ethernet. That
should
> help and should be fast. We'll see how long before ZW has a version
with
> ethernet working.
>
> And I do hope they fixed the 16-bit RAM bugs in the 5k ;)
Expanding a bit on what Lynn said, The R5000 CPU was completely
reworked to take advantage of a 16-bit bus. The R4000 takes
instructions and data a byte at a time, with a special prefetch unit
looking ahead to keep the instruction queue full. It also had special
hardware to do 16-bit writes, although to the CPU it was still two
byte writes. The R5000 can fetch and decode 16 bits at a time. It
also does 16-bit data reads and writes if the data is aligned. These
two changes provide significant speed-up for multi-byte instructions
and word data. They don't do anything for one-byte opcodes and byte
data though.

Another change to the CPU is what made the high clock frequency
possible. In previous generations a single clock was used to do both
the address calculation and the address translation, and this was
what limited clock frequency. In the R5000 separate clock cycles are
used for these two operations, resulting in a significantly higher
clock frequency. Of course this means an extra clock cycle in some
instructions, but this is more than compensated for by the increased
clock frequency.

As far as the R4000 pin count, that decision was made above my pay
grade...
Monte

I apologize. I didn't realize that my company email would block stuff
from the outside. Please, if you could resend your responses to
m...@yahoo.com I will be able to see them.
-MDiaz-Tello
--- In r..., "Bill_CT" wrote:
>
> --- In r..., "mdiaz.tello" wrote:
> >
> > Yeah, I actually sent an email to the address they have on their site
> > asking about support for Rabbit 4000 processors, but I haven't gotten
> > a response back from Softools yet.
>
> This is because the reply to that email was sent twice to you has
> bounced - so I have no way to contact you. If the address was valid,
> then email from our ISP is being blocked or rejected. Please email a
> different address to me - thanks.
>
> Bill
>

--- In r..., "mdiaz.tello" wrote:
>
> Yeah, I actually sent an email to the address they have on their site
> asking about support for Rabbit 4000 processors, but I haven't gotten
> a response back from Softools yet.

This is because the reply to that email was sent twice to you has
bounced - so I have no way to contact you. If the address was valid,
then email from our ISP is being blocked or rejected. Please email a
different address to me - thanks.

Bill

allsoft01a wrote:
> How about the new 5k modules? Are they going to be any easier to
> work with?
>
>
In my opinion, the 4k CPU is a big dud. Not any faster than the 3k and
you lose functionality due to less available I/O pins (up to 20 less.)
Why they added 10 pins for ethernet, 8 pins lost for 16-bit RAM support
but still stuck with the 128-pin package is a mystery. A 160-pin would
have made it able to support the same amount of I/O as the 3k and still
have the added features.

From what I see, the 5K just fixes the problems by providing more pins.
I did not see any new instructions mentioned. It also can run up to
100mHz. So it does have advantages over the 3k modules.

We'll see about the 5k, it has built-in 10/100 ethernet. That should
help and should be fast. We'll see how long before ZW has a version with
ethernet working.

And I do hope they fixed the 16-bit RAM bugs in the 5k ;)
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
[Brian and Peter are putting a crib together]
Brian Griffin: Okay, insert rod support A into slot B.
Peter Griffin: That's what...
Brian Griffin: If you say "that's what she said" one more time, I am gonna pop you.

mdiaz.tello wrote:
> I was wondering if there is anyone here who has actually programmed
> with softools on the RCM4200? I appreciate that people know it will
> work with the 4200, but i'd like to know how well it works. At work we
> looked into the differences between the 4300 and 4200 and there don't
> seem to be many, so we may end up switching to the 4200 for softools
> if it turns out it works well enough. I appreciate the feed back you
> guys have been giving me.
>
> -MDiaz-Tello
>
>

In the WinIDE yahoo group files are is the network patch and sample
program for the 4200. Email be if you want to try it in the demo.

Softools does not compile code to a specific module. The code is
generic. Really the only difference between modules is the memory map
and network. The ST startup is smart enough to set up the memory map at
run time and use the rabbit segment registers rather than DC's hardcoded
(and usually fragmented) mapping. The same .bin file can run on the
RCM2000, 3700, 3200 and 4200.

Network differences are handled by the ID to use the right init code.

The samples that come with Softools will work on the 4000 series, the
serial code will need a bit of help to set the routing to the pins.

the 4300 is odd. There is no main flash and programs are loaded from
serial flash via a PIC processor. This process is completely
undocumented and the format of the file system (if any) used n the
serial flash is also undocumented.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
[Brian and Peter are putting a crib together]
Brian Griffin: Okay, insert rod support A into slot B.
Peter Griffin: That's what...
Brian Griffin: If you say "that's what she said" one more time, I am gonna pop you.

How about the new 5k modules? Are they going to be any easier to
work with?

--- In r..., Scott Henion wrote:
>
> We don't have a timeline for support for the other 4k modules, we
are
> looking at it.
> --
> ------
> | Scott G. Henion| shenion@... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns http://www.shdesigns.org |
> ------
> Rabbit libs: http://www.shdesigns.org/rabbit/
> today's fortune
> It is wrong always, everywhere and for everyone to believe anything
upon
> insufficient evidence.
> - W. K. Clifford, British philosopher, circa 1876
>

I was wondering if there is anyone here who has actually programmed
with softools on the RCM4200? I appreciate that people know it will
work with the 4200, but i'd like to know how well it works. At work we
looked into the differences between the 4300 and 4200 and there don't
seem to be many, so we may end up switching to the 4200 for softools
if it turns out it works well enough. I appreciate the feed back you
guys have been giving me.

-MDiaz-Tello

--- In r..., "mdiaz.tello" wrote:
>
> I certainly understand that it is difficult to support hardware that
> has little to no documentation (and having wrong documentation is even
> worse than none). Case in point being the poor open source guys trying
> to reverse engineer proper graphics drivers. It is incredibly slow
> going for them, so I understand if there is no support for RCM4xxx in
> the near term. Thanks for all the help so far!
>
> -MDiaz-Tello
>
> --- In r..., Scott Henion wrote:
> >
> > Steve Trigero wrote:
> > >
> > > While others can give you more details about the Softools IDE, from
> > > what I've read, it is full ANSI, faster, and produces much more
> > > efficient
> > > code. I don't know how their editor is.
> >
> > And it supports far pointers even back to the R3000, has for
years. No
> > need for all that xmem2root() calls. So you get the far support on
all
> > the modules, not just the 4k modules.
> >
> > The editor is good. The debugger is far better as it doe snot have
the
> > data size limitations. It also does not use the RST 28's that slow
the
> > code down by 10-20%. Code runs full speed under the debugger.
> >
> > >
> > > The downside to Softools, so far, is that it seems to take them a
> long
> > > time
> > > to add new Rabbit features to their compiler as they come out.
> That they
> > > now support the Rabbit 4200 was news to me. That must be very
recent,
> > > because they have not supported any R4000 products until now. They
> > > also don't support some of the DC libraries. I'm sure they will in
> time.
> > > Maybe they can give you a development time-line if that's
> important for
> > > you.
> > >
> >
> > Adding new 3k modules is trivial, usually just adding the ID to
the net
> > init code.
> >
> > The 4k is a royal pain. The documentation is sparse and contains
wrong
> > information. The 16-bit RAM support has bugs that even the
workarounds
> > provided by ZW do not work. That has made supporting them near
> > impossible without proper documentation.
> >
> > ST runs the 4200 in 3k mode. The code is still considerably faster
than
> > DC as it is an optimizing compiler while DC does no optimization.
> >
> > Most libs are supported.
> >
> > We don't have a timeline for support for the other 4k modules, we are
> > looking at it.
> >
> >
> > --
> > ------
> > | Scott G. Henion| shenion@ |
> > | Consultant | Stone Mountain, GA |
> > | SHDesigns http://www.shdesigns.org |
> > ------
> > Rabbit libs: http://www.shdesigns.org/rabbit/
> > today's fortune
> > It is wrong always, everywhere and for everyone to believe
anything upon
> > insufficient evidence.
> > - W. K. Clifford, British philosopher, circa 1876
>

I certainly understand that it is difficult to support hardware that
has little to no documentation (and having wrong documentation is even
worse than none). Case in point being the poor open source guys trying
to reverse engineer proper graphics drivers. It is incredibly slow
going for them, so I understand if there is no support for RCM4xxx in
the near term. Thanks for all the help so far!

-MDiaz-Tello

--- In r..., Scott Henion wrote:
>
> Steve Trigero wrote:
> >
> > While others can give you more details about the Softools IDE, from
> > what I've read, it is full ANSI, faster, and produces much more
> > efficient
> > code. I don't know how their editor is.
>
> And it supports far pointers even back to the R3000, has for years. No
> need for all that xmem2root() calls. So you get the far support on all
> the modules, not just the 4k modules.
>
> The editor is good. The debugger is far better as it doe snot have the
> data size limitations. It also does not use the RST 28's that slow the
> code down by 10-20%. Code runs full speed under the debugger.
>
> >
> > The downside to Softools, so far, is that it seems to take them a
long
> > time
> > to add new Rabbit features to their compiler as they come out.
That they
> > now support the Rabbit 4200 was news to me. That must be very recent,
> > because they have not supported any R4000 products until now. They
> > also don't support some of the DC libraries. I'm sure they will in
time.
> > Maybe they can give you a development time-line if that's
important for
> > you.
> > Adding new 3k modules is trivial, usually just adding the ID to the net
> init code.
>
> The 4k is a royal pain. The documentation is sparse and contains wrong
> information. The 16-bit RAM support has bugs that even the workarounds
> provided by ZW do not work. That has made supporting them near
> impossible without proper documentation.
>
> ST runs the 4200 in 3k mode. The code is still considerably faster than
> DC as it is an optimizing compiler while DC does no optimization.
>
> Most libs are supported.
>
> We don't have a timeline for support for the other 4k modules, we are
> looking at it.
> --
> ------
> | Scott G. Henion| shenion@... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns http://www.shdesigns.org |
> ------
> Rabbit libs: http://www.shdesigns.org/rabbit/
> today's fortune
> It is wrong always, everywhere and for everyone to believe anything upon
> insufficient evidence.
> - W. K. Clifford, British philosopher, circa 1876
>

Steve Trigero wrote:
>
> While others can give you more details about the Softools IDE, from
> what I've read, it is full ANSI, faster, and produces much more
> efficient
> code. I don't know how their editor is.

And it supports far pointers even back to the R3000, has for years. No
need for all that xmem2root() calls. So you get the far support on all
the modules, not just the 4k modules.

The editor is good. The debugger is far better as it doe snot have the
data size limitations. It also does not use the RST 28's that slow the
code down by 10-20%. Code runs full speed under the debugger.

>
> The downside to Softools, so far, is that it seems to take them a long
> time
> to add new Rabbit features to their compiler as they come out. That they
> now support the Rabbit 4200 was news to me. That must be very recent,
> because they have not supported any R4000 products until now. They
> also don't support some of the DC libraries. I'm sure they will in time.
> Maybe they can give you a development time-line if that's important for
> you.
>

Adding new 3k modules is trivial, usually just adding the ID to the net
init code.

The 4k is a royal pain. The documentation is sparse and contains wrong
information. The 16-bit RAM support has bugs that even the workarounds
provided by ZW do not work. That has made supporting them near
impossible without proper documentation.

ST runs the 4200 in 3k mode. The code is still considerably faster than
DC as it is an optimizing compiler while DC does no optimization.

Most libs are supported.

We don't have a timeline for support for the other 4k modules, we are
looking at it.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
It is wrong always, everywhere and for everyone to believe anything upon
insufficient evidence.
- W. K. Clifford, British philosopher, circa 1876

Yeah, I actually sent an email to the address they have on their site
asking about support for Rabbit 4000 processors, but I haven't gotten
a response back from Softools yet. When I do, i'll be sure to make a
post here for the benefit of others. As to the Softools editor, i
didn't use it very long, but from the short time that i did, it seemed
OK, not great, but OK. The feature that i saw that I really liked is
that it supports using an external editor, so I was able to make it
use Vim as my source code editor, which is really nice. The only
downside to using an external editor is that you can't set breakpoints
and debug with it, you will have to ask the IDE to open its native
editor when you are in debug mode, but this is an acceptable
compromise I suppose.

-MDiaz-Tello
--- In r..., Steve Trigero wrote:
>
> As for the IDE, I would agree. I don't do any work with the IDE, I
use a
> separate programming editor. The DC IDE is just too clumsy to be
> productive with. I only open it to compile and download.
>
> Sadly, there isn't a more complete version of DC. It would be nice
> if they could make their compiler, and maybe even the debugger,
> a plugin for existing programming editors, such as SlickEdit or
> CodeWrite. That way they wouldn't have to write their own editor
> (are you listening Z-World?), yet the user would have a world-class
> IDE to work with in one package.
>
> As for the compiler itself, you're right, it's not ANSI, in that it
doesn't
> use a linker, and you can't just compile one file by itself. It has,
what
> appears to me to be a crazy methodology of using "BEGIN HEADER/
> END HEADER" tags for everything. We can throw darts at it all day,
> but it is what it is. It's not the worst thing I ever had to use.
Just annoying.
>
> While others can give you more details about the Softools IDE, from
> what I've read, it is full ANSI, faster, and produces much more
efficient
> code. I don't know how their editor is.
>
> The downside to Softools, so far, is that it seems to take them a
long time
> to add new Rabbit features to their compiler as they come out. That they
> now support the Rabbit 4200 was news to me. That must be very recent,
> because they have not supported any R4000 products until now. They
> also don't support some of the DC libraries. I'm sure they will in time.
> Maybe they can give you a development time-line if that's important for
> you.
>
> Steve
>
> ----- Original Message ----
> From: mdiaz.tello
> To: r...
> Sent: Thursday, September 11, 2008 9:48:16 AM
> Subject: [rabbit-semi] Re: Softools on Rabbit 4000 (RCM4300)
> Dynamic C just feels underdeveloped compared to other IDEs that I have
> used for other embedded microprocessors such as CodeWarrior. After
> using Dynamic C for about a week and a half, I was beginning to wonder
> if the version of the software that came with the RCM4300 development
> kit was some sort of stripped down version to get you to buy a more
> complete version of the compiler. The company I am working for would
> be fine with purchasing a more complete version of Dynamic C if this
> is the case. The other thing is that Dynamic C is rather quirky and is
> not standard C. Of course, if we can't find a viable ANSI C compiler
> for our board, we will just have to use Dynamic C.
>
> -MDiaz-Tello
>
> --- In rabbit-semi@ yahoogroups. com, Steve Trigero ...> wrote:
> >
> > I don't believe there is another compiler for the Rabbit.
> >
> > What specifically was it about Dynamic C that made it
> > unusable for you? I've only used DC 10.xx on a few
> > sample programs, so I don't have much experience with
> > it. All my work as been with with the R3000 and below.
> >
> >
> >
> > ----- Original Message ----
> > From: mdiaz.tello
> > To: rabbit-semi@ yahoogroups. com
> > Sent: Thursday, September 11, 2008 6:24:37 AM
> > Subject: [rabbit-semi] Re: Softools on Rabbit 4000 (RCM4300)
> >
> >
> > That is a shame. I do appreciate the prompt response I got, though.
> > Thanks!
> >
> > Softools was the first 3rd party compiler for Rabbit that I found
> > after a bit of searching; does anyone know if there are other viable
> > alternatives to Dynamic C that have Rabbit 4000 (RCM4300) support?
> >
> > Thank you.
> >
> > -MDiaz-Tello
>