>> DONT look for incorrect code !
>> write correct code .
>> It should have occurred to you the
>
><snip>
>
>etc. etc.
>Is it me??
No, it's him - like one of those Japanese soldiers holed up on an
island, still waiting for orders long after the war was lost.
Mike
Reply by CBFalconer●February 15, 20082008-02-15
Dave wrote:
> "werty" <werty@swissinfo.org> wrote in message
>>
>> DONT look for incorrect code !
>> write correct code .
>> It should have occurred to you the
>
> <snip>
>
> etc. etc. Is it me??
Yes. You failed to PLONK werty.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Reply by Dave●February 15, 20082008-02-15
"werty" <werty@swissinfo.org> wrote in message
news:ca335791-2913-42aa-90e8-c2655e0128fb@u10g2000prn.googlegroups.com...
>
> DONT look for incorrect code !
>
>
> write correct code .
>
>
> It should have occurred to you the
<snip>
etc. etc.
Is it me??
Dave.
Reply by werty●February 15, 20082008-02-15
DONT look for incorrect code !
write correct code .
It should have occurred to you the
s/w you bought could never create
good bug free code !
The authors had no intention to sell
you a better way to generate code !
There is only one way to write good
code , write it all , yourself .
You begin by sending serial ( rs232 or SPI)
strings to ARM , running them .
The ones that dont crash and light up the
red , green , and blue LEDs in the right
order are your "tutorial" .
Learn to create code that assembles
and stores short Forth primatives in a
dictionary , so you can use these primatives
to help you create higher level sequences
of code .
Chuck Moore did this in the 70's , in Tucson
to put many programmers out of a job .
He created Forth ( the simplist method to
program).
You will save many months of "learning" curve
by not reading thick s/w manuals , you can
charcterize the ARM yourself , with Forth , in
minutes , and save the results to the Forth
dictionary , to aide others .
There is no future , for M$ , C , Linux ,
and the PC ...
why not study modern techniques and
burn your s/w "Books" ?
All critical s/w is written
NOT using C , and
NOT using available assemblers
Not using Linux ,
Not using Intel , AMD cpu's
...........
More than 2.5 billion A.R.M cpu's
on this earth , the Thumb-2 instruction
set is used more than the 32 bit instructions
cause its faster !
The ST electronics company makes
ST-710-FZ2 ARM 7 , has 144 pins
6 mhz I/O ,
internal 65 K SRAM and huge flash .
It will be configured with 32MB PSRAM .
and a non-prop USB 480 mb/s serial
port ( "Hi-Speed... Run Length Limited h/w).
PC is dead ,
ARM-BC ( business computer follows)
KC7CC
Reply by David Brown●February 14, 20082008-02-14
chrisdekoh@gmail.com wrote:
> Hi,
>
> 1) Does a microprocessor in debug mode run on a slower clock? I din
> know that
Sometimes cpus will run slower when you are using a debugger (for
example, the debugger might have tracing features that require the cpu's
cache to be disabled, or it might "simplify" the processor in other
ways). However, I think what Alex meant was that the debug compile
flags will generate slower code than when you pick flags for more
optimisation. When using debug flags, the compiler will try to keep the
structure of your program intact (such as its loops and functions), to
make it easier to follow with a debugger. When doing full optimisation,
the compiler will do more inlining and loop unrolling if that makes the
code smaller and/or faster.
> 2) under what circumstances should what variables be volatile?
>
A variable should be "volatile" to indicate that its value might be read
or changed without the compiler knowing about it (including being
accessed from another C function if the compiler does not know that it
may also run at any time, such as an interrupt function or a separate
thread).
mvh.,
David
> Chris
>
>
> On Feb 14, 5:58 am, Alex Freed <al...@mirrow.com> wrote:
>> GMM50 wrote:
>>> Hi All:
>>> This may indeed be a problem but how does debug make it all work.
>>> george
>> In my experience the most common scenario is a lack of "volatile"
>> keyword. Debug version turns optimization off and release version
>> optimizes a read of a hardware register out, 'cause it doesn't know it
>> is hardware and nothing in the code changes it's value.
>>
>> The second possibility is a race condition. Dubug version may execute
>> more slowly.
>>
>> -Alex.
>
Reply by ●February 13, 20082008-02-13
Hi,
1) Does a microprocessor in debug mode run on a slower clock? I din
know that
2) under what circumstances should what variables be volatile?
Chris
On Feb 14, 5:58=A0am, Alex Freed <al...@mirrow.com> wrote:
> GMM50 wrote:
> > Hi All:
>
> > This may indeed be a problem but how does debug make it all work.
>
> > george
>
> In my experience the most common scenario is a lack of "volatile"
> keyword. Debug version turns optimization off and release version
> optimizes a read of a hardware register out, 'cause it doesn't know it
> is hardware and nothing in the code changes it's value.
>
> The second possibility is a race condition. Dubug version may execute
> more slowly.
>
> -Alex.
Reply by Alex Freed●February 13, 20082008-02-13
GMM50 wrote:
> Hi All:
>
> This may indeed be a problem but how does debug make it all work.
>
> george
In my experience the most common scenario is a lack of "volatile"
keyword. Debug version turns optimization off and release version
optimizes a read of a hardware register out, 'cause it doesn't know it
is hardware and nothing in the code changes it's value.
The second possibility is a race condition. Dubug version may execute
more slowly.
-Alex.
Reply by GMM50●February 13, 20082008-02-13
On Feb 12, 5:33 pm, chrisde...@gmail.com wrote:
> Hi Dave,
>
> my mistake. Here is what i intended it to be.
>
> to paraphrase:
> #1: RTS(PC) -> CTS(FPGA) 0 = PC has no data to send to FPGA. If PC
> sends data without asserting its RTS,
> UART will not shift
> in the inputs.
> 1= PC should assert this
> if it has data to send. only then can FPGA can receive data
> from PC
>
> #2: RTS(FPGA) -> CTS(PC) 0 = receive buffer on UART attached to
> microblaze is full. During this time, PC should
> no longer transmit
> to FPGA. once receive buffer has been cleared, FPGA will set
> the RTS line again.
> 1 = PC can transmit to
> FPGA as the UART receive buffer is not full.
>
> did you spot any mistake? Is there a need for FPGA to use DSR?
>
> Chris
>
> On Feb 12, 11:47 pm, Dave Pollum <vze24...@verizon.net> wrote:
>
> > On Feb 11, 10:55 am, chrisde...@gmail.com wrote:
> > <snip>
> > 1) rts on PC side will drive FPGA cts pin. If rts on PC side = 1, then
> > transmission from FPGA to PC will be possible. otherwise, the FPGA
> > cannot transmit anything back to PC.
> > 2) cts on PC side is driven by FPGA rts pin. FPGA rts pin = 1 once the
> > receiver buffer in UART peripheral attached to microblaze is full.
> > this will disable PC from sending any more data to microblaze on the
> > FPGA.
> > <snip>
>
> > to paraphrase:
> > #1: RTS(PC) -> CTS(FPGA) 1 = FPGA transmits to PC
> > #2: RTS(FPGA) -> CTS(PC) 1 = PC _does not_ transmit to FPGA
>
> > Is this really what happens, or did you mistype?
> > -Dave Pollum
Hi All:
This may indeed be a problem but how does debug make it all work.
george
Reply by ●February 12, 20082008-02-12
Hi Dave,
my mistake. Here is what i intended it to be.
to paraphrase:
#1: RTS(PC) -> CTS(FPGA) 0 =3D PC has no data to send to FPGA. If PC
sends data without asserting its RTS,
UART will not shift
in the inputs.
1=3D PC should assert this
if it has data to send. only then can FPGA can receive data
from PC
#2: RTS(FPGA) -> CTS(PC) 0 =3D receive buffer on UART attached to
microblaze is full. During this time, PC should
no longer transmit
to FPGA. once receive buffer has been cleared, FPGA will set
the RTS line again.
1 =3D PC can transmit to
FPGA as the UART receive buffer is not full.
did you spot any mistake? Is there a need for FPGA to use DSR?
Chris
On Feb 12, 11:47=A0pm, Dave Pollum <vze24...@verizon.net> wrote:
> On Feb 11, 10:55 am, chrisde...@gmail.com wrote:
> <snip>
> 1) rts on PC side will drive FPGA cts pin. If rts on PC side =3D 1, then
> transmission =A0from FPGA to PC will be possible. otherwise, the FPGA
> cannot transmit anything back to PC.
> 2) cts on PC side is driven by FPGA rts pin. FPGA rts pin =3D 1 once the
> receiver buffer in UART peripheral attached to microblaze is full.
> this will disable PC from sending any more data to microblaze on the
> FPGA.
> <snip>
>
> to paraphrase:
> #1: RTS(PC) =A0 -> CTS(FPGA) =A01 =3D FPGA transmits to PC
> #2: RTS(FPGA) -> CTS(PC) =A0 =A01 =3D PC _does not_ transmit to FPGA
>
> Is this really what happens, or did you mistype?
> -Dave Pollum
Reply by Dave Pollum●February 12, 20082008-02-12
On Feb 11, 10:55 am, chrisde...@gmail.com wrote:
<snip>
1) rts on PC side will drive FPGA cts pin. If rts on PC side = 1, then
transmission from FPGA to PC will be possible. otherwise, the FPGA
cannot transmit anything back to PC.
2) cts on PC side is driven by FPGA rts pin. FPGA rts pin = 1 once the
receiver buffer in UART peripheral attached to microblaze is full.
this will disable PC from sending any more data to microblaze on the
FPGA.
<snip>
to paraphrase:
#1: RTS(PC) -> CTS(FPGA) 1 = FPGA transmits to PC
#2: RTS(FPGA) -> CTS(PC) 1 = PC _does not_ transmit to FPGA
Is this really what happens, or did you mistype?
-Dave Pollum