Seeking more input on hobbyist demo/educational stuff

and more here, as well as some at S.E.D.

I was thinking about a new thread or highjacking yours. Well, here it goes:

I know there are many anti-PIC-er here, but we need to learn more what and why not to PICk PIC. The world would be too boring to be all ARMs.

Yes, I plan to control the HVAC with PIC. However, i need to get the temperature logger working first. Running at 80MHz heat up the CPU and the thermosistor, not to mension shortening the battery life.

So, instead of running 7 million Nop() per second,

for(i=0; i

You also have a stated goal of trying to get people to build their own circuits. With that in mind, I think you should discuss PDIP based MCUs much more heavily than you might otherwise would.

If you are trying to get someone interested enough to build circuits, you are much more likely to succeed if they can assemble something quickly and easily on a breadboard or veroboard and watch it work.

After those initial experiences, you stand a better chance of getting them interested in the extra work involved in PCB based circuits (assuming they actually need to move to creating their own PCBs).

You do not want the 8-bit PICs to be the first MCU a person new to this world uses.

In addition to the lousy instruction set (which I admit does not matter nearly as much when programming in a HLL) there are other issues such as it's very limited interrupt support.

In the 8-bit PICs, you have to funnel everything down one of two interrupts (for the high end MCUs) or just one (for everything else) which means you have to check all interrupt sources in the one handler.

The AVR however has a much cleaner interrupt architecture and allows you to easily write standalone device libraries whose various components do not have to interact with each other.

To achieve this on the 8-bit PICs, I had to write a little interrupt handler library which my device handlers could register themselves with and the interrupt handler in this library would call the appropriate device handler when required.

In other words, I had to implement in software what you get for free in the MCU hardware on the AVR.

You want to pick as clean a architecture as possible for a first MCU, and the AVR is far cleaner than the 8-bit PICs.

As for why I have used 8-bit PICs if I feel this way ? Answer: It has USB device in PDIP and the AVR does not. (Either :-) or :-( depending on your frame of mind. :-))

Those are the only ones which come to mind for me. I did start out with the HC08 MCUs, but I outgrew those at least 5-6 years ago.

The PIC32MX is a seriously interesting part if you want people to build their own circuits and want something more powerful than a 8-bit device.

I've only had a quick look at the first part of that document, but some of the disadvantages for ARM can be relabeled as advantages with the right mind set. :-)

For example, it says that MIPS can get higher clock speeds more easily because of simpler instructions. You could turn that around and say you can do more in one ARM instruction than you can in a MIPS instruction and hence ARM could be considered quicker that way. :-)

(Note: that was a good natured comment. I have not actually written any MIPS code yet, but the instruction set looks reasonably clean and I will reserve forming opinions until I have experience in both architectures.)

Does CodeSourcery offer a front end to gdb ? I build my own tool chains from source and I am currently using ddd as a gdb front end.

Simon.

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

I do have that goal.... for some. Many will never do that. I want this to be accessible and useful to both groups.

The quandary there is that while I really would like to interest them in doing that, I also can't expect that everyone wants to or ever will want to.

But that said, I agree with the way you said your comment (for those you are talking about.)

Yup.

I've not decided that, yet.

Especially on the smaller parts. That "extended" beast though has quite a lot more in the hardware stack than before. (Yeah, that thing is annoying.)

But actually the whole idea of using 8-bit parts is, in my mind, something that you don't want "to be the first MCU a person new to this world uses" as you say. There are other reasons, even using C, why I think so.

This is why I'm considering seriously the idea that the MSP430 be their FIRST introduction. It's well supported, well worn path, cheap readily available starter boards direct from the company, and operates at the sweet spot. There are downsides to it -- it's clocking system is sophisticated and varies from part to part, for example. But I can finesses that. I can't finesse (not easily) some of what they'd be forced into facing with 8-bit parts using C (or have them use BASIC, I suppose.) The MSP430 relieves some of that pressure.

Yeah. High level vs low level in the midrange and PIC18 parts memory serving and just the one level for many others. But the flip side of that problem is explaining multiple interrupt vectors. There is good and bad in either approach when trying to explain it enough to use it to someone new.

