Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
CPU's and boards for hobbyists?
118 views
Skip to first unread message
Ivan Shmakov
Nov 15, 2012, 3:25:33 AM11/15/12
to
>>>>> Erik Holter <erikb...@hotmail.com> writes:
[Cross-posting to news:comp.arch.embedded, just in case.]
[...]
> Or maybe someone just enjoys soldering their own computer and the
> feeling when it's booted for the first time (if it boots...)?
Well, as long as 8-bit architectures are concerned, my current
preference are AVR MCU's. The pro's are that one'd need only a
power source, and a resistor (for the /RESET circuit) to start
the thing up. (And a TTL serial port to program it; e. g.,
either MAX232 / MAX3232, or perhaps CP2103.) The die typically
hosts a number of peripherals as well, such as one or more
USART's, a two-wire (I2C) interface, a few timer/counters, an
analog comparator, and an ADC.
Depending on the chip, the cost may be in the $2 .. $5 a piece
range.
The cons. is that these employ the Harvard architecture, and
thus implementing a "conventional" 8-bit OS on such an MCU would
be challenging at best.
(And why, I've just ordered an Arduino Uno rev. 3 board.)
> That is kind of challenging to achieve for most people with a
> dual-core 64bit system...
I'd like to note that the difficulty of the task is not strictly
related to the number of cores. For instance, you'd only need a
suitably programmed serial flash chip (and a RESET circuit;
e. g., a button) to start a 40-core S40C18 MCU.
My guess is that there're MIPS64 MCU's upon which it's similarly
easy to build one's hobby projects, but I have no first-hand
experience with those. (Perhaps someone could suggest a model?
TIA.) Thus, it's not the bitness, either.
[1] http://www.intellasys.net/index.php?option=com_content&task=view&id=60&Itemid=75
> "How real" is an interesting question, but it does not affect the fun
> of making the kit work.
Agreed.
[...]
--
FSF associate member #7257
[Cross-posting to news:comp.arch.embedded, just in case.]
[...]
> Or maybe someone just enjoys soldering their own computer and the
> feeling when it's booted for the first time (if it boots...)?
Well, as long as 8-bit architectures are concerned, my current
preference are AVR MCU's. The pro's are that one'd need only a
power source, and a resistor (for the /RESET circuit) to start
the thing up. (And a TTL serial port to program it; e. g.,
either MAX232 / MAX3232, or perhaps CP2103.) The die typically
hosts a number of peripherals as well, such as one or more
USART's, a two-wire (I2C) interface, a few timer/counters, an
analog comparator, and an ADC.
Depending on the chip, the cost may be in the $2 .. $5 a piece
range.
The cons. is that these employ the Harvard architecture, and
thus implementing a "conventional" 8-bit OS on such an MCU would
be challenging at best.
(And why, I've just ordered an Arduino Uno rev. 3 board.)
> That is kind of challenging to achieve for most people with a
> dual-core 64bit system...
I'd like to note that the difficulty of the task is not strictly
related to the number of cores. For instance, you'd only need a
suitably programmed serial flash chip (and a RESET circuit;
e. g., a button) to start a 40-core S40C18 MCU.
My guess is that there're MIPS64 MCU's upon which it's similarly
easy to build one's hobby projects, but I have no first-hand
experience with those. (Perhaps someone could suggest a model?
TIA.) Thus, it's not the bitness, either.
[1] http://www.intellasys.net/index.php?option=com_content&task=view&id=60&Itemid=75
> "How real" is an interesting question, but it does not affect the fun
> of making the kit work.
Agreed.
[...]
--
FSF associate member #7257
Simon Clubley
Nov 15, 2012, 7:56:40 AM11/15/12
to
On 2012-11-15, Ivan Shmakov <onei...@gmail.com> wrote:
>>>>>> Erik Holter <erikb...@hotmail.com> writes:
>
> [Cross-posting to news:comp.arch.embedded, just in case.]
>
I'm posting from comp.arch.embedded so I will not see any followups unless
>>>>>> Erik Holter <erikb...@hotmail.com> writes:
>
> [Cross-posting to news:comp.arch.embedded, just in case.]
>
they are also cross-posted. I'm also coming at this cold, in that I don't
know the context for the cross-post, so I am assuming the reason for the
cross-post is that you want advice on the options which hobbyists have
available.
Unlike the other c.a.e posters, I am a hobbyist (at least when it comes
to embedded work).
> [...]
>
> > Or maybe someone just enjoys soldering their own computer and the
> > feeling when it's booted for the first time (if it boots...)?
>
> Well, as long as 8-bit architectures are concerned, my current
> preference are AVR MCU's. The pro's are that one'd need only a
> power source, and a resistor (for the /RESET circuit) to start
> the thing up. (And a TTL serial port to program it; e. g.,
> either MAX232 / MAX3232, or perhaps CP2103.) The die typically
> hosts a number of peripherals as well, such as one or more
> USART's, a two-wire (I2C) interface, a few timer/counters, an
> analog comparator, and an ADC.
>
a very well supported architecture for hobbyists. I've also done some
work with the PIC18 range (it has USB device in PDIP, which the AVR
does not) but I would strongly advise against the 8-bit PICs (lousy
architecture, including poor interrupt capabilities) unless you have a
very good reason for needing them.
> Depending on the chip, the cost may be in the $2 .. $5 a piece
> range.
>
> The cons. is that these employ the Harvard architecture, and
> thus implementing a "conventional" 8-bit OS on such an MCU would
> be challenging at best.
>
a CP/M clone on a hobbyist built board ?
> (And why, I've just ordered an Arduino Uno rev. 3 board.)
>
> > That is kind of challenging to achieve for most people with a
> > dual-core 64bit system...
>
> I'd like to note that the difficulty of the task is not strictly
> related to the number of cores. For instance, you'd only need a
> suitably programmed serial flash chip (and a RESET circuit;
> e. g., a button) to start a 40-core S40C18 MCU.
>
> My guess is that there're MIPS64 MCU's upon which it's similarly
> easy to build one's hobby projects, but I have no first-hand
> experience with those. (Perhaps someone could suggest a model?
> TIA.) Thus, it's not the bitness, either.
>
are looking for higher range MCUs for some emulation project which a
hobbyist can handle.
One device which has caught my attention is the PIC32MX, which is a 32-bit
MIPS architecture with a PIC24 style peripheral set. It's been on my to-do
list to have a look at for the best part of this year (but other projects
keep taking priority).
There's no external memory support (at least nothing worth speaking of)
but it might be of interest depending on what you want to do.
If you want something more serious than that, then as a hobbyist, I just
buy a pre-assembled board from Olimex; there's a large range of options to
choose from.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jeff Jonas
Nov 16, 2012, 8:42:48 AM11/16/12
to
> Unlike the other c.a.e posters,
> I am a hobbyist (at least when it comes to embedded work).
My embedded work is also only hobbyist, so far.
> I am a hobbyist (at least when it comes to embedded work).
>> > Or maybe someone just enjoys soldering their own computer and the
>> > feeling when it's booted for the first time (if it boots...)?
similarly enjoy "programming in solder"
despite the proliferation of microcontrollers in just about everything.
>> Well, as long as 8-bit architectures are concerned, my current
> When it comes to 8-bit MCUs, my strong preference is for the AVR;
> it's a very well supported architecture for hobbyists.
> I've also done some work with the PIC18 range
> (it has USB device in PDIP, which the AVR does not)
> but I would strongly advise against the 8-bit PICs
> (lousy architecture, including poor interrupt capabilities)
> unless you have a very good reason for needing them.
(the course was "instrumentation systems & microprocessors)".
The instructor had used the PIC-16 and was intrigued by the PIC-18
so we learned it together.
Despite being weaned in the ways of the PIC,
I agree that it's difficult to defend the architecture design & implementation,
particularly the non-vectored interrupt.
I was wary of the Atmel AVR because of all the Arduino folks
doing trivial projects with it, but I must agree that it's a nice chip.
At $4.30, the 16 bit TI MSP430 "Launchpad" developer's kit
is TRYING to be hobbyist friendly and compete for the Arduino crowd
but it just doesn't have the critical mass of support & interest.
Friends were early adopters of the MSP430 for the GNU toolchain
(they ONLY use open source Linux tools).
The Freescale "ColdFire" is
the embedded version of the 32 bit Motorola 68000
which is one of the nicest architectures ever.
But Freescale's sales force is currently pushing their ARM chips
and shows no interest in encouraging ColdFire development
despite destroying CodeWarrior (which was an architecture-neutral
development system for embedded systems,
but after Freescale acquired it, only Freescale parts are supported).
As for USB, having it as a built-in peripheral is nice
but then the software must enumerate as a standard serial port
lest you require custom drivers on everything to which it connects.
It's so much easier to just use a FTDI FT232RL
to convert between USB and serial. It does ALL THE WORK,
and has internal EEPROM for setting speeds, name, etc.
(the Prolific USB chip has no nonvolatile RAM,
so it must be reconfigured every power-up).
And everyone liked it: Linux, Windows all have drivers.
>> Depending on the chip, the cost may be in the
>> $2 .. $5 a piece range.
I'm yet to try Microchip for PIC samples.
>> The cons. is that these employ the Harvard architecture, and
>> thus implementing a "conventional" 8-bit OS on such an MCU
>> would be challenging at best.
such as CP/M since they co-mingled code and data so much.
But even simple Z80 systems
1) did some memory mapping for the boot ROM to appear for a while
even if RAM later filled the address space
2) did memory banking to break the 64k barrier
similar to the way the PC banked RAM to first break the 640k limitation.
3) had embedded versions to run from ROM
Harvard Arch is not such an alien concept.
Many machines had memory management that separated
I (instruction) from D (data).
The Z80's M1 line COULD be used to qualify the memory cycle
for an external memory management unit to differentiate
instruction fetch from data read/write,
allowing 2 separate 64k address spaces
and tricks like cycle stealing
(accessing the "other" memory while otherwise idle).
(Use static RAM and the refresh cycles
are also available for one access by other devices).
Did any machines do that?
I'd say it's pipelining that's most confusing to beginners.
First of all, it complicates timing calculations.
Secondly, it complicates single stepping for debugging.
> Seeing where this is been crossposted from,
> is the intention to implement
> a CP/M clone on a hobbyist built board ?
so I have authentic vintage hardware.
But I'm also learning & enjoying modern microcontrollers
since that's a more current, active & vibrant community.
And might help me on some consulting assignments too :-)
There are curious overlaps of the 2 communities,
such as Apple ][ and Commodore 64 folks with retrofits
such as SD card, ethernet adapters.
>One device which has caught my attention is the PIC32MX, which is a 32-bit
>MIPS architecture with a PIC24 style peripheral set. It's been on my to-do
>list to have a look at for the best part of this year (but other projects
>keep taking priority).
1) There's a PIC32 based Arduino board!
See the chipKIT on www.microchip.com
2) MIPS had finally been acquired by other companies
so they're allegedly stable again.
MIPS was one of the early fabless RISC core designers.
They're TRYING to compete with ARM
for the 32 bit RISC microcontroller arena.
The Microchip PIC32 is a MIPS core.
Since you mention the PIC24:
the "Microstick" is a cheap development kit for the PIC24
www.microchip.com/microstick3V
because they're trying to compete with the
TI MSP430 "LaunchPad development Tool"
www.ti.com/launchpad
for low power 16 bit microcontrollers.
Too many choices!
-- jeffj
m...@linnix.info-for.us
Nov 16, 2012, 1:29:51 PM11/16/12
to
> One device which has caught my attention is the PIC32MX, which is a 32-bit
>
> MIPS architecture with a PIC24 style peripheral set. It's been on my to-do
>
> list to have a look at for the best part of this year (but other projects
>
> keep taking priority).
We have been working on the PIC32MX and MRF24 for several months now. They both work well except for power consumptions. The PIC32MX draws around 50mA and the MRF24 around 24mA. We don't need sleeping for the server mode (coordinator), but need it for device mode (partial function devices).
>
> MIPS architecture with a PIC24 style peripheral set. It's been on my to-do
>
> list to have a look at for the best part of this year (but other projects
>
> keep taking priority).
This is the only thing keeping them from replacing the AVR.
>
>
>
> There's no external memory support (at least nothing worth speaking of)
>
> but it might be of interest depending on what you want to do.
Ivan Shmakov
Nov 20, 2012, 1:03:31 PM11/20/12
to
>>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>> On 2012-11-15, Ivan Shmakov <onei...@gmail.com> wrote:
[...]
>>>>> On 2012-11-15, Ivan Shmakov <onei...@gmail.com> wrote:
>> Depending on the chip, the cost may be in the $2 .. $5 a piece
>> range.
>> The cons. is that these employ the Harvard architecture, and thus
>> implementing a "conventional" 8-bit OS on such an MCU would be
>> challenging at best.
> Seeing where this is been crossposted from, is the intention to
> implement a CP/M clone on a hobbyist built board ?
quite a popular choice for a variety of "kit computers" back in
the day. So, the question is: is there any value whatsoever in
"kit" computers today, and if there is, what a system they
should run?
My guess is that the basic features for such a system would be
its ability to present a self-sufficient development environment
(i. e., the ability to be compiled from the source using the
bundled utilities, running under the system itself), and the
ability to utilize the now-cheap hardware (just as CP/M started
on the cheaper processors, which weren't quite meant to be used
as computers' CPU's.) Also, as long as the educational value of
such a system is considered, an additional requirement may be
that the source code for its "core" may be read in its entirety
by a semi-prepared person in a few nights.
Unfortunately, the "classic" CP/M doesn't seem to be a good fit,
at least as long as AVR 8-bit MCU's are considered. The first
obstacle is that the latter employ the Harvard architecture
/and/ execute the code from the flash memory. The "micro"
systems of the 80'es were quite modest in their RAM usage (for
both code and data), but as a consequence relied heavily on that
the no longer necessary code or data may be replaced with the
relevant one in RAM at no cost. With at most 10 000 erase
cycles the AVR code flash offers, this isn't nearly as feasible.
To further complicate the issue is that AVR has the interrupt
vectors in just the same flash that holds the code. Thus,
allowing the system to use loadable "device drivers" (which may
be considered a precondition for the "readability" requirement
above) may be a non-trivial task (although we may opt for a
"static" kernel, built to include all the necessary drivers.)
Not to mention that this complicates the use of the integrated
timers by the applications.
Also, given that most of the MCU's in the AVR 8-bit family don't
allow for external RAM, "RAM extension boards" aren't possible,
either. However, we may still use external memory (one or more
fast serial flash chips now, instead of FDD's of the old) for
the data rather cheaply.
[...]
> I'm missing the context for this part of the discussion, so I assume
> you are looking for higher range MCUs for some emulation project
> which a hobbyist can handle.
a contemporary "kit computer," what architecture and MCU could
the latter be based on instead?
> One device which has caught my attention is the PIC32MX, which is a
> 32-bit MIPS architecture with a PIC24 style peripheral set. It's
> been on my to-do list to have a look at for the best part of this
> year (but other projects keep taking priority).
for the chip? For sure, my preference would be to stick to the
"stock" version of GCC. (I see that this point is being
discussed in news:comp.arch.embedded right now.)
> There's no external memory support (at least nothing worth speaking
> of) but it might be of interest depending on what you want to do.
> If you want something more serious than that, then as a hobbyist, I
> just buy a pre-assembled board from Olimex; there's a large range of
> options to choose from.
to adhere to the digital freedom values.
Unfortunately, I don't seem to find anything that could be
called a "kit computer" in the sense above right now. Well,
Duinomite, or the like, could've been taken for one, but it
isn't "self-hosting." (Yet?..)
m...@linnix.info-for.us
Nov 20, 2012, 1:25:42 PM11/20/12
to
> Unfortunately, the "classic" CP/M doesn't seem to be a good fit,
> at least as long as AVR 8-bit MCU's are considered. The first
> obstacle is that
> execute the code from the flash memory. The "micro"
> systems of the 80'es were quite modest in their RAM usage (for
> both code and data), but as a consequence relied heavily on that
> the no longer necessary code or data may be replaced with the
> relevant one in RAM at no cost. With at most 10 000 erase
> cycles the AVR code flash offers, this isn't nearly as feasible.
Stephen Pelc
Nov 20, 2012, 1:29:47 PM11/20/12
to
On Wed, 21 Nov 2012 01:03:31 +0700, Ivan Shmakov <onei...@gmail.com>
wrote:
> My question has somewhat a wider scope. As it seems, CP/M was
> quite a popular choice for a variety of "kit computers" back in
> the day. So, the question is: is there any value whatsoever in
> "kit" computers today, and if there is, what a system they
> should run?
How about porting CP/M68k to ARM? See
http://www.cpm.z80.de/source.html
There's a floppy disk Sage IV in the garage somewhere ... if anyone
wants it.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
wrote:
> My question has somewhat a wider scope. As it seems, CP/M was
> quite a popular choice for a variety of "kit computers" back in
> the day. So, the question is: is there any value whatsoever in
> "kit" computers today, and if there is, what a system they
> should run?
http://www.cpm.z80.de/source.html
There's a floppy disk Sage IV in the garage somewhere ... if anyone
wants it.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Simon Clubley
Nov 21, 2012, 9:33:23 AM11/21/12
to
On 2012-11-20, Ivan Shmakov <onei...@gmail.com> wrote:
>>>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>>> On 2012-11-15, Ivan Shmakov <onei...@gmail.com> wrote:
>
> [...]
>
> >> Depending on the chip, the cost may be in the $2 .. $5 a piece
> >> range.
>
> >> The cons. is that these employ the Harvard architecture, and thus
> >> implementing a "conventional" 8-bit OS on such an MCU would be
> >> challenging at best.
>
> > Seeing where this is been crossposted from, is the intention to
> > implement a CP/M clone on a hobbyist built board ?
>
> My question has somewhat a wider scope. As it seems, CP/M was
> quite a popular choice for a variety of "kit computers" back in
> the day. So, the question is: is there any value whatsoever in
> "kit" computers today, and if there is, what a system they
> should run?
>
I can only speak for myself, but I don't think general purpose "kit"
>>>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>>> On 2012-11-15, Ivan Shmakov <onei...@gmail.com> wrote:
>
> [...]
>
> >> Depending on the chip, the cost may be in the $2 .. $5 a piece
> >> range.
>
> >> The cons. is that these employ the Harvard architecture, and thus
> >> implementing a "conventional" 8-bit OS on such an MCU would be
> >> challenging at best.
>
> > Seeing where this is been crossposted from, is the intention to
> > implement a CP/M clone on a hobbyist built board ?
>
> My question has somewhat a wider scope. As it seems, CP/M was
> quite a popular choice for a variety of "kit computers" back in
> the day. So, the question is: is there any value whatsoever in
> "kit" computers today, and if there is, what a system they
> should run?
>
computers have a place today, at least in the 8-bit area and, as you
note, the design of more modern 8-bit MCUs reflects that.
With their running code out of flash and with attributes like the
unchangeable (at least not easily) interrupt vectors at runtime, they
are clearly designed to be used in circuits designed to perform one
specific function only.
There is still some tendency towards self hosted development environments
on the 32-bit embedded boards (Raspberry Pi comes to mind here), but those
are not boards people are going to be able to easily build themselves at
home.
>
> To further complicate the issue is that AVR has the interrupt
> vectors in just the same flash that holds the code. Thus,
> allowing the system to use loadable "device drivers" (which may
> be considered a precondition for the "readability" requirement
> above) may be a non-trivial task (although we may opt for a
> "static" kernel, built to include all the necessary drivers.)
> Not to mention that this complicates the use of the integrated
> timers by the applications.
>
a better choice here. Since you have to run down the list of devices
in your interrupt handler to find out which one needs attention, there
is no reason why your interrupt handler cannot dispatch to the driver
via a interrupt table in RAM.
This is the approach I took, but in my case the goal was been able to
use a nicely modular software library (each module inserted it's driver's
address into the table during MCU startup).
>
> > I'm missing the context for this part of the discussion, so I assume
> > you are looking for higher range MCUs for some emulation project
> > which a hobbyist can handle.
>
> The point is again, if AVR proves to be an inadequate choice for
> a contemporary "kit computer," what architecture and MCU could
> the latter be based on instead?
>
are probably looking at the PIC32MX (based on what I currently know about
it). If you are happy to work with SMD components which are not BGA
based, Olimex have put together a Freescale ARM based board recently
(called OLinuXino) for which the hardware designs are freely downloadable.
> > One device which has caught my attention is the PIC32MX, which is a
> > 32-bit MIPS architecture with a PIC24 style peripheral set. It's
> > been on my to-do list to have a look at for the best part of this
> > year (but other projects keep taking priority).
>
> BTW, don't they provide their own C compiler (a GCC fork, AIUI)
> for the chip? For sure, my preference would be to stick to the
> "stock" version of GCC. (I see that this point is being
> discussed in news:comp.arch.embedded right now.)
>
bits in the mainline gcc/binutils sources in recent versions for you to be
able to use them instead. (I've had a quick look at this, but not actually
got anywhere near to trying it yet.)
> > There's no external memory support (at least nothing worth speaking
> > of) but it might be of interest depending on what you want to do.
>
> Does it mean "external RAM" specifically?
>
64K of external memory (IIRC).
Mark Borgerson
Nov 21, 2012, 11:11:50 PM11/21/12
to
In article <k8ioni$fi4$1...@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...
that allows you to set up a vector table in RAM and switch to it
some time after the initial boot process.
I think you could also have all the interrupt vectors in flash jump
though a jump table in RAM---as long as the boot code set up a
default jump table before enabling interrupts. I have a fuzzy
recollection of something like this happening way back in the
1990s.
Mark Borgerson
clubley@remove_me.eisner.decus.org-Earth.UFP says...
>
> On 2012-11-20, Ivan Shmakov <onei...@gmail.com> wrote:
> >>>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> >>>>>> On 2012-11-15, Ivan Shmakov <onei...@gmail.com> wrote:
> >
> > [...]
> >
> > >> Depending on the chip, the cost may be in the $2 .. $5 a piece
> > >> range.
> >
> > >> The cons. is that these employ the Harvard architecture, and thus
> > >> implementing a "conventional" 8-bit OS on such an MCU would be
> > >> challenging at best.
> >
> > > Seeing where this is been crossposted from, is the intention to
> > > implement a CP/M clone on a hobbyist built board ?
> >
> > My question has somewhat a wider scope. As it seems, CP/M was
> > quite a popular choice for a variety of "kit computers" back in
> > the day. So, the question is: is there any value whatsoever in
> > "kit" computers today, and if there is, what a system they
> > should run?
> >
>
> I can only speak for myself, but I don't think general purpose "kit"
> computers have a place today, at least in the 8-bit area and, as you
> note, the design of more modern 8-bit MCUs reflects that.
>
> With their running code out of flash and with attributes like the
> unchangeable (at least not easily) interrupt vectors at runtime, they
> are clearly designed to be used in circuits designed to perform one
> specific function only.
IIRC, many of the ARM and ARM Cortex MPUs have a vector base register
> On 2012-11-20, Ivan Shmakov <onei...@gmail.com> wrote:
> >>>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> >>>>>> On 2012-11-15, Ivan Shmakov <onei...@gmail.com> wrote:
> >
> > [...]
> >
> > >> Depending on the chip, the cost may be in the $2 .. $5 a piece
> > >> range.
> >
> > >> The cons. is that these employ the Harvard architecture, and thus
> > >> implementing a "conventional" 8-bit OS on such an MCU would be
> > >> challenging at best.
> >
> > > Seeing where this is been crossposted from, is the intention to
> > > implement a CP/M clone on a hobbyist built board ?
> >
> > My question has somewhat a wider scope. As it seems, CP/M was
> > quite a popular choice for a variety of "kit computers" back in
> > the day. So, the question is: is there any value whatsoever in
> > "kit" computers today, and if there is, what a system they
> > should run?
> >
>
> I can only speak for myself, but I don't think general purpose "kit"
> computers have a place today, at least in the 8-bit area and, as you
> note, the design of more modern 8-bit MCUs reflects that.
>
> With their running code out of flash and with attributes like the
> unchangeable (at least not easily) interrupt vectors at runtime, they
> are clearly designed to be used in circuits designed to perform one
> specific function only.
that allows you to set up a vector table in RAM and switch to it
some time after the initial boot process.
I think you could also have all the interrupt vectors in flash jump
though a jump table in RAM---as long as the boot code set up a
default jump table before enabling interrupts. I have a fuzzy
recollection of something like this happening way back in the
1990s.
Wilf
Nov 22, 2012, 12:51:38 AM11/22/12
to
There is this one recently produced in Australia. The target market is I
think people who had one in the 80's.
http://www.microbeetechnology.com.au/
The Maximite was another on based on a PIC device. Quite different but
did have BASIC.
http://geoffg.net/maximite.html
Wilfred
think people who had one in the 80's.
http://www.microbeetechnology.com.au/
The Maximite was another on based on a PIC device. Quite different but
did have BASIC.
http://geoffg.net/maximite.html
Wilfred
Simon Clubley
Nov 22, 2012, 7:53:36 AM11/22/12
to
On 2012-11-21, Mark Borgerson <mborg...@comcast.net> wrote:
> In article <k8ioni$fi4$1...@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP says...
>>
> In article <k8ioni$fi4$1...@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP says...
>>
>> I can only speak for myself, but I don't think general purpose "kit"
>> computers have a place today, at least in the 8-bit area and, as you
>> note, the design of more modern 8-bit MCUs reflects that.
>>
>> With their running code out of flash and with attributes like the
>> unchangeable (at least not easily) interrupt vectors at runtime, they
>> are clearly designed to be used in circuits designed to perform one
>> specific function only.
>
> IIRC, many of the ARM and ARM Cortex MPUs have a vector base register
> that allows you to set up a vector table in RAM and switch to it
> some time after the initial boot process.
>
Yes, I know (which is why I only talked about 8-bit MCUs above) but thanks
>> computers have a place today, at least in the 8-bit area and, as you
>> note, the design of more modern 8-bit MCUs reflects that.
>>
>> With their running code out of flash and with attributes like the
>> unchangeable (at least not easily) interrupt vectors at runtime, they
>> are clearly designed to be used in circuits designed to perform one
>> specific function only.
>
> IIRC, many of the ARM and ARM Cortex MPUs have a vector base register
> that allows you to set up a vector table in RAM and switch to it
> some time after the initial boot process.
>
for the information anyway.
Of course on, for example, the ARM7TDMI you have a nice variant of this in
that you come out of reset with your interrupt vectors in flash, but can
issue a remap (at least on the ones I am familiar with) to map the SRAM to
the address space occupied by the interrupt vectors.
As for the jump table in RAM idea, that's a nice idea. As already mentioned
I've done it on the PIC18 but I've never had the need to do it on any other
8-bit device so I don't know what issues may be encountered on, say, the AVR.
Ivan Shmakov
Nov 22, 2012, 9:45:56 AM11/22/12
to
>>>>> me <m...@linnix.info-for.us> writes:
>> Unfortunately, the "classic" CP/M doesn't seem to be a good fit, at
>> least as long as AVR 8-bit MCU's are considered. The first obstacle
>> Unfortunately, the "classic" CP/M doesn't seem to be a good fit, at
>> least as long as AVR 8-bit MCU's are considered. The first obstacle
>> is that the latter employ the Harvard architecture /and/
> almost all modern microcontrollers > ...
>> execute the code from the flash memory.
The point is, specifically, in that it isn't possible to make an
>> execute the code from the flash memory.
AVR 8-bit MCU to execute native code from RAM (either internal,
or external, for those variants that support it.)
IIUC, both MSP430 (16 bit) and ARM (32 bit) MCU's allow the code
to be executed either from internal flash, or internal RAM.
Of those I was able to easily find in the online stores,
MSP430F5418 (MSP430F5438) and STM32F103xx seem like a cheap fit
to base a "kit" computer upon. (Though I have no first-hand
experience with either family.)
[...]
> Some PIC32 has 128K RAM, so you can reload as often as you want.
just like the MSP430 and ARM families?
I find their lack of cooperation with the GCC folks somewhat
disturbing. Given that I have no first-hand experience with any
of these three, I wonder if there is a specific reason to
consider a Microchip MCU?
> With 512K flash, we have plenty of memory to cycle through. To
> address the flash cycle limit, we implement layers of modules such as
> L0, L1, L2 and L3. Currently, L0 is 7K, L1 is 30K, L2 is 5K and L3
> is 8K. L3 is our main application layer, we seldom change L0 to L2.
> With 8K to rotate through 384K (we reserve lower 128K for L0 to L2),
> we can page (not chip) erase and flash it 48 times more. So, 480,000
> cycles for less than $10 is cheap enough.
It doesn't quite help with the "interrupt vectors in flash"
issue, though.
m...@linnix.info-for.us
Nov 22, 2012, 11:27:17 AM11/22/12
to
> > Some PIC32 has 128K RAM, so you can reload as often as you want.
>
> ... And, I assume, it implements the von Neumann's architecture,
> just like the MSP430 and ARM families?
150MHz (flash would need many wait states and at most 100MHz). Unfortunately, i could not reprogram or recover the chip. So, haven't try it again.
> I find their lack of cooperation with the GCC folks somewhat
> disturbing.
> Given that I have no first-hand experience with any
> of these three, I wonder if there is a specific reason to
> consider a Microchip MCU?
>
> > With 512K flash, we have plenty of memory to cycle through. To
> > address the flash cycle limit, we implement layers of modules such as
> > L0, L1, L2 and L3. Currently, L0 is 7K, L1 is 30K, L2 is 5K and L3
> > is 8K. L3 is our main application layer, we seldom change L0 to L2.
> > With 8K to rotate through 384K (we reserve lower 128K for L0 to L2),
> > we can page (not chip) erase and flash it 48 times more. So, 480,000
> > cycles for less than $10 is cheap enough.
>
> Indeed, that may be a sensible solution.
> It doesn't quite help with the "interrupt vectors in flash"
> issue, though.
Ivan Shmakov
Nov 22, 2012, 11:59:22 AM11/22/12
to
>>>>> Wilf <wilf...@live.com> writes:
[Cross-posting to news:comp.sys.misc, and dropping
news:comp.os.cpm (in favor of the former) from Followup-To:.]
> There is this one recently produced in Australia. The target market
> is I think people who had one in the 80's.
> http://www.microbeetechnology.com.au/
The point is that as a "remake", such a computer is not to be
expected to be cheap. And, indeed, it isn't.
For a "non-kit", one-board (cheap) computer, I'd probably check
Raspberry Pi or the Gooseberry board. Both are ought to be
rather fully-featured, with over than 29000 software packages
readily available [1].
[1] http://www.debian.org/
> The Maximite was another on based on a PIC device. Quite different
> but did have BASIC. http://geoffg.net/maximite.html
I've mentioned DuinoMite (a derivative system from a different
vendor) already in this thread.
Unfortunately, the designer behind Maximite, and also the author
of the MMBasic firmware bundled, has regretted his earlier
choice to release MMBasic as free software, as the design has
readily spawned a number of derivatives (including DuinoMite),
whose respective authors not necessarily credited him, or at
times provided inferior versions of the software, allegedly
harming his reputation.
... A feature of the design is the use of the SPI interface to
drive a VGA interface, which seems like a clever one (even if it
wasn't the first time SPI was used for such a trick.) However,
it made me wonder on what CPU frequency is used? (I see the
crystal, but I presume the chip has an internal frequency
multiplier.)
Also, I see that while the ATmega8-family MCU's are able to
drive SPI at half the core frequency, it's possible to get the
system's clock output at the CLKO pin. I wonder if it may make
sense to drive a parallel-to-serial chip (such as, e. g.,
74HC165) to achieve the 20 MHz pixel clock for such an
improvised VGA output? (I. e., instead of using the
SPI-internal shift register.)
[Cross-posting to news:comp.sys.misc, and dropping
news:comp.os.cpm (in favor of the former) from Followup-To:.]
> There is this one recently produced in Australia. The target market
> is I think people who had one in the 80's.
> http://www.microbeetechnology.com.au/
expected to be cheap. And, indeed, it isn't.
For a "non-kit", one-board (cheap) computer, I'd probably check
Raspberry Pi or the Gooseberry board. Both are ought to be
rather fully-featured, with over than 29000 software packages
readily available [1].
[1] http://www.debian.org/
> The Maximite was another on based on a PIC device. Quite different
> but did have BASIC. http://geoffg.net/maximite.html
vendor) already in this thread.
Unfortunately, the designer behind Maximite, and also the author
of the MMBasic firmware bundled, has regretted his earlier
choice to release MMBasic as free software, as the design has
readily spawned a number of derivatives (including DuinoMite),
whose respective authors not necessarily credited him, or at
times provided inferior versions of the software, allegedly
harming his reputation.
... A feature of the design is the use of the SPI interface to
drive a VGA interface, which seems like a clever one (even if it
wasn't the first time SPI was used for such a trick.) However,
it made me wonder on what CPU frequency is used? (I see the
crystal, but I presume the chip has an internal frequency
multiplier.)
Also, I see that while the ATmega8-family MCU's are able to
drive SPI at half the core frequency, it's possible to get the
system's clock output at the CLKO pin. I wonder if it may make
sense to drive a parallel-to-serial chip (such as, e. g.,
74HC165) to achieve the 20 MHz pixel clock for such an
improvised VGA output? (I. e., instead of using the
SPI-internal shift register.)
Simon Clubley
Nov 22, 2012, 12:56:40 PM11/22/12
to
On 2012-11-22, Ivan Shmakov <onei...@gmail.com> wrote:
>
> I find their lack of cooperation with the GCC folks somewhat
> disturbing. Given that I have no first-hand experience with any
> of these three, I wonder if there is a specific reason to
> consider a Microchip MCU?
>
The one reason I am interested in the PIC32MX is because it comes in PDIP.
>
> I find their lack of cooperation with the GCC folks somewhat
> disturbing. Given that I have no first-hand experience with any
> of these three, I wonder if there is a specific reason to
> consider a Microchip MCU?
>
Given that it's much more capable than the typical 8-bit options, this
would give me more options on what I can build at home versus what I have
to buy in as a preassembled board.
And yes, Microchip's behaviour with the toolchain makes me uneasy also.
My aim would be to try and get the mainstream gcc/binutils kits built as
a cross compiler for a MIPS M4K target and see if all the bits are present
in the mainstream kits for me to use them instead.
>
> Indeed, that may be a sensible solution.
>
> It doesn't quite help with the "interrupt vectors in flash"
> issue, though.
>
table in RAM which is setup before interrupts are enabled.
m...@linnix.info-for.us
Nov 23, 2012, 11:28:40 AM11/23/12
to
> The one reason I am interested in the PIC32MX is because it comes in PDIP.
Unfortunately, it only has the low-end chip (up to 128K flash) in PDIP. We are seriously considering packing a 512K version in a pin-compatible carrier, and with an integrated RF packet radio (i.e. MC13202). BTW, we will be able to do firmware upgrade over RF.
> Given that it's much more capable than the typical 8-bit options, this
> would give me more options on what I can build at home versus what I have
> to buy in as a preassembled board.
piece of cake to solder.
> And yes, Microchip's behaviour with the toolchain makes me uneasy also.
> My aim would be to try and get the mainstream gcc/binutils kits built as
> a cross compiler for a MIPS M4K target and see if all the bits are present
> in the mainstream kits for me to use them instead.
http://173.224.223.62/pic32
> I liked the earlier suggestion to have the vectors go through a jump
> table in RAM which is setup before interrupts are enabled.
You can see why we are interested in the 512K version only.
Simon Clubley
Nov 23, 2012, 12:58:27 PM11/23/12
to
On 2012-11-23, m...@linnix.info-for.us <m...@linnix.info-for.us> wrote:
>> The one reason I am interested in the PIC32MX is because it comes in PDIP.
>
> Unfortunately, it only has the low-end chip (up to 128K flash) in PDIP. We
> are seriously considering packing a 512K version in a pin-compatible carrier,
> and with an integrated RF packet radio (i.e. MC13202). BTW, we will be able to
> do firmware upgrade over RF.
>
That's quite true, but those PDIP devices, especially since they go up to
>> The one reason I am interested in the PIC32MX is because it comes in PDIP.
>
> Unfortunately, it only has the low-end chip (up to 128K flash) in PDIP. We
> are seriously considering packing a 512K version in a pin-compatible carrier,
> and with an integrated RF packet radio (i.e. MC13202). BTW, we will be able to
> do firmware upgrade over RF.
>
32K RAM, are still vastly more capable than the 8-bit MCUs I am familiar
with.
>> Given that it's much more capable than the typical 8-bit options, this
>> would give me more options on what I can build at home versus what I have
>> to buy in as a preassembled board.
>
> With outsourcing PCBs, you can certainly do a lot at home. 25 mils TQFP is
> piece of cake to solder.
>
About once a year (on average), I seem to provoke c.a.e residents into
trying to persuade me to go down this path. One day I may actually do it. :-)
>> And yes, Microchip's behaviour with the toolchain makes me uneasy also.
>> My aim would be to try and get the mainstream gcc/binutils kits built as
>> a cross compiler for a MIPS M4K target and see if all the bits are present
>> in the mainstream kits for me to use them instead.
>
> Our application layers are pure MIPS/C code, it does not know anything about
> PIC32. Currently, there are some direct I/O calls, but we can always push them
> down to the system modules (L0:Kernel, L1:K-lib, L2:U-lib, L3:User). We can
> loan you a board to try it with building gcc. You can also build and test (an
> emulator) on our virtual server:
>
> http://173.224.223.62/pic32
>
I bought some items from Farnell, I also picked up some PIC32 MCUs as well.
The problem for me is not buying the things, but the fact that the list of
items on my hobbyist schedule is far greater than the amount of the time
I have to work on them. :-)
0 new messages