PIC versus AVR

On Friday, in article
     <R1KAg.111634$wl.20205@text.news.blueyonder.co.uk>
     nospam@thanks.com "FreeRTOS.org" wrote:

>> with some 7 servers and over 250 workstations around the school. Scanners,
>
>This is a private school then, right?

Yes, but state schools are not that dissimilar as this includes administartion
and staff systems as well.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

Paul Carpenter wrote:

> Come acros this problem often as the other half (SWMBO) runs a school network
> with some 7 servers and over 250 workstations around the school. Scanners,
> and digital cameras can be the worst culprits for wanting to create their
> wonderful 'albums' and catalogues in the program directory. Then you can
> get printers that want to create their own print spooler and need a directory
> for it, usually under the program directory and you cannot change it.

At least the diags tools are better now. I used to be the lead
programmer on a product called pcLockout (the company is now defunct).
The school version of this product, which worked on DOS, Win3.x and
Win95/98, had as one of its major features the ability to write-protect
the hard disk at the int 21h, int 13h and int 26h levels. (I also wrote
a VxD that hooked the file I/O functions to do the file-level
protection in Win9x without compromising 32BFA).

The software those people used wanted all sorts of things to be
writable; it was a REAL bear to get even CD-ROM software working.
Before I came to the company, the schools would send us copies of the
malfunctioning applications and the support guy would sit down and
figure out what it was trying to write, then we'd tell the school what
filespecs to put in the wildcard list.

The best thing I ever did was to build some slightly clever code that
would log file write accesses to a text file (this is nontrivial in
DOS, because int 21h is not reentrant, and TSRs on top of it usually
aren't either!). Another programmer later wrote a program that parsed
the log file and automatically made some best guesses at which files
needed to be put in the exception (always-writable) list.

Since you can't write-protect the registry in Win9x, we did some exotic
backup and restore stuff on those files.

Oh, those were the good old days, to be sure.

> I stay as far away from Windows as I can, so I can't say that I've
> looked deep enough at AVR Studio to answer your question. But I can say
> that the Atmel team appears to be trying harder than the Microchip folks
> at providing development tools. And unlike Microchip its actually
> practical to code and debug an AVR without Windows.

That's good; that means they're aware of PC operating systems.  If they 
support two, they'll probably support *both* of them better than if they had 
only supported one, because every OS opens your eyes to important 
characteristics of other OSes.

> AVR-gcc is a very good compiler. The packager of WinAVR (avr-gcc for
> Windows) is now an Atmel employee. See above about "trying harder."

That also sounds like a very good move.  gcc of course has a long reputation 
for high reliability.

> I realize in an academic environment at least one stage of the learning
> process one stays limited to assembler. Once students get used to
> assembler it can be enlightening for them to study the output of a C
> compiler. I looked a lot at the output of avr-gcc. It never wrote
> assembly that I could improve enough to justify the effort to rewrite in
> assembly. Once or twice I changed a C expression for better assembly
> output.

Yes... this is how you learn what a compiler does.

"steve" <bungalow_steve@yahoo.com> wrote in message 
news:1154666721.211509.298520@i42g2000cwa.googlegroups.com...

> A common core is not too helpful as modern high level languages already
> makes all cores "psuedo common" (except for timing).
>
> I rather have common memory maps, peripheral interfaces, electrical
> characteristics and common pinouts with different cores, this way I
> could just recompile...

It would have been nice if AVR and PIC 8-pin micros had had the same pinout, 
so they could really fight it out in the marketplace!

>> 62-character length limit on the full path to the file.  Does AVR Studio 
>> cooperate fully with normal Windows security practices, or does it, too, 
>> require you to loosen security on the computer in order to run it?
>
> Are you forced to install in C:\Program Files, or do you mean, you must 
> have write permissions to the EXE host directory ?
> ( which is slack of them, if true )

The latter.  Microchip MPLAB requires you to have write permissions in 
something under C:\Program Files, presumably its own directory.  I don't 
know what it writes there, or whether different users of the same computer 
will disrupt each other.  In order to use MPLAB we have to loosen security 
on our computers by letting all users write in that directory.

>>Are you forced to install in C:\Program Files, or do you mean, you must
>>have write permissions to the EXE host directory ?
>>( which is slack of them, if true )
>
> Unfortuntely most of the vendor apps are written by PC applications
> programmers, who assume everybody is on a STANDALONE PC! Programmes that
> force storing of project details into the installed programme directory
> are the NORM not the exception. Very few have network deployment methods.
>
> I would not surprised if the apps want to write all sorts of files in 
> their
> installed directory and not into a project directory.

And I call that inept application programming.  Microsoft has been 
recommending against it for, what, 6 years or more?

> As the original poster was talking about a univerity type lab which would 
> be
> on a university network, with all sorts of restrictions such as users 
> cannot
> install programmes and their work is over the network so their "My 
> Documents"
> is actually on a server, along with the user portion of registry. Often in
> these situations the user has no write access directly to local drives! 
> Nor
> would I wnt to is some eductaion establishments.

Exactly!  In ours, the user can make a directory of his own on C: and write 
in it, but if he does, his files will not roam with him to the next computer 
he logs in on.  If we were more fastidious we'd disallow writing on C: 
altogether, except for the area containing the user's copied profile.

The thing is, UNIX programmers have known for nearly 30 years that ordinary 
users aren't supposed to write in directories other than /home/username (or 
what have you).

