On Tuesday 08 December 2009, David Brownell wrote:
From Section B.7 Determining the core and system state of ARM9E-S
Core Technical Reference Manual (DDI0240A.pdf):
| Note
|
| Because all Thumb instructions are only 16 bits long,
Maybe back then they were! [ ... ]
|
Hi everyone,
Flamewar protection on
I just glance at the mailing list chatter, so please excuse if my
suggestion/comment is completely off the wall/misinformed/completely wrong and
please ignore it if that's the case.
I get the impression that you (the developers) are butting your head
Hi Pieter,
On 12/9/09, Pieter Conradie pieter.conra...@psitek.com wrote:
Hi everyone,
Flamewar protection on
I just glance at the mailing list chatter, so please excuse if my
suggestion/comment is completely off the wall/misinformed/completely wrong
and please ignore it if that's the case.
Please search on mailing list archive, people already lost too much
time discussion about it.
I second this. There was a nice discussion about how the developers of
OpenOCD tend to be more comfortable in C because of the embedded work they
do. In addition, OpenOCD is built to run on some
On Wed, 9 Dec 2009, Pieter Conradie wrote:
I get the impression that you (the developers) are butting your head
against the limitations of C.
What limitations?
I never considered the C language to bare any limitations what so ever.
You can do much more in C, and with way more control and
Nicolas Pitre pisze:
What limitations?
I never considered the C language to bare any limitations what so ever.
You can do much more in C, and with way more control and performance,
than with most other languages. The inconvenient is that C requires
better programming skills.
And C
Freddie Chopin a écrit :
The overhead of C++ is also doubtful - when you know how to do it
the overhead will be 0. BTW you also need to know how to do it to
write C++-in-C, so...
... and this overhead is 0 when you know how to do it, isn't it? :)
More seriously: I don't favor C over C++ or
This discussion comes up every so often. I don't see
that anything has changed.
There hasn't been any interest from the maintainers to switch and
it would be a major undertaking to do this. Getting the consensus
and convincing everybody to come on board would be a huge
undertaking in itself. You
On Wed, 9 Dec 2009, Freddie Chopin wrote:
Nicolas Pitre pisze:
What limitations?
I never considered the C language to bare any limitations what so ever.
You can do much more in C, and with way more control and performance,
than with most other languages. The inconvenient is that C
On Wednesday 09 December 2009, Freddie Chopin wrote:
And C is amenable to object oriented programming just fine.
Now replace C with assembler - this will still be perfectly true,
but are there any sane ppl who write software for PC in assembly?
To state the obvious: OpenOCD can run on
This commit adds in src/target/embeddedice.c a plain
LOG_INFO(%s: hardware has 2 breakpoints or watchpoints, ...
This is wrong for Feroceon and Dragonite which have only one of them.
In that case arm7_9-wp_available_max is initialized to 1 in the
target_create method, but the above
On Wednesday 09 December 2009, Nicolas Pitre wrote:
This is wrong for Feroceon and Dragonite which have only one of them.
In that case arm7_9-wp_available_max is initialized to 1 in the
target_create method, but the above message is still wrong and
misleading.
OK, got patch? :)
I guess
On Wednesday 09 December 2009, David Brownell wrote:
On Wednesday 09 December 2009, Nicolas Pitre wrote:
This is wrong for Feroceon and Dragonite which have only one of them.
In that case arm7_9-wp_available_max is initialized to 1 in the
target_create method, but the above message is
On Wed, 9 Dec 2009, David Brownell wrote:
On Wednesday 09 December 2009, Nicolas Pitre wrote:
This is wrong for Feroceon and Dragonite which have only one of them.
In that case arm7_9-wp_available_max is initialized to 1 in the
target_create method, but the above message is still wrong
Freddie Chopin a écrit :
Why everyone sees only the bad sides of C++ and completely forgets the
good ones? Templates? Stronger compilation-time-error-checks? Easier
error handling? Easier abstraction? Easier polymorphism? Easier - well -
everything?
I will never use C++ in my embedded
Bugfix the read side of flash protection:
- read the right register(s)!
- handle more than 64K
- record the results in the right places
- don't display garbage.
Partially bugfix the write side:
- use 2KB lock regions instead of 1KB pages (!)
- validate input range
- don't try to _remove_
Hi all,
please welcome Nicolas Pitre as a maintainer!
Besides having git access, I don't expect much to change. He
has provided first class advice and patches in the past and
we hope that he'll continue to do so!
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
17 matches
Mail list logo