It's been a awhile since I've used the AT90 in any thing professional. I do still have my old STK500 system and I've used them for hobby purposes once or twice, since. I have a lot of AT90S2313 parts sitting in a tube, too. But my recollection (I used assembly for the professional project) that while it was nice in some ways, it was not so nice in others. But it did the job, no question, and I really felt as though the development went pretty smoothly, too. So I grant that bottom-line.

appropriate

Yeah, but this isn't what I'd be talking about... to a newby. The whole idea of standalone device library design is "down the pike" a bit, whether easy or harder, and I'm not yet sure where I think they will be by the time I do consider writing about that (or if I do.)

Okay.

And the MSP430, I think, is even better at that stage.

Hehe. Yeah. Lots of differentiating niches all over the place. Boggles the mind. Which of course serves them, well.

I still have some of those laying about. Never used one for any project, though. Just curious at the time, but they never were the right match for anything I did. There is an HC908 thing too I seem to recall (I think I have some of those.)

To me it is MORE interesting because I have a LOT of experience with the R2000 core, going back to my days in the

1980's and when I spent a couple of days talking with Dr. Hennessey at MIPS (new start up, back then.) I learned a great deal, then, about designing cpu architectures -- two days in his presence as a 1:1 is enough to learn quite a lot.

I happen to consider the M4k (and M14k) to be "home ground" where I am very comfortable and ... feel an element of joy an love, to be honest about it. The ARM, by comparison, is foreign in some ways. It makes CISC-like decisions that I can't anticipate entirely because I've been trained to think like RISC designers would. I'll mention more of this in a moment.

1.pdf

What they are saying is the same thing I personally heard from Dr. Hennessey "way back when." There is a price in inserting register interlock flags (though the M4k uses a pipeline stage bypass pathway instead), for example.

That paper says, "The MIPS architecture has less predicated execution, which minimizes logic complexity and enablesMIPS cores to achieve higher frequencies." This is just that kind of thing -- anytime you insert logic in the main path you also insert delays. The longest delay path sets your max clock rate, since you MUST allow that combinatorial pathway to settle down. Inserting anything has a delay cost, if it is in a longer or longest path. Predication means including such logic to detect and act upon the predicates. And that means longer paths, and therefore slower clock rates.

This has always been the MIPS driving philosophy. The Alpha processor, by the way, took these ideas to a limit I never imagined. (And therefore saw as too hard to deal with, I admit.) The Alpha would incur exceptions, but you might be dozens of clock cycles down the road before you could get to a routine to deal with them. And there could be several and they just kept information, but let the handler deal with all of the hard job of UNWINDING things. It was daunting to consider. But fast. The basic idea was that exceptions are the exception. Make it FAST when there are no exceptions and let the pieces lay where they may when they happen. Most designers go to some trouble about pipeline stalls and so on. Not the Alpha. It didn't care. It just kept screaming on for a bit. I thought they went just a little too far. The Alpha went so far as to disallow any byte references. It had a

64-bit data path but they WOULD NOT insert any "lane changing" mux in that path. A designer often inserts a lane change switch so that bytes can be fetched over 16-bit or 32-bit or 64-bit data paths, picking out the 8-bits needed from the wider path. But inserting that means delays. Delays mean slower clock rate. Alpha said "no" to that. If you want bytes, mask them out and shift around, it said. That was your problem, not its, it said. Clock rate was the goal.

Dr. Hennessey (and founders like Dr. Patterson) also realized this would greatly pressure the memory system (at the time.) So they went to great trouble to include special cache parts, for data and instructions, as part of their R2000 core set.

By the way, Dr. Hennessey was very generous with his time with me. I was only a small time possibility for his business, but he took all the time I cared to accept in studying taped out cpu designs he had available at the time (like the 68020, which he kept a large version of on his office wall.)

It's a complete toolset. Or, for what I used of it, seemed to be. I used the tools to do some small verification, is all. So I can't say I've used them enough to answer your question.

I'll have to get better educated about this, though.

Jon

As I see it, there's absolutely no excuse for still considering PICs after having flat-out abolished the 8051. If there's any architecture still in active existence that's actually worse than the 8051, PIC must be it.

Looks like the most preferred choice among 8/16-bitters out there today. And a good deal less antagonistic to being programmed in anything else than assembler than both the PIC and 8051.

For the hobbyist market: absolutely. Professional developers would have to consider other options, too. E.g. ARM's own compiler bundled with Keil, or the considerably wide selection of third-party compiler vendors like GreenHills, IAR, etc. ARMs well may have the widest selection of different compilers of all currently active architectures in the embedded market. Some of those might be viable for "serious" hobby use, but the low-price end of that market appears to be owned by GNU.

I can't agree here. But unless you want to engage a debate on the subject, we can just leave it as a disagreement and I'm happy with that. Either way is fine, though.

Not 16-bit. I'd go MSP430 there. No question.

Assembly is part of an architecture discussion. That happens somewhat later on, and only if that's a path they want to pursue. If so, then it becomes a matter of how you want to approach teaching computer architecture. And on that point, the 8051 and PIC have their place.

The GNU toolset pathway has been well-worn in ARM. In fact, that is the place that gets the most use -- probably accounts for almost all its use, if I had to guess about it. It just works well. Even commercial vendors use it. It's just plain good medicine for ARM. That doesn't mean someone else can't point out an advantage in some commercial product -- but I doubt there is much regarding code quality to show. Mostly in the periphery, I suspect. But I'm ignorant about a lot of things, too.

CodeSourcery appears to me to have the most lenient policy for hobbyists -- explicit on their web site and not hard to find, simply free in all the meanings of it, and updated twice a year. No one else offering commercial support and libraries does as much, I think.

I'm still considering M4k and M14k -- if I choose to consider talking about Cortex M4F or M4.

Jon

Hi John,

Couldn't remember if I gave the link for the 4e4th software. This gives a fully functional Forth for the MSP430 Launchpad board which can then be communicated with by a simple terminal programme. This makes it a whole lot easier to programme.

--
******************************************************************** 
Paul E. Bennett............... 
Forth based HIDECS Consultancy 
Mob: +44 (0)7811-639972 
Tel: +44 (0)1235-510979 
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. 
********************************************************************

a

lot

Thanks, Paul. I would like to avoid writing about Forth, though. One reason is that I'm not an expert at it. (It's been so many years now and I never did write anything professional using it [since no one inquired and my lack of expertise with it wouldn't allow me to suggest it, myself.]) There are some other reasons having to do with my personal opinions (current, and subject to change) about the slant.

But I'm going to check the link anyway. I think I saw it earlier on the yahoo group and took note then. Might have been a different link, though. Anyway, I was interested to try it out.

So thanks, Jon

? Why avoid the 8051, but include PIC ?

There are good simulators for the 8051, and companies like SiLabs have good, low cost Toolstick Emulation offerings.

PIC is not that low cost to get into In Circuit Debug with ..

and ATXMega, which seems to have the price-point on 'USB controllers with reasonable uC'

Not well worn, but Wide Vcc is seeing a resurgance. Parts from Freescale and STM8S are other 8 bit cores....

Yes the 'cheap to get going' wins here.

If you want ARM _and_ WideVcc, _and_ low cost, (ie the Student sweet spot) and Debug and Tools and PCB from one link, then look at this :

There are also DSC from TI and Freescale.

- and the RX200 series from Reneas ....

My pet peeve with 32 bit controllers : WHY does anyone put 16 bit timers, with a 32 bit core ?!

-jg

Even though it is NOT so easy to explain an 8-bit PIC, it is EVEN HARDER to explain the 8051. That is, to kids these days. If this were the next thing AFTER teaching a computer architecture class, either one would be equal in my mind -- they are both good at exposing interesting details like a "transparent man" exposes internals to view. But the 8051 is more complex to explain. Register banks that can be quickly switched in an interrupt routine is GREAT for speed, but I'm not sure how to write about it. Bit manipulation applying only to certain parts of the internal ram, but not other parts. And discussing when the direct ram, indirect ram, external memory... I think the PIC is easier to write about, without the architecture background leading into it first. And I don't think that's the path, right now.

I mentioned the AVR, by the way, here. Others seem to imagine that is the best way to go, not the PIC. I think BOTH are well worn paths. But the AVR has compiler tools in its advantage over PIC (in terms of cheap, available, well worn

-- in my current opinion subject to change.) The 8051 has SDCC, I suppose, which give it an advantage over PIC in terms of cost of tools.

Like I said, I'm thinking out loud here and just seeing what shakes out. I want my ass kicked when my view isn't even close to comprehensive. So kick away.

One of the problems I have with SiLabs is from personal experience. I needed information on the DMA. The datasheet was "incomplete" and NO ONE there could answer my question. So they finally got back to me, two months later, after they tracked down the designer of the DMA unit (who was 8 years off doing something else and hard to find) in order to find out how it actually works. Seriously. That really happened. I have all the emails to prove it and to show the elementary nature of my question, too.

But I like the part. It worked as I wanted it to. And the ONLY problem I had was with the DMA. (Try running 1MHz 16-bit ADC data into the 8051 memory with anything else on that darned 8051.) Still, I had to write a number of specialized assembly routines to get the performance needed -- because of the bottleneck of the external memory DPTR register.

I guess that's not a reason to say no. But my instincts tell me that when I start to write, on THIS PROCESSOR, I will find myself WRITING TOO MUCH, TOO LONG, TOO HARD. Maybe I'm wrong.

Yeah, I admit that!! I will look around for options there.

Hmm. Need to update myself on that one. Thanks. That's why I'm asking here. To get a broader view I lack.

Wide Vcc is both simple and complex. There isn't a complete toolset of surrounding parts that match up, yet. People always asking questions about level conversion, "tolerant" I/O, etc. I am not so sure that is near the top of my list of things I care about going into this, though I recognize it's happening a lot more. But I'd like to cover it simply. So it's not a make/break issue for me, I think.

Hehe.

spot)

Well worn paths?

Some have 64-bit, I gather. Like the TI Stellaris Launchpad LM4F120H5QR's concatenated 64-bit GPTM register. I admit I've NOT done anything more than skim over the datasheet to see the number. So I may be all wet here, too. Lots of work ahead.

Point taken, though.

Jon

SDCC supports the 8-bit PICs and it worked for the MCU I used it with.

As for a actual low cost programmer however, you are on your own with that one. :-)

The part I was interested in wasn't suitable for use with a JDM style programmer, so I eventually built my own based around a AVR.

The AVRs are certainly better supported when it comes to using a pure open source toolchain from compiler through to programmer.

Simon.

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

Jon Kirwan wrote: [ ... ]

One advantage PICs have is that the advanced-amateur/maker crowd seems to love them. Everything that comes out of dangerousprototypes.com, for example, seems to have a PIC on it, if it has a processor at all. When your ex-students have finished the book and start hitting the web sites, PICs are what they're going to see.

Mel.

Our client specifically asks for PIC, no matter what we say. It took me a long time just to throw in an AVR for LCD, because there are no good PIC alternatives. So, we are using Microchip's PIC32MX675F512, Atmel's Atmega169 and Microchip's MRF24J40.

This is part of a proposal for home automation showcase. I hope it is not too technical. It needs to be technical enough to show "we know what we are doing", but not too technical to turn off general audiences.

See: http://173.224.223.62/HomeLink

Comments are welcome.

Personally, I would not consider them ?supported?. I personally filed a total of 21 (twenty-one!) bugs against SDCC, many specific to the pic16 target. Some of them were minor, some were major, and more than one was so critical it produced silent generation of incorrect machine code! These were all filed almost two years ago, and only eight have been closed so far?and one of the bad-code-generation tickets is among those still open.

Use it if you wish, but beware.

Chris

On 05/10/2012 13:06, Jon Kirwan wrote:> Okay. Just to start off the list of candidate processors for > educational purposes and writing up various considerations > for them, let me offer this because then folks will say "you > missed this.." and "what about that?", but also because I > probably don't have my details right anyway and need > corrections where they apply. > > In the 8-bit world, it's probably better to stay with well > worn hobbyist families (while avoiding the 8051, do you > think?) such as: > -- The Microchip PIC (up through PICF18?) I've been informed > about an extended variety of these, as well. > -- Atmel AVR (AT90) and ATmega and ATtiny.

I know this is just an opinion, but the (8-bit) PICs are a brain-dead cpu and will drive people crazy if they actually want to understand how the processor works. And if you don't want people to understand the devices, why bother with the project in the first place?

PICs have the advantage of having more DIP packages than any other microcontroller - but that is hardly relevant in the modern world. You either learn to make surface-mount boards, or you use ready-made boards and kits.

While there are plenty of things wrong with the AVR core, it is still the cleanest and most understandable 8-bit architecture in common use.