"larwe" <zwsdotcom@gmail.com> wrote in message 
news:1154701706.388096.214640@p79g2000cwp.googlegroups.com...

>> > MSP430 - 16-bit, high performance, low power, von Neumann architecture.
>> > VERY easy to work with. Code compatibility between parts is superb.
>> > However, relatively expensive and not many devices in the family.
>>
>> Ah!  Didn't realize it was Von Neumann.  Hmmm...  A lot of what I do is
>
> It's very von Neumann. Even the in-program-rewritable "EEPROM" (it
> isn't EEPROM) area is mapped straight into the normal memory map, not
> the usual address/data registers found in other parts. It's very easy
> to use.

Easy for a COMPILER to use, in particular, I'll bet!

>> precision timing of one kind or another, and the ability to count to 
>> 65535
>> might be useful.
>
> The MSP430 is quite rich in timer and capture/compare goodies. If you
> want to play with it, invest in the $20 ez430 demo/development kit;
> this is a full debugger with a small target board (2K flash).

Right -- we were just talking about how to hack the ez430 to also program 
DIP versions of the chip.  Small matter of finding a connector with the pins 
0.05 inch apart...

> The 2K target is inside the 4K limit of the free C compiler provided
> with the kit, so you can work in asm or C (or even C++) according to
> your particular fetish.

C++?  Now what I'd like to see is a microcontroller subset of C#... clearly 
the whole C# language is not appropriate, but it ought to be able to extract 
a Pascal-like subset for expressing algorithms on small CPUs.

>> > Well, gee, I only just finished writing several thousand words on the
>> > topic... here's the dime version:
>>
>> Previous postings here, or something else?  I'd be glad to read it if 
>> you've
>> made a web site or something...
>
> Both. There was a long thread in this NG recently, I think the title
> was something like "about the MSP430", and we got into pros and cons of
> these three architectures. Some very detailed stuff in there, IIRC from
> Senor Kirwan.

Thanks.  I just found your web site and realized who you are.  I read your 
shoestring book quickly a while back and enjoyed it.  I'm a book author 
myself (www.covingtoninnovations.com/books.html) but not in this exact 
field. (Yet! :)

All this is very useful.  Thanks for posting it.

Wilco Dijkstra wrote:

