ByPic A PIC32 with built in compiler and a cross between Basic and C with Arduino footprint

You don't have to use C++, c is fine. Modern architectures are purpose-tuned for C, they practically execute the statements directly!

While Cortex/ARM dev boards are likely more expensive compared to a naked PIC, we are only talking in the $10 region for some of them. And of course you can use the bare metal Cortex or whatever with an SMT adapter board or your own design.

DC accuracy is probably awful though.

--

John Devereux

On a sunny day (Thu, 03 Oct 2013 16:22:20 +0100) it happened John Devereux wrote in :

Yes, I know, was waving to Dr Hobbs.

chopper?

Sure, why not. But I can see something like that ADI chip being a neater solution for many things than some clunky USB "sound card" + chopper + rPi lashup :)

Appears to be no support in openocd though so a non-starter for me.

--

John Devereux

On a sunny day (Thu, 03 Oct 2013 17:38:37 +0100) it happened John Devereux wrote in :

Yes, sure. I installed 'soundmodem' on a Raspi, to my amazement it could read from file, but Raspi has no sound in. So I hope those USB sticks will add sound in to it. Done some wild things with Raspi; sound out, like generating the AX25 test signals for the HUD PIC, while using the same Raspi as PIC programmer, and 3 or 4 ssh sessions to it, one for editing / writing asm, once to assemble asm, one with my communication program 'ptlrc' and USB to serial adaptor to see the PIC RS232 output, All that remote from an other area, 3 or 4 xterms (rxvt actually) just had to go there in the morning to switch things on. Reliable little things, those Raspis. Just imagine, program your PIC and test it from anywhere in the world...

What is openocd?

Jtag software, mainly for linux but with windows also supported.

As well as stand-alone programming of flash images and examining the target, it can act as a gdb server so gdb can talk to hardware. You can single-step lines of C, examine variables (even while running in case of CM3) etc.

I thought you knew about it, I believe it can use the rPi PIOs turning the rPi into a jtag server, or you can run gdb on the rPi too so it becomes a complete development system. (For code that will ultimately run on a the stand-alone microcontroller).

--

John Devereux

On a sunny day (Thu, 03 Oct 2013 19:15:05 +0100) it happened John Devereux wrote in :

Yes, now I remember I did look at that some years ago.

I have not used gdb in many years, never use a debugger..... Printf is my friend, after all asm and C are high level languages [1]. First code I put together on a new micro is some serial out so I can print numbers and register values. I do not understand why people need debuggers... Or ICE.

I use Raspi as JTAG FPGA programmer:

for Xilinx bit files... I did write or play with some JTAG stuff myself, mainly based on what others already wrote;

[1] Others may disagree, but hey I started writing code as binary numbers and entering it with dip switches programming byte by bye in an EPROM. In those times, then later I wrote a debugger: and then I found I no longer needed one.

Oh I do that too, I find both methods have their uses.

I found a couple of nice things with it recently (with openocd). You can show variables (or a large structure/array) without stopping the program, so you can monitor what is going on in a complicated system if you have arranged things appropriately.

And I found a extension which uses the built-in python (I think) to pipe arrays through gnuplot, so I get a nice high resolution plot on the PC of a processed waveform, from a ADC output array say.

But you can just use openocd it as the flash programmer if that is all you need, take the linker output file and program it into flash.

--

John Devereux

People are biased by what they know. I haven't messed with a microcontroller for about 30 years, so as rediculous as it seems, I can't help but to compare new technology to 8048's. I know better but I still think of a PIC as being like a glorified EPROM or programmable logic array. I think of a PIC as being more reflex like than processor like. If I understand it correctly, PIC processors are cheaper and better for something that needs instant reflexive response to conditions. Will the more powerful general purpose processors become cheap enough and fast enough to compete with the cheap reflexive function of PIC's?

There isn't much new under the sun, no.

PICs are simply a brand/architecture of uCs. They span a pretty broad spectrum of the uC market, from the bottom of the bottom, into the midrange in power and cost. It really is a pretty crude architecture, at that.

Certainly I've used PLAs to emulate a uC (management had their panties in a twist about uCs) but they really aren't the same at all, any more than memory and logic gates are the same.

"Reflex like"?

PICs *ARE* processors. Some are quite high on the food chain.

Please explain. What do you mean by "reflexive response"?

It's all about cost, power, and speed. Pick where you want to be on those axis. IMO, PICs only make sense at the extreme low end of the first two, if there.

The main differences between uPs back in the day, and uCs and SoCs today, is the architecture and the hardware (...duh?).

Architectures range from 4 bits (yes, such beasties are still around; mainly for stuff like remote controls) to 32 bits (there may be 64 bit embedded processors, I haven't really heard of any though?).

8 bit architectures have never disappeared; anywhere you need just a little leverage, they're great. See Arduino (AVR8), PIC (the lower models), etc.

16 bit gives more bandwidth, which gives you a little more speed, but not so much for book-keeping activities. MSP430, PIC18 (I think?) and others.

32 bit is very common for slightly more powerful activities, up to freaking browser cell phones (pipelined multicore ARMs at GHz). See Raspberry Pi, among many others.

Architectures range from single cycle instructions to old, slow instruction sets. Even the 8051s are fast (single or a few cycles per instruction) these days (the original ISA was something like 12 cycles per instruction, wasn't it?). Heck, Z80 is still around (though I don't know that anyone really uses it). Most uCs are RISC (load-store), so the instructions are fast but you need more of them. Some are CISCier (HC11 for example), but slower too.

The biggest difference from the olden days is the lack of a [parallel] bus, and the inclusion of every kind of hardware you ever needed. Instead of a Z80-CPU, EPROM, SRAM, CTC, SIO and PIO, and more chips (or the equivalents for a 6502, or 68k, or..), you get all of it in one chip. Much less expandable (in the classical sense of plug-in boards), but also easier to use.

So if you want to compare with 8048 days, things are faster, and most everything is at your fingertips, integrated. Beyond that, things aren't much different... computers are still computers. You'll see Harvard and Von Neumann schemes (one or several address spaces), which necessitate special instructions or control registers for certain operations. (AVR for instance has a FLASH program space with 16 bit (or more) addressing,

16 bit width, plus the general I/O bus with 16 bit addressing, 8 bit width. DSP chips typically have multiple address spaces, so that instructions, data source 1, data source 2, and output operands are available within a single fell swoop of one clock cycle.)

In another thread, someone brought up Intel's offering in the dev board market. As far as I know, Intel has never made an attempt to really support embedded applications -- that is, an all-in-one solution. Back in the day, Z80 and etc. were great because the bus was simple: you could run the chip from a clock oscillator, connect its bus to EPROM and some latches, and blink LEDs just that easily -- try the same with an 8086 and you need a clock generator and a bus interface, minimum. Supposedly,

80186s saw some embedded use (I've never seen one myself, so I don't know). So, if you're building a PC, northbridge, DRAM, all that, Intel has always been great, but for minimal implementations, they haven't shown interest there.

Tim

--
Seven Transistor Labs 
Electrical Engineering Consultation 
Website: http://seventransistorlabs.com 

 wrote in message  
news:rlst49tnbjqr5h425pi8ro4kr0vlmgvkms@4ax.com... 
> On Fri, 4 Oct 2013 09:43:13 -0700 (PDT), Greegor  
> wrote: 
> 
>>People are biased by what they know. 
>> 
>>I haven't messed with a microcontroller 
>>for about 30 years, so as rediculous as 
>>it seems, I can't help but to compare 
>>new technology to 8048's. 
> 
> There isn't much new under the sun, no. 
> 
>>I know better but I still think of a 
>>PIC as being like a glorified EPROM 
>>or programmable logic array. 
> 
> PICs are simply a brand/architecture of uCs.  They span a pretty broad 
> spectrum of the uC market, from the bottom of the bottom, into the 
> midrange in power and cost.  It really is a pretty crude architecture, 
> at that. 
> 
> Certainly I've used PLAs to emulate a uC (management had their panties 
> in a twist about uCs) but they really aren't the same at all, any more 
> than memory and logic gates are the same. 
> 
>>I think of a PIC as being more 
>>reflex like than processor like. 
> 
> "Reflex like"? 
> 
> PICs *ARE* processors.  Some are quite high on the food chain. 
> 
>>If I understand it correctly, PIC 
>>processors are cheaper and better 
>>for something that needs instant 
>>reflexive response to conditions. 
> 
> Please explain.  What do you mean by "reflexive response"? 
> 
>>Will the more powerful general purpose 
>>processors become cheap enough and 
>>fast enough to compete with the 
>>cheap reflexive function of PIC's? 
> 
> It's all about cost, power, and speed.  Pick where you want to be on 
> those axis.  IMO, PICs only make sense at the extreme low end of the 
> first two, if there. 
>