There are a wide range of chips available, at low prices, with lots of demo boards and starter kits. There are good quality tools (gcc), and the free IDE is good (personally, I don't like MSVS, and it is windows-only, but other than that it is good). The compiler does an excellent job, and has a strong community supported by Atmel.

There is a range of other software tools (programmers, debugger interfaces, etc.) for those that don't want to use Windows (or don't want to use AVR Studio).

The hardware debuggers and programmers are robust and reasonably priced.

There is lots of existing software (FreeRTOS, etc.) for the chips.

Choosing anything else for 8-bit is a waste of your time, and a disservice to your students. (IMHO, as always.)

(Again, don't forget the implied IMHO :-)

The 16-bit market is dead, so there is no point in considering it. The msp430 competes in the 8-bit class - it just happens to have 16-bit registers and ALU. But in all other respects it is a small low-power, low-speed, low-pincount microcontroller, just like the AVR. If there were some major reason that stopped you using the AVR, then the msp430 would be a good alternative for a small device - but if you have the AVR, then the msp430 does not give you or your students anything significant. Teach people to use an AVR, and they can easily switch to an msp430 later if they need it.

(Note that in "real life" projects there can be good reasons for picking an msp430 rather than an AVR - we use both at my company. But the requirements for an educational system are different from those of a professional project.)

Cross-purpose argument... I think. But as things develop, I'll see.

Your argument doesn't convince me. But perhaps experience during writing will.

So that's the sum of your argument? I could wish for something more nuanced. I did read the rest, but this seems to be your whole argument about the MSP430.

Jon

personally filed a

among those

Thanks, Chris. These kinds of experiences are helpful. I used SDCC for the 8051 core used in the SiLabs parts and had no real troubles completing the somewhat long application using SDCC. But it wasn't for the PIC, either. And I'm sure I got lucky, anyway. But it was a positive experience in that case, at least.

Thanks again, Jon

8 bit micros remain strong sellers, and they are a good base to teach from, because they do NOT have 1000 page Data sheets.

There are signs of 32 bit socket-buying from Market-droids at some companies, but that can drive down ASP faster than sales ramp, and the design lifetimes of

32 bit are already looking shorter. It seems everyone hopes to buy market share, and avoid cannibalise of their own cores. Customers are caught in this scramble, and have to hope the variant they chose today, is still available in 3/5/8 years time - at a sensible price. Only a small portion of the 32 bit offerings are 5V capable, so the rest cannot drop into a 5V application, to displace a 8 bit core. Renesas seems to have grasped this faster than other vendors, but they do have a large portion of the Automotive market.

The Asian sector understand this better than many, and they continue strong development in 8 bit controllers.

-jg

I think almost anyone who has experience with both PICs and AVRs can tell you which has the nicest cpu architecture and the best compilers and development tools.

As I noted, the PICs do have a few good points - but /I/ would not recommend them at any level.

And yes, that is an /opinion/ - it is up to you to agree or disagree. Take my advice for what you think it is worth - it's your project, not mine.

It's not quite my whole argument - you snipped the rest. My point is that the msp430 competes in the same market as 8-bit devices like the AVR (and the PIC).

The market is really divided into two parts - "small" devices characterised by low power, ease-of-use, small physical sizes, low cost, low speeds and small memories, and "big" devices characterised by a lot more processing power and peripherals, with corresponding costs in complexity, power and price.

The bit-width of the core is just one aspect of this. The "small" devices are almost entirely 8-bit - the msp430 is the only mainstream

16-bit device. (There are also Cortex devices creeping into this market, but I think we can leave them out for now.) The "big" devices are almost entirely 32-bit (with some 64-bit, but I doubt if you want to include them for hobbyists!).

If you are looking for a wide breadth of different devices, then the msp430 would be worth including - as you note, it is popular, has cheap development kits (including a good gcc port), and is a nice architecture (well, it /was/ nice until some half-wit decided it needed 20-bit extensions).

But if you are looking for a small number to concentrate on, then I can't see any point in including the msp430 when you have the AVR. The fact that it is 16-bit is not sufficient to make it worth the effort.

I've had a look in the bug tracker and that's quite a list of bugs from various people. :-(

I don't seem to have tripped over any of the code generation ones yet, but I've got to do some more work on the project I decided to use a PIC18F for, so it will be interesting to see if I trip over them when I do.

Thanks for the warning.

Simon.

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