> "Jim Granville" <no.spam@designtools.co.nz> wrote in message 
> news:44d309c7$1@clear.net.nz...
> 
>>FreeRTOS.org wrote:
>>
>>
>>>>Except they aren't really multi-source.  For example, you're
>>>>using an ARM single-chip solution from vendor A.  It's not like
>>>>there's a drop-in replacement part from Vendor B: the
>>>>peripherals are all different from one source to th next.
>>>>Since all the work is in dealing with the peripherals, I find
>>>>almost zero benefit in switching to a second source with the
>>>>same core but a different set of peripherals.
>>>
>>>This will change with the ARM Cortex-M3.  Standard peripherals and 
>>>standard memory map.  Of course a vendor can choose to ignore the 
>>>standard if they so wish.
> 
> 
> No, the standard M3 peripherals such as the interrupt controller/
> timer/profiler/breakpoint unit are defined by ARM and cannot be
> changed. Neither can the memory map. Due to this there is almost
> no need in porting RTOSes, debuggers etc when moving between
> different devices.
> 
> Other peripherals like UARTs are not standardised. The major MCU
> manufacturers already have their own, so there is little chance of
> standardisation.
> 
> 
>>... and they may wish to do that, as the Cortex peripherals are rather 
>>'ordinary/below par' for a new 32 bit core offering :
>>
>> No Up/Down or quadrature modes, and only 16 bit capture ?
>>PWM edge resolution is only = Core clk speed, 4Mhz spi speed... ?
> 
> 
> These are Luminary peripherals. The Cortex-M3 peripherals are
> described in the TRM. You can add more peripherals but you
> can't change/remove the standard ones.

  Just to clarify, what you call standard peripherals, is then the 
interrupt controller/timer/profiler/breakpoint unit
[Rather like the MDI potion of the ARM7TMDI standard ? ]
( and timer here is part of profiler, not a generic timer ? )

- what most uC users would call peripherals, like 
ADC/UART/CaptureCompare/UpDnCounters/PWM,
are all "not standardised" ?

  I'm not sure how you can make different sizes of RAM and CODE, and
NOT change the memory map, but perhaps you meant 'base addresses' or 
similar ?

-jg

On 4 Aug, in article
     <1154718657.221610.283880@b28g2000cwb.googlegroups.com>
     zwsdotcom@gmail.com "larwe" wrote:

>Paul Carpenter wrote:
>
>> Come acros this problem often as the other half (SWMBO) runs a school network
>> with some 7 servers and over 250 workstations around the school. Scanners,
>> and digital cameras can be the worst culprits for wanting to create their
>> wonderful 'albums' and catalogues in the program directory. Then you can
>> get printers that want to create their own print spooler and need a directory
>> for it, usually under the program directory and you cannot change it.
>
>At least the diags tools are better now. I used to be the lead
>programmer on a product called pcLockout (the company is now defunct).
>The school version of this product, which worked on DOS, Win3.x and
>Win95/98, had as one of its major features the ability to write-protect
>the hard disk at the int 21h, int 13h and int 26h levels. (I also wrote
>a VxD that hooked the file I/O functions to do the file-level
>protection in Win9x without compromising 32BFA).
>
>The software those people used wanted all sorts of things to be
>writable; it was a REAL bear to get even CD-ROM software working.

There is a lot of stuff written for/by supposedly big and reputable companies
that is a pile of crock.

>Before I came to the company, the schools would send us copies of the
>malfunctioning applications and the support guy would sit down and
>figure out what it was trying to write, then we'd tell the school what
>filespecs to put in the wildcard list.

Seen a similar thing on Fortress 101, used to lock down a PC running
Win9x at a hotel so that the night staff did not visit websites and
install all sorts of things. It looks like at another of the hotels
in the group I may have to do the same thing as they have problems
with itchy fingers and download anything staff, especially at night.

>The best thing I ever did was to build some slightly clever code that
>would log file write accesses to a text file (this is nontrivial in
>DOS, because int 21h is not reentrant, and TSRs on top of it usually
>aren't either!). Another programmer later wrote a program that parsed
>the log file and automatically made some best guesses at which files
>needed to be put in the exception (always-writable) list.
>
>Since you can't write-protect the registry in Win9x, we did some exotic
>backup and restore stuff on those files.
>
>Oh, those were the good old days, to be sure.

Personally if more systems had lock downs on them, there would be LESS
problems and in a lot of organisations, it would not be buy it and sort
problems out later, over time most people would get to learn that it has
to be tested to ensure it will work OK.

By lockdowns I do not mean the poor attempt on Windows to have workstation
user/permissions, that is nearly always circumvented as all users have
to have LOCAL administrator rights for the crap applications to run.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate