CPU's and boards for hobbyists?

I'm posting from comp.arch.embedded so I will not see any followups unless 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).

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.

Seeing where this is been crossposted from, is the intention to implement a CP/M clone on a hobbyist built board ?

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.

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

My embedded work is also only hobbyist, so far.

Circuit Cellar and other "maker" engineering forums similarly enjoy "programming in solder" despite the proliferation of microcontrollers in just about everything.

I learned the PIC-18 for a masters level course for interfacing sensors (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.

Or free. Free Atmel samples are available, max 3 of the same item. I'm yet to try Microchip for PIC samples.

You're probably right if trying to port "classic" systems 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.

I still have my Z80B 6 MHz CP/M Servo-8 SBC, 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.

Just to muddle things

1) There's a PIC32 based Arduino board! See the chipKIT on

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

because they're trying to compete with the TI MSP430 "LaunchPad development Tool" for low power 16 bit microcontrollers.

Too many choices!

-- jeffj

t o

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 50 mA and the MRF24 around 24mA. We don't need sleeping for the server mode ( coordinator), but need it for device mode (partial function devices).

This is the only thing keeping them from replacing the AVR.

As long as you can live within 512K flash and 64K ram. Older mpu (8080/z80/

6800) have 64K total memory anyway.

[...]

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?

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.

[...]

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?

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.)

Does it mean "external RAM" specifically?

The good point is that both Olimex and the Arduino project seem 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?..)

--
FSF associate member #7257

almost all modern microcontrollers > ...

Some PIC32 has 128K RAM, so you can reload as often as you want. With 512K flash, we have plenty of memory to cycle through. To address the flash cy cle limit, we implement layers of modules such as L0, L1, L2 and L3. Curre ntly, L0 is 7K, L1 is 30K, L2 is 5K and L3 is 8K. L3 is our main applicati on layer, we seldom change L0 to L2. With 8K to rotate through 384K (we re serve lower 128K for L0 to L2), we can page (not chip) erase and flash it 4

8 times more. So, 480,000 cycles for less than $10 is cheap enough.

How about porting CP/M68k to ARM? See

There's a floppy disk Sage IV in the garage somewhere ... if anyone wants it.

Stephen

--
Stephen Pelc, stephenXXX@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

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.

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.

In some ways, the PIC18, with it's lousy interrupt handling is actually 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).

If you want the average person to be able to build it themselves, you 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.

Yes they do, and yes it's gcc/binutils based. In theory, there may be enough 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 a Parallel Master Port (PMP) which can support in the region of

64K of external memory (IIRC).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

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.

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

There is this one recently produced in Australia. The target market is I think people who had one in the 80's.

The Maximite was another on based on a PIC device. Quite different but did have BASIC.

Wilfred

Yes, I know (which is why I only talked about 8-bit MCUs above) but thanks 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.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

The point is, specifically, in that it isn't possible to make an 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.)

[...]

... And, I assume, it implements the von Neumann's architecture, 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?

Indeed, that may be a sensible solution.

It doesn't quite help with the "interrupt vectors in flash" issue, though.

--
FSF associate member #7257

Yes, you can run code in RAM, in fact much faster. I tried a ram routine a t

150MHz (flash would need many wait states and at most 100MHz). Unfortunate ly, i could not reprogram or recover the chip. So, haven't try it again.

At long as they provide free download of the GCC lite-version, we have no p roblem with that. We only need to use the compiler, not to fix it. Generi c MIP32 is well supported by GCC. So, in case we need a custom chip, we ca n always go direct to MIP32. In fact, nothing we have done so far is speci fic to MIP. We don't really care if it's MIP or ARM. We have done some TI /LMI and STM ARMs. Beyond the startup code, there is not much different be tween MIP and ARM.

Our reason was the Microchip MRF24J40 RF library. However, it turns out th at we don't really need any library codes and we might switch to Freescale' s MC13202 anyway.

Interrupts are only done in L0 (kernel layer). If necessary, we can always remap it to ram or somewhere in flash. In fact, we want to hide all the u gly interrupt codes from the application layer.

[Cross-posting to news:comp.sys.misc, and dropping news:comp.os.cpm (in favor of the former) from Followup-To:.]

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]

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.)

--
FSF associate member #7257

The one reason I am interested in the PIC32MX is because it comes in PDIP. 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.

I liked the earlier suggestion to have the vectors go through a jump table in RAM which is setup before interrupts are enabled.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

.

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 carri er, and with an integrated RF packet radio (i.e. MC13202). BTW, we will be able to do firmware upgrade over RF.

With outsourcing PCBs, you can certainly do a lot at home. 25 mils TQFP is piece of cake to solder.

t

Our application layers are pure MIPS/C code, it does not know anything abou t PIC32. Currently, there are some direct I/O calls, but we can always pus h 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 a nd test (an emulator) on our virtual server:

http://173.224.223.62/pic32

We do have a RAM table for all the inter-module calls. For instance, sendi ng an RF packet requires call from L3 to L2, L2 to L1 and L1 to L0. Furthe rmore, the bootloader checks for empty program pages before jumping there. For example, starting with page 0x80, jump there if not all 0xff (erased b its). If empty, try page 0x81, etc. First version of app is at 0xff, seco nd version at 0xfe, etc. The app can reprogram itself at a lower page and ask the bootloader to redirect it.

You can see why we are interested in the 512K version only.

to

That's quite true, but those PDIP devices, especially since they go up to

32K RAM, are still vastly more capable than the 8-bit MCUs I am familiar with.

I know as I've had this pointed out to me before. :-)

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. :-)

them

Thanks for the offer, I really do appreciate it. However, the last time 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. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

Another sighting: Chumby Hacker board

(This is an old thread, and lots of posts have expired. Have we already talked about this one?)

I start to think that the Linux-based boards are a completely different tribe from the smaller processors, and would need a completely different treatment. With a hardware-centric solution I would never be thinking about using SysV IPC to put a firedoor between the GPIO-controlling processes (which need root privileges on the Raspberry Pi) and the Internet-facing processes.

Mel.

I don't recall seeing it.

Ignoring the sensors, it looks comparable to the Olimex boards here:

The Olimex boards are cheaper, but they do not have the sensors onboard that the above board does.

I suppose it depends on what you are going to do with them. I have come up with a number of project ideas for these types of boards, but none of them involve any public facing Internet connection, so that's not a issue I have yet had to tackle, but I agree with the role seperation.

I wonder if the versions of Linux running on these boards support SELinux ? I could see the benefits of creating a heavily restricted SELinux profile for the internet component in your above setup in case someone managed to break through your Internet facing process above.

I use SELinux on all my Internet facing Linux boxes, both at home and work, and I consider it something useful to have active in case the system security is ever compromised, although (as always) there are no guarantees here. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

I don't understand why you would need a fire door in the first place. At most you are not sinking very much current from a MCU, hardly enough to start a fire. Building a fire door might be a fun project, i.e. temp detection, servo to close off oxygen supply but it is not necessary. I find this typical of the folks who use Linux on VSCDs (Very Small Computing Devices).