4 Sep
2012
4 Sep
'12
9:07 a.m.
Joachim writes:
> The R? has gotten a mixed reception 'round here
Al writes:
The problem I see with the Cambridge examples is
students don't LEARN anything
about what they're programming on. They're given a bunch of magic recipes and
don't learn what they're for. What you end up with is what you
could have done with 10 lines of Z80 assembly talking to a terminal through a
UART, but in the example you have to make your own terminal, talking to a big
blob of USB stack and graphics coprocessor glue.
It's ironic that it seems increasingly hard to do anything "bare metal"
without a graphical UI IDE on a desktop and a USB stack on the "bare metal".
I ran across this (probably inadvertent, possibly sly, but still funny and relevant) quote
on Wikipedia:
"By the late 1960s change was coming: as operating systems and programming
language compilers evolved, software production costs were dramatically increasing."
4 Sep
4 Sep
10:54 a.m.
On 9/4/12 6:07 AM, Shoppa, Tim wrote:
It's ironic that it seems increasingly hard to do
anything "bare metal" without a graphical UI IDE on a desktop and a USB stack on
the "bare metal".
That is true if you start out with a SOC that never was intended for embedded systems use,
like this part was.
All of the I/O is just... wrong.
If you want to be doing bare metal development, you should be using something like this
http://www.ebay.com/itm/150839172147
It's small, it's 'slow' but the I/O on it is actually USEFUL for building
stuff.
11:45 p.m.
On 09/04/2012 10:54 AM, Al Kossow wrote:
"Slow" is not a word I'd use to describe a Cortex-M3 core at 80MHz.
Remember "bare metal" here...no lumbering pig kernels like Linux or even
NetBSD involved.
One of my latest designs for work is an ARM7 (not Cortex) running a
multitasking RTOS that's up to eight fairly busy tasks now. I've
clocked it down to 48MHz because that's all it needs, and I need to keep
the whole board down below about 140mA because it's going into a
customer's existing, fairly limited machine.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
It's
ironic that it seems increasingly hard to do anything "bare
metal" without a graphical UI IDE on a desktop and a USB stack on the
"bare metal".
That is true if you start out with a SOC that never was intended for
embedded systems use, like this part was.
All of the I/O is just... wrong.
If you want to be doing bare metal development, you should be using
something like this
http://www.ebay.com/itm/150839172147
It's small, it's 'slow' but the I/O on it is actually USEFUL for
building stuff. 
5 Sep
5 Sep
12:10 a.m.
On Sep 4, 2012, at 11:45 PM, Dave McGuire wrote:
On 09/04/2012 10:54 AM, Al Kossow wrote:
"Slow" is not a word I'd use to describe a Cortex-M3 core at 80MHz.
Remember "bare metal" here...no lumbering pig kernels like Linux or even NetBSD
involved.
Right. And at 92K of RAM and 256K program memory, many PDP-11 operating
systems would fit reasonably well and run a hell of a lot faster
(assuming the feasibility of a port, which is next to nil).
- Dave
It's
ironic that it seems increasingly hard to do anything "bare
metal" without a graphical UI IDE on a desktop and a USB stack on the
"bare metal".
That is true if you start out with a SOC that never was intended for
embedded systems use, like this part was.
All of the I/O is just... wrong.
If you want to be doing bare metal development, you should be using
something like this
http://www.ebay.com/itm/150839172147
It's small, it's 'slow' but the I/O on it is actually USEFUL for
building stuff.
12:19 a.m.
On 09/05/2012 12:10 AM, David Riley wrote:
"Slow" is not a word I'd use to describe a Cortex-M3 core at 80MHz.
Remember "bare metal" here...no lumbering pig kernels like Linux or
even NetBSD involved.
Right. And at 92K of RAM and 256K program memory, many PDP-11
operating systems would fit reasonably well and run a hell of a lot
faster (assuming the feasibility of a port, which is next to nil).
Hmm. How much of a POSIX layer is required by simh? ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
It's
ironic that it seems increasingly hard to do anything
"bare metal" without a graphical UI IDE on a desktop and a USB
stack on the "bare metal".
That is true if you start out with a SOC that never was intended
for embedded systems use, like this part was. All of the I/O is
just... wrong.
If you want to be doing bare metal development, you should be
using something like this http://www.ebay.com/itm/150839172147
It's small, it's 'slow' but the I/O on it is actually USEFUL for
building stuff.
4 Sep
4 Sep
2:28 p.m.
On 09/04/2012 09:07 AM, Shoppa, Tim wrote:
It's ironic that it seems increasingly hard to do
anything "bare
metal" without a graphical UI IDE on a desktop and a USB stack on the
"bare metal".
I strongly disagree. You're looking in the wrong places. Boards like
the Raspberry Pi are just not designed for that sort of thing. There
are a great many other boards, however, that are.
Personally I do a lot of ARM development, designing custom boards and
writing the firmware. I do ALL of my systems bare metal. When I'm
starting to work with a different ARM chip, I get a development board
for that chip first, usually one of the Olimex boards, and start porting
my "standard toolbox" of stuff to that...getting UART drivers working,
interrupt handlers, etc, all on known-working hardware. Then I start
working on my custom board.
All bare metal. RPi just wasn't designed for that sort of thing; it
was designed to be an amazingly cheap, serviceable, low-power Linux
system. If you need that, it's the right tool for the job. If you
don't, it probably isn't.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
4:33 p.m.
On Tue, Sep 4, 2012 at 9:07 AM, Shoppa, Tim <tshoppa at wmata.com> wrote:
It's ironic that it seems increasingly hard to do
anything "bare metal" without
a graphical UI IDE on a desktop and a USB stack on the "bare metal".
Increasingly difficult perhaps, but not impossible.
I just got my R-Pi this weekend. I know how to drop a bunch of files
on an SD card, and I know how to to write C programs in a UNIX/Linux
environment, but I don't happen to know the ins and outs of ARM
assembly (I've done lots of assembly, but only on CPUs designed before
1980).
I happen to be going through the Cambridge tutorials as a quick way to
pick up the things that are new to me because of ARM, and to pick up
what specific directive syntax GCC's assembler wants (my first program
failed to compile because it didn't like my attempt to put
to-the-end-of-the-line comments after a semicolon).
I already teach folks at the hackerspace how to build projects with
Arduino. For all the thousands of R-Pi units that have already sold
and how many more will be sold, it's going to be a part of the hobby
ecosystem for some time. I am looking at what's out there now because
when the supply chain problems are finally worked out, I know there
will be a clamor for courses to teach a whole new round of folks what
it is and what they can do with it.
Is it perfect? No. Is it $35? Yes.
It's going to be popular, especially with people who just see the
initial price tag and want to do *something* with it.
-ethan
5 Sep
5 Sep
3:14 a.m.
On Tue, 4 Sep 2012 13:07:26 +0000
"Shoppa, Tim" <tshoppa at wmata.com> wrote:
It's ironic that it seems increasingly hard to do
anything
"bare metal" without a graphical UI IDE on a desktop and a
USB stack on the "bare metal".
As has been mentioned already: If you wane
do things like this Rpi is
the wrong tool because it is designed to run a full blowen OS. If you
wane start with in depth bare metal programming something like a AVR 8
bit microcontroler is much better suited. And you can programm it just
using command line tools like vi(1), make(1), avr-as(1), avr-gcc(1), ...
I'd prefere it over the smaler ARM microcontrolers for this purpose
as a AVR is as simple as a microcontroler can get today. Especially as
you can show students what you can do with just one single 14 Pin DIP
chip on a breadboard.
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
4371
days inactive
4372
days old
7 comments
6 participants
participants (6)
-
aek＠bitsavers.org -
ethan.dicks＠gmail.com -
fraveydank＠gmail.com -
jkunz＠unixag-kl.fh-kl.de -
mcguire＠neurotica.com -
tshoppa＠wmata.com