> We found a similar problem in moving between versions, and spent a
day with the zworld guys with no positive results. The next day, we
opened up the project file (__.dcp) and found a couple paths that
need to be changed.
This isn't unique to 9.21, it applies to previous version changes as
well. You need to open this file with some dumb text editor, and
revise the paths. We shouldn't need to do this, but we must. This
gets to be a major pain if there are two guys with different DC
versions!
Reply by Bruce Isted●May 23, 20052005-05-23
I'm sorry that you had trouble with this also. We are looking at
ways to make migration of project files less troublesome, but have not
come to any conclusions yet. It is obviously not possible to
anticipate every problem and resolve it automatically, but I believe that
we should try to make potential trouble spots easier to identify.
On the other hand, it may be that supporting migration of project files
across compiler releases is just more trouble than it's worth, and DC
just needs to recognize and reject the old DCP file.
At 04:28 PM 5/22/2005, you wrote:
Bruce,
In regards to the migration of project files between DC versions, we
recently discovered the hard way that they are not compatible when moving
from 8.61 to 9.10.
DC was whinging about a coldloader issue, and after wasting some time
discovered that the project file was originally created in 8.61 (and the
coldloader and pilot paths were pointing to the 8.61 directory which was
not installed on this particular PC). What was annoying is that:
a)
The coldloader and pilot
information is not present to the user in the project settings screen
(both PCs had identical settings) so the problem was only discovered
once the project file was opened in a text editor.
b)
There was no warning
message about project file version mismatches.
I can understand that project files could be incompatible between DC
versions, but you seem to suggest its not necessarily a bad thing to
migrate a project file?
Regards,
Nathan
-----Original Message----- From: r...@yahoogroups.com
[mailto:r...@yahoogroups.com]
On Behalf Of Bruce Isted Sent: Friday, 20 May 2005 8:35 AM To: r...@yahoogroups.com Subject: Re: [rabbit-semi] Errors in DC9.21
Sorry for the
inconvenience, we have just recently identified this annoying
problem and found a work
around.
If you're carrying forward a Dynamic C project (DCP) file from
DC 8.51 to 9.21, you will encounter problems due to a change in the pilot
BIOS that is necessary to support the PowerCore FLEX's version 5 ID
block.
This problem can be resolved by making a copy of your project
file (maybe append "921" at the end of the file name) and then
editing (with Dynamic C
closed) the pathlists for the coldload.bin and pilot.bin files
to suit your DC 9.21
installation.
-
Bruce
At 09:58 AM 5/19/2005, you
wrote: >I come from DC 8.51 and trying DC
9.21. > >I get that errors when i try to compile to flash or trying
to resest the >board. > >line 1 : WARNING
ERROR : No parameters found for
flash id >received from pilot bios - using default
parameters. >line 33 : WARNING BOARDTYPES.LIB :
No ID Block found on the
target; >defining _BOARD_TYPE_ to be a
BL1810. > >I see in the downlaod dialog a bad id for my
boards: > >RCM2100 : Board
0x0314 >RCM2110 : Board
0x0414 > >The same boards work excelent with DC 8.51 , same machine,
all the same >except DC version. I switch from one version to another
and stop working. >Im using a USB to serial adapter from Keyspan (19W) and
ever work >excellent at 4xx
KBPS. >Any
idea? > >German. > > > >Yahoo! Groups
Links > > > >
Yahoo! Groups Links
To
Reply by Nathan Johnston●May 22, 20052005-05-22
Bruce,
In regards to the migration of project
files between DC versions, we recently discovered the hard way that they are
not compatible when moving from 8.61 to 9.10.
DC was whinging about a coldloader issue, and after wasting some time discovered
that the project file was originally created in 8.61 (and the coldloader and pilot paths were pointing to the 8.61
directory which was not installed on this particular PC). What was annoying is
that:
a)The
coldloader and pilot information is not
present to the user in the project settings screen (both PC’s had
“identical”
settings) so the problem was only discovered once the project file was opened
in a text editor.
b)There
was no warning message about project file version
mismatches.
I can understand that project files could
be incompatible between DC versions, but you seem to suggest it’s not
necessarily a bad thing to migrate a project file?
Regards,
Nathan
-----Original
Message----- From: r...@yahoogroups.com
[mailto:r...@yahoogroups.com] On
Behalf Of Bruce Isted Sent: Friday, 20 May 2005 8:35
AM To: r...@yahoogroups.com Subject: Re: [rabbit-semi] Errors
in DC9.21
Sorry for the inconvenience,
we have just recently identified this annoying problem and found a work around.
If you're carrying forward a Dynamic C project
(DCP) file from DC 8.51 to 9.21, you will encounter problems due to a change
in the pilot BIOS that is necessary to support the PowerCore FLEX's
version
5 ID block.
This problem can be resolved by making a copy of
your project file (maybe append "921" at the end of the file
name) and then editing (with Dynamic C closed) the pathlists for the coldload.bin and
pilot.bin files to suit your DC 9.21 installation.
- Bruce
At 09:58 AM 5/19/2005, you wrote: >I come from DC 8.51 and trying DC
9.21. > >I get that errors when i try to compile to
flash or trying to resest the >board. > >line 1 : WARNING
ERROR : No parameters found for flash
id >received from pilot bios - using default
parameters. >line 33 : WARNING
BOARDTYPES.LIB : No ID Block found on the target; >defining _BOARD_TYPE_ to be a
BL1810. > >I see in the downlaod dialog a bad id for my
boards: > >RCM2100 : Board 0x0314 >RCM2110 : Board 0x0414 > >The same boards work excelent with DC 8.51 ,
same machine, all the same >except DC version. I switch from one version
to another and stop working. >Im using a USB to serial adapter from Keyspan
(19W) and ever work >excellent at 4xx KBPS. >Any idea? > >German. > > > >Yahoo! Groups Links > > > >
Reply by German Gentile●May 22, 20052005-05-22
Scott Henion escribi
>[snip]
>The V5 ID block still looks like a bad idea. There is a lot of code added
>to the bioslib _even for boards that will never use a V5 ID block_.
> You mind theres not condiyional compiler directives in the bios to
eliminate that code? Any code compiled with V 9.21 will have that code ,
thas i never will use?
That explain the more than 10k diff in the code, from version 8.5 to
9.21. :(
German .
Reply by Scott Henion●May 21, 20052005-05-21
At 12:29 PM 5/20/2005, you wrote:
>To the best of my knowledge, currently the only
Z-World / Rabbit
>Semiconductor board shipped with a version 5 ID block is the
>PowerCore FLEX. How are you finding that DC 9.21 is creating a
>version 5 ID block? What program(s) are you running when this
>happens?
I'm not running anything. Just users reported problems on RCM3200/3700
until I added V5 user block support.
>Again, no RCM33xx or RCM37xx, or any board other
than the PowerCore
>FLEX should have a V. 5 ID block on it. Do you know how this is
>happening?
No. I don't see anything in the libs that does it.
>Z-World's Tech Support (or I) can supply an
updated (ugly) version
>of the write_idblock.c utility that will write a version 5 ID block,
>given that it is compiled using DC 9.2x. You could probably port it
>to Softools quite easily, although you'd also need to port at least
>IDBLOCK.LIB and FLASHWR.LIB along with it.
I already can read a V5 user block, Softools does it also. If i need to
force a V5 ID block I'll write a Softools utility as it would be
simpler.
> >
> > BTW, I consider tha V5 ID block a bad idea. It is set up to be
>rewritten
> > according to compile settings. I consider the ID block should be
>left
> > alone. I have had users report it getting corrupted when using 9.x.
> >
>
>No version of the ID block should be rewritten, except in rare
>instances. For example, where an application requires a different
>User block size, or similar reason. What do you mean when you say
>that compile settings are responsible for rewriting the V. 5 ID
>block?
It looks by the code that #defines are being migrated to the new ID block.
Looking closer I see there is no way to add a macro to the ID block.
>In the past, we have changed the version of ID
block that is factory
>installed on a particular product, and found it to be a mistake. We
>try very hard not to repeat this mistake. Are you seeing that it
>has re-occurred on ZW / RS "factory-fresh" boards?
The V5 ID block still looks like a bad idea. There is a lot of code added
to the bioslib _even for boards that will never use a V5 ID block_.
uint32 macrosLoc; // Start of the macro table for additional board
// configuration options.
uint32 driversLoc; // offset to preloaded drivers start from ID block
// start (positive is below ID block)
uint32 ioDescLoc; // offset to I/O descriptions start from ID block
// start (positive is below ID block)
uint32 ioPermLoc; // offset to User mode I/O permissions start from ID
// block start (positive is below ID block)
Here's pointers to flash data stored outside the ID/User block? This makes
every 3rd party have to follow ZW's whims on what is stored there. I would
think even ZW's DLM would overwrite it as it is now.
This type of stuff has caused me to increase the cost of my libs (ST
unchanged.) I know Softools is wasting a lot of time keeping up with this
stuff. I bet Rudy is getting annoyed with these arbitrary changes.
So the powerflex can have one of two NICs. Why not have the info in the
board ID. Then it can be compiled for that board type without all the extra
code for the other device and wasted code to check for different ID blocks.
I would not want ZW to be able to change the NIC from asix to SMSC and
still keep the same board model #. If you have to order a different part #
to use the other NIC, it should use a different board ID to identify it.
Otherwise, any targetless compile to .bin would need to include code for
all possible configurations. Again a waste of code.
BTW, why is the powerflex 1 wait state? Seems silly to run ~50mhz then slow
it down to an effective speed of 37mHz by adding 1ws even when running in
fast RAM. The only advantage seems to be more flexibility with baud rates
and 1meg Flash (although I see no support for using it in DC. ST has
support coming in the next release ;) .)
<Scott>
------
| Scott G. Henion| shenion@shen... |
| Consultant | Stone Mountain, GA |
| SHDesigns | PGP Key 0xE98DDC48 |
| http://www.shdesigns.org |
------
today's fortune
Data, n.:
Computerspeak for "information". Properly pronounced
the way Bostonians pronounce the word for a female child.
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 5/20/2005
Reply by sser2k●May 20, 20052005-05-20
Please see my answers / comments / questions interspersed in the
quoted email below.
- Bruce
--- In rabbit-semi@rabb..., Scott Henion <shenion@s...>
wrote: > At 07:22 PM 5/19/2005, you wrote:
>
> >Dynamic C 9.20 is the first release that "knows" about
version 5 ID blocks, > >and the version 5 ID block is only
factory-installed on Z-World's PowerCore > >FLEX boards so far. Previous versions of the
ID block are still fully > >supported by DC 9.2x.
> >
> >What issues are you seeing that make you think DC 9.2x somehow expects the > >version 5 ID block?
>
> I did not say it expects it, I said it creates one.
To the best of my knowledge, currently the only Z-World / Rabbit
Semiconductor board shipped with a version 5 ID block is the
PowerCore FLEX. How are you finding that DC 9.21 is creating a
version 5 ID block? What program(s) are you running when this
happens?
>
> > Do you have PowerCore FLEX boards with corrupted
> >version 5 ID blocks that need to be recovered or re-written? If so, > >Z-World Tech Support (or I) can supply a
version of the write_idblock.c > >utility that will write a suitable version 5
ID block. If this is the > >case, how did the ID block corruption occur,
and is it reproducible? >
> I don't have the powerflex board (although I was told I'd get
one.)
Please check on this again with Sales or Tech Support or whoever you
spoke with before.
>
> It is not just corruption. My DLM is written in Softools so it needs to > convert the ID block to ST format (in RAM so it
knows how to skip the > user/id block areas.) Users reported problems with
8.x. This seems to be a > change in how the User block is handled. Before
there was 2 user blocks > that share one ID block (v3). The new mirrored
scheme makes 2 ID blocks, > one is marked invalid (v4?). The code was changed
to search for the ID > block. Its fixed the problems.
The V. 2 ID block has a single (non-mirrored) User block that it is
combined with. By "combined" I mean that the ID block and the User
block (if present) may share a flash sector.
The V. 3 and 4 ID blocks are very similar to each other, differing
only in the number of their elements actually populated with data.
No ZW / RS production board was ever shipped with a V. 3 ID block,
AFAIK. The V. 3 and 4 ID block is also combined with the User
block, and both are mirrored for robustness.
The V. 5 ID block on the PowerCore FLEX has additional information
in and around it, but is also a combined + mirrored type similar to
the V. 3 and 4 ID blocks.
>
> Then users reported additional problems on 3700/3300 boards when using DC > 9.x. It was found that the ID block format has
suddenly changed. I added > decoding of the V5 ID block and that fixed the
problems.
Again, no RCM33xx or RCM37xx, or any board other than the PowerCore
FLEX should have a V. 5 ID block on it. Do you know how this is
happening?
>
> >If it is the previously mentioned pilot BIOS issue that you ask about, then > >the problem is that the old pilot BIOS
doesn't deliver the exact
> >information that the new DC 9.2x versions expect / require. This problem > >shows up when an older pilot.bin file is used
by the new DC 9.2x, as will > >happen when a older DCP file is migrated to
the new DC 9.2x version. >
> I was talking about a .c file with no project. I have seen garbage code, > TCP/IP stack bugs, DHCP issues, and the code size
was too big for projects > that used to easily fit in flash. After trying
several .c files and seeing > different bugs in the code generated, I gave up. I
do little work in DC, I > use 7.33 as it is stable and supports all the
modules (with a little rework.) >
> I would like a utility to generate a V5 ID block, although I could write > one. Might be useful for testing.
Z-World's Tech Support (or I) can supply an updated (ugly) version
of the write_idblock.c utility that will write a version 5 ID block,
given that it is compiled using DC 9.2x. You could probably port it
to Softools quite easily, although you'd also need to port at least
IDBLOCK.LIB and FLASHWR.LIB along with it.
>
> BTW, I consider tha V5 ID block a bad idea. It is set up to be rewritten > according to compile settings. I consider the ID
block should be left > alone. I have had users report it getting
corrupted when using 9.x.
>
No version of the ID block should be rewritten, except in rare
instances. For example, where an application requires a different
User block size, or similar reason. What do you mean when you say
that compile settings are responsible for rewriting the V. 5 ID
block?
In the past, we have changed the version of ID block that is factory
installed on a particular product, and found it to be a mistake. We
try very hard not to repeat this mistake. Are you seeing that it
has re-occurred on ZW / RS "factory-fresh" boards?
> <Scott>
>
> ------------
> | Scott G. Henion | shenion@s... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns | PGP Key 0xE98DDC48 |
> |Rabbit Libs: http://www.shdesigns.org/rabbit/ |
> ------------
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.12 - Release Date: 5/17/2005
Reply by mlinder●May 20, 20052005-05-20
Robert,
You are correct I was using DC9.10 and pointer checking was on.
I normally have these turned off, since I compile mostly to .bin.
using projects.
I Checked Code again in DC9.10 with all debug off, MUCH BETTER.
Alot better than I thought. I just dont trust most of the debug
stuff, I've had weird things happen with tracing and some of the
other new stuff turned on.
--- In rabbit-semi@rabb..., Larry Kilmer <lkkilmer@y...>
wrote: > Not defending DC cause the Rabbit code is UGLY but
it seems the Rabbit compilers were producing code with debug turned on and the
Z180 maybe didn't. Possibly how default settings for the compilers
are set. Interesting test anyway. > If this reply shows up twice, sorry...Having technical issues lately.
The reason for such ugly code is because of pointer and array
checking. Since you are assigning to a pointer, it wants to make
certain that pointer is a legitimate pointer.
I don't know if Softools provides run-time checking of arrays; if so,
it probably puts in some not-so-clean code, too.
I never purchased DC32, but I do have the 16-bit Z180 Dynamic C and
still program a few products that I haven't retrofitted to Rabbit
products. I assume DC32 also has the ability to do array and bounds
checking.
Here is the Z-180 code created with its array and bounds checking on:
Not defending DC cause the Rabbit code is UGLY but it seems the Rabbit
compilers were producing code with debug turned on and the Z180 maybe
didn't. Possibly how default settings for the compilers are
set. Interesting test anyway.
LK
mlinder <m...@micro-controls.com>
wrote:
Since
it's beat on DC week...
Run this code an look at the asm code
for the two lines marked. This clearly shows that DC32 was better than
DCRabbit. Softtools also creates very small code for the lines in
question.
At the bottom it shows the asm code for several zworld
compilers. So on DC anyone using pointers gets a nice sized penalty in
code size and speed. #memmap xmem
typedef struct _TEST { unsigned uVar1; unsigned uVar2; unsigned uVar3; } TEST;int
main(void) { static TEST Clean; static TEST *pClean;
pClean = &Clean;
//LOOK AT THE
ASM CODE FOR THESE TWO LINES Clean.uVar1 = 1; pClean->uVar1 = 1; }/** ****************************** * Z180 Dynamic C 32 ******************************
Clean.uVar1 = 1; ff:e00f 210100 ld hl,0001 ff:e012 22E3D9 ld (D9E3),hl
Run this code an look at the asm code for the two lines marked.
This clearly shows that DC32 was better than DCRabbit.
Softtools also creates very small code for the lines in question.
At the bottom it shows the asm code for several zworld compilers.
So on DC anyone using pointers gets a nice sized penalty
in code size and speed.
#memmap xmem
typedef struct _TEST
{
unsigned uVar1;
unsigned uVar2;
unsigned uVar3;
} TEST;
int main(void)
{
static TEST Clean;
static TEST *pClean;
pClean = &Clean;
//LOOK AT THE ASM CODE FOR THESE TWO LINES
Clean.uVar1 = 1;
pClean->uVar1 = 1;
}
/**
******************************
* Z180 Dynamic C 32
******************************
Clean.uVar1 = 1;
ff:e00f 210100 ld hl,0001
ff:e012 22E3D9 ld (D9E3),hl