The earliest PICs (and some of the architecture of much of the lower-end line) may even precede the 8048 (I'm talking about the PICs from the pre-Arizona Microchip GI days).

They both started as modified Harvard-architecture chips made in n-MOS in the mid 1970's. The PICs became CMOS, added capabilities and gained popularity as one of the first affordable programmable chips. The 8048 rapidly begat the 8051 which is also still around as individual chips and SOC cores.

The 8048 was more advanced than the first PIC chips- it actually had an interrupt input!

Anyway, if I understand your question- bit diddling type stuff can be slower if there's an operating system in the middle. People these days often demand their processor run a touch screen, talk USB host and TCP/IP over Ethernet or WiFi, etc. That's easiest done with something like Linux, QNX etc. Often there's hardware on the more powerful chips (and sometimes less powerful ones) to do things like read a quadrature encoder or PWM a 3-phase motor. If your application doesn't fit one of the canned peripherals and the processsor + O/S doesn't make the grade, you can add a chip to deal with it (logic, FPGA, microcontroller etc.). If you want to JUST do bit diddling stuff, I think a 120MHz ARM programmed in C is going to beat a 4MHz (1 MIPS) PIC programmed in assembly language any day of the week, barring pathological cases. In assembly language, a PIC can probably toggle an output port pin faster as a percentage of MIPS (because there is more stuff going on in the ARM internal busses), but that's not a very useful metric.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward" 
speff@interlog.com             Info for manufacturers: http://www.trexon.com 
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

The 80186/8 was converted into a uC because it couldn't (easily) be used for the PC market. I you think that Intel was never in the uC market, obviously you're forgotten the 8048 and 8051.

Oh, they're clearly interested in this market. They've bought enough lunches to show that. ;-) Indeed, Intel is trying to get back into this market but IMO, they're having trouble "getting it". Their pricing structure is gawd-awful. The PC market has rotted their brain.

They're going to get squashed by ARM in the server market now if they're not careful.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward" 
speff@interlog.com             Info for manufacturers: http://www.trexon.com 
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

They'll fight that one hard but I agree it's going to be a battle.

Thanks Spehro, those are big considerations for most apps of course. What kinds of processors are most popular in: new TV's? DVR? DVD/Blue Ray? ROKIA type video servers? clothes washers? clothes dryers? automobiles, etc? Cell Phones use mostly ARM processors right? Digital camcorders? How many Refrigerators and Air Conditioners actually use processors? Programmable thermostats use PICs right? Processors built into LiIon battery packs? These things run in nitch markets right?

One of the better sources for total industry information like this is Gartner research. The actual studies cost serious money, but they sometimes release highlights where it suits the folks who paid for it.

On the downside, they seem to ignore an entire class of Asian parts.

If you're interested, it's fun to tear down stuff and google for data. I have a couple calculators that have ARM processors (one for sure, the other one I'm 99% sure). My home CO alarms have 4000-series CMOS and PICs. Some high volume air conditioners actually have DSPs.

Not sure what you're going for here- PIC is a brand covering a fairly broad range microcontroller made by one particular company (or maybe you could count clones of them too). Everything from quite rudimentary

8-bit processors to MIPS-based 32-bit cores. Some simple thermostats probably do use them.

At least one programmable thermostat uses a rather powerful ARM A8

32-bit processor, probably running at 600MHz~1GHz.

Depending on how you define niche and market, it could be.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward" 
speff@interlog.com             Info for manufacturers: http://www.trexon.com 
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

On the contrary: what's the point of writing in C, if you can use C++? You can even compile your precious C code with a C++ compiler and it should work like a charm. Cheaper stone age developers, perhaps? :-)

Best regards, Piotr

You snipped too much context there...especially given you are replying to a 32 week old message!

I was replying to Jan, well known c++ hater and C programmer.

I have no problem using c++ for embedded.

Well, actually, that is untrue. I have a big problem with it because c++ is a very complicated language and I do not know it well enough yet. But it is clear to me that a sufficiently clever person could write superior code with it.

As long as you start out the project doing that, I agree.

--

John Devereux

Funny you should ask - The "IOT" Internet of Things, has the HW mfrs with their tongues hanging out. Now take your refrigerator. Do you ever have food in there you forget about? Well, what you need is a wireless tag system to have those storage containers yell for attention after a certain time lapse. Can't find an item in there? Well, just push a button and the hidden item lights up. Food management is handled by a cpu in a main IOT link to the network, maybe. And of course there is the issue of temperature in there. Most fridges are too hot, I am told. You may even have a "Federal Nutrition Nanny" to scold you about your lack of vegetables, but I jest, I hope.