Discussion:
[EE] AVR micros
David C Brown
2017-10-09 09:45:28 UTC
Permalink
Probably not the ideal place to ask but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.

I would be using their eight bit devices and programming in assembler. And
would want development aids equivalent to MPLAB8 and ICD2.

Could anyone give me any direct advice on getting started or direct me to
the better of the overwhelming number of web resources?



__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
Derbyshire eMail: ***@gmail.com
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>



*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
James Cameron
2017-10-09 10:10:33 UTC
Permalink
I'm just starting into using http://platformio.org/ which can be used
a plugin for the http://atom.io/ editor by GitHub. It should be
possible with PlatformIO to code for both Atmel AVR, Atmel SAM, and
Microchip PIC32 in the same source file at the same time. It is
mostly open source, so easy to find out how specific platforms or
boards were added, just by looking through the version control
history. I don't know how equivalent these are to MPLAB8 and ICD2
though. The unified debugger is a priced service, see
http://platformio.org/pricing
Post by David C Brown
Probably not the ideal place to ask but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.
I would be using their eight bit devices and programming in assembler. And
would want development aids equivalent to MPLAB8 and ICD2.
Could anyone give me any direct advice on getting started or direct me to
the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
James Cameron
http://quozl.netrek.org/
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Van Horn, David
2017-10-09 13:08:56 UTC
Permalink
AVR Studio has always been my tool of choice. The Jtag Ice is very useful, but not essential.
I think you'll find it a refreshing departure from the PIC. I started using the AVRs back when the 8515 was new, and never did PIC development again.




Could anyone give me any direct advice on getting started or direct me to the better of the overwhelming number of web resources?



__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
Derbyshire eMail: ***@gmail.com
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>



*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Denny Esterline
2017-10-09 14:07:19 UTC
Permalink
I'm still deeply invested in PICs and not ready to jump ship yet.
If/when that time comes for me, I don't think I'd be looking at any 8-bit
part families.
So many parts have been introduced with _much_ more performance and in many
cases a lower price point.

ARM is starting to catch my attention...


-Denny




On Mon, Oct 9, 2017 at 6:08 AM, Van Horn, David <
Post by Van Horn, David
AVR Studio has always been my tool of choice. The Jtag Ice is very
useful, but not essential.
I think you'll find it a refreshing departure from the PIC. I started
using the AVRs back when the 8515 was new, and never did PIC development
again.
Could anyone give me any direct advice on getting started or direct me to
the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at http://mailman.mit.edu/
mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Jason White
2017-10-09 14:41:09 UTC
Permalink
I'd say overall my experience learning ARM has been worthwhile. Of course
I've mostly been working in C.

Comparing the instruction sets, personally, I'd rather write ARM assembler
than PIC. Perhaps ARM has more instructions and more registers (and a
"lengthy" 32-bit word size). But, I'd consider that more of a blessing than
a curse.
Post by Denny Esterline
I'm still deeply invested in PICs and not ready to jump ship yet.
If/when that time comes for me, I don't think I'd be looking at any 8-bit
part families.
So many parts have been introduced with _much_ more performance and in many
cases a lower price point.
ARM is starting to catch my attention...
-Denny
On Mon, Oct 9, 2017 at 6:08 AM, Van Horn, David <
Post by Van Horn, David
AVR Studio has always been my tool of choice. The Jtag Ice is very
useful, but not essential.
I think you'll find it a refreshing departure from the PIC. I started
using the AVRs back when the 8515 was new, and never did PIC development
again.
Could anyone give me any direct advice on getting started or direct me to
the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at http://mailman.mit.edu/
mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
Jason White
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
mike brown
2017-10-09 15:56:02 UTC
Permalink
I cheated and moved to the Arduino stuff several years ago, but I'm one
that believes that you can be just as efficient in C as assembler if you're
careful and pay attention. In my meager experience, the 8 bit PIC is by
far the ugliest environment ever conceived, but it has it's place when
ruggedness, power efficiency and cost are the driving factors. I don't
regret the many hours of hair pulling and constant tedious struggle that
working with them was. I learned a lot.

AVR assembly language seems to be quite luxurious compared to PIC.
ARM7/Cortex takes that to a new level. JTAG debugging is a godsend to
solving problems, it's so much more informative than wiggling an IO pin.

I love low level work, but now that I'm 55 I want to spend more time
accomplishing bigger things than figuring out why I have 1-3uS jitter when
writing to the timer in an ISR before I die. OCD has it's downside.

Right now my favorite tinker toy is the ESP8266. I'm just a hobbyist.
Post by Jason White
I'd say overall my experience learning ARM has been worthwhile. Of course
I've mostly been working in C.
Comparing the instruction sets, personally, I'd rather write ARM assembler
than PIC. Perhaps ARM has more instructions and more registers (and a
"lengthy" 32-bit word size). But, I'd consider that more of a blessing than
a curse.
Post by Denny Esterline
I'm still deeply invested in PICs and not ready to jump ship yet.
If/when that time comes for me, I don't think I'd be looking at any 8-bit
part families.
So many parts have been introduced with _much_ more performance and in
many
Post by Denny Esterline
cases a lower price point.
ARM is starting to catch my attention...
-Denny
On Mon, Oct 9, 2017 at 6:08 AM, Van Horn, David <
Post by Van Horn, David
AVR Studio has always been my tool of choice. The Jtag Ice is very
useful, but not essential.
I think you'll find it a refreshing departure from the PIC. I started
using the AVRs back when the 8515 was new, and never did PIC
development
Post by Denny Esterline
Post by Van Horn, David
again.
Could anyone give me any direct advice on getting started or direct me
to
Post by Denny Esterline
Post by Van Horn, David
the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at http://mailman.mit.edu/
mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
Jason White
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
RussellMc
2017-10-10 00:08:40 UTC
Permalink
​ ... ​
In my meager experience, the 8 bit PIC is by
far the ugliest environment ever conceived, but it has it's place when
ruggedness, power efficiency and cost are the driving factors.
​Blessed are they who have never dealt with the Fairchild F8.
Weird and wonderful were its ways and there is, hopefully, a special place
for it in outer darkness where it may weep and wail, if not actually gnash
its teeth.

DATASHEET http://datasheets.chipdb.org/Fairchild/F8/fairchild-3850.pdf
http://www.textfiles.com/bitsavers/pdf/fairchild/f8/
Fairchild_-_F3850_Central_Processing_Unit_datasheet_-_1982.pdf

Peripherals http://seanriddle.com/fairchild%20micromachine.pdf

https://wiki2.org/en/Fairchild_F8

http://www.cpushack.com/2013/06/08/cpu-of-the-day-
fairchild-f8-microprocessor/
_______________________

The 1974 introduced NatSemi Scamp aka SCMP aka SC/MP aka ISP-8A/600 ... is
less weird than the F8 and actually quite nice to use, but still rather
strange.
Not many, but marginally enough registers that one COULD buidl a simple
system with no RAM, and someone here did, and a friend of mine had to pick
up the project after the miscreants moved on and try to support an expand a
RAMless system.

Technical description 67 pages

http://www.dos4ever.com/SCMP/SCMP_Technical_Description_Jan76.pdf
https://archive.org/details/bitsavers_nationalscicalDescriptionJan76
_8300762

20 datasheet pages as gifs http://searle.hostei.com/grant/SCMP/index.html

SCMP + NIBL BASIC http://www.dos4ever.com/SCMP/SCMP.html

*Wikipedia*: https://wiki2.org/en/National_Semiconductor_SC/MP
https://wiki2.org/en/National_Semiconductor_SC/MP
he SC/MP was also used as the basis of a single board microcontroller
produced by Science of Cambridge (later Sinclair Research Ltd
<https://wiki2.org/en/Sinclair_Research_Ltd>) called the MK14
<https://wiki2.org/en/MK14>. Montgomery Elevator
<https://wiki2.org/en/Montgomery_Elevator> Co of Moline IL (later purchased
by KONE, Inc <https://wiki2.org/en/KONE,_Inc>) used the SC/MP as the basis
for its first micro processor based elevator controller released in 1975.
There are still many of these units running in buildings across the U.S.A.

______________________


The PIC grew from an early ?GE? NMOS processor that was slightly more
arcane.

_____________________

The MC14500B "1 bit" processor was "rather arcane".
Here is my description of it in my "moment of glory" Jack Ganssle "Embedded
Muse" newsletter in 2008, pages 5 & 6

MC14500B datasheet <http://www.ganssle.com/misc/mc14500datasheet.pdf>

_____________

From: Embedded muse 157 pages 5-6 <http://bit.ly/mc14500b_p5-6>

Russell McMahon submitted: The all time most terrible and
narrowest bus width

"microprocessor", assuming such an exalted title dare be applied, and
assuming that there

has never been a none-bit processor, although any number of mine have
assumed that

apparent state over the decades, was the dread Motorola 14500 "1 bit"
microprocessor.



A perfunctory web search, employing effort worthy of such a device, turns
up a number

of references but neither data sheet, nor seller willing to admit stocking
them.



From memory they achieved their claim to 1 bit status fame by having an
execution unit

which returned a binary true/false when various (and necessarily limited)
tests and

operations were carried out. Presumably (and memory dimly suggests) the
obvious

AND/OR/XOR and I seem to recall a TAD or ADD. The outcome of a test would
enable

or disable the execution of subsequently fetched instructions and the
device would chug

oh so slowly up its memory until some text condition was met, whereupon the
instruction

decoding was reenabled and execution recommenced. All program locations were

ALWAYS accessed sequentially as an endless loop with program flow including
any

conditional jumps being achieved by turning off execution, meandering
through address

space and then reenabling execution when the relevant test of condition
produced a true

result.



From dim recollection, the title "1-bit" was a misnomer as you effectively
built tests of a

width that suited externally using such hardware as requisite.



I never used the device but spent some hours with friends poring over data
sheets

attempting to identify a way in which it could be sensibly and economically
used. As we

never discovered one we were never among the buyers of the 10 or so devices
that I

imagine they sold in this country.



And, when was this? I'd guesstimate, based on other memory cues, about
1981-1982,

although that seems rather late in considering the general state of the art
by then.



RIP 14500


Copyright 2003 by The Ganssle Group. All Rights Reserved. You may
distribute this for

non-commercial purposes. Contact us at ***@ganssle.com for more
information.

The Ganssle Group, www.ganssle.com
<https://mail.google.com/mail/u/0/www.ganssle.com>





--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mai
mike brown
2017-10-10 01:05:09 UTC
Permalink
Anyone ever use a CDP1802? Try as he did, Tom Pittman with his Short
Course on Programming just could not get me to wrap my head around the X
register, interrupts and DMA. Seems so simple now. It didn't help that
I'd put a transistor in backwards when building the RF modulator resulting
in the instant demise of the 1861 "video" device leaving me with no ability
to display something on a TV screen, crude though it may be.

RCA had a great book showing what happened with each instruction, wish I'd
kept it. I still have my COSMAC Elf II though, and I believe it still
works.

Today it has a cult following of youngsters that find some twisted
entertainment value by fabricating replicas of those early personal
computers using emulators and CPLDs (FPGAs?).
Post by RussellMc
​ ... ​
In my meager experience, the 8 bit PIC is by
far the ugliest environment ever conceived, but it has it's place when
ruggedness, power efficiency and cost are the driving factors.
​Blessed are they who have never dealt with the Fairchild F8.
Weird and wonderful were its ways and there is, hopefully, a special place
for it in outer darkness where it may weep and wail, if not actually gnash
its teeth.
DATASHEET http://datasheets.chipdb.org/Fairchild/F8/fairchild-3850.pdf
http://www.textfiles.com/bitsavers/pdf/fairchild/f8/
Fairchild_-_F3850_Central_Processing_Unit_datasheet_-_1982.pdf
Peripherals http://seanriddle.com/fairchild%20micromachine.pdf
https://wiki2.org/en/Fairchild_F8
http://www.cpushack.com/2013/06/08/cpu-of-the-day-
fairchild-f8-microprocessor/
_______________________
The 1974 introduced NatSemi Scamp aka SCMP aka SC/MP aka ISP-8A/600 ... is
less weird than the F8 and actually quite nice to use, but still rather
strange.
Not many, but marginally enough registers that one COULD buidl a simple
system with no RAM, and someone here did, and a friend of mine had to pick
up the project after the miscreants moved on and try to support an expand a
RAMless system.
Technical description 67 pages
http://www.dos4ever.com/SCMP/SCMP_Technical_Description_Jan76.pdf
https://archive.org/details/bitsavers_nationalscicalDescriptionJan76
_8300762
20 datasheet pages as gifs http://searle.hostei.com/grant/SCMP/index.html
SCMP + NIBL BASIC http://www.dos4ever.com/SCMP/SCMP.html
*Wikipedia*: https://wiki2.org/en/National_Semiconductor_SC/MP
https://wiki2.org/en/National_Semiconductor_SC/MP
he SC/MP was also used as the basis of a single board microcontroller
produced by Science of Cambridge (later Sinclair Research Ltd
<https://wiki2.org/en/Sinclair_Research_Ltd>) called the MK14
<https://wiki2.org/en/MK14>. Montgomery Elevator
<https://wiki2.org/en/Montgomery_Elevator> Co of Moline IL (later purchased
by KONE, Inc <https://wiki2.org/en/KONE,_Inc>) used the SC/MP as the basis
for its first micro processor based elevator controller released in 1975.
There are still many of these units running in buildings across the U.S.A.
______________________
The PIC grew from an early ?GE? NMOS processor that was slightly more
arcane.
_____________________
The MC14500B "1 bit" processor was "rather arcane".
Here is my description of it in my "moment of glory" Jack Ganssle "Embedded
Muse" newsletter in 2008, pages 5 & 6
MC14500B datasheet <http://www.ganssle.com/misc/mc14500datasheet.pdf>
_____________
From: Embedded muse 157 pages 5-6 <http://bit.ly/mc14500b_p5-6>
Russell McMahon submitted: The all time most terrible and
narrowest bus width
"microprocessor", assuming such an exalted title dare be applied, and
assuming that there
has never been a none-bit processor, although any number of mine have
assumed that
apparent state over the decades, was the dread Motorola 14500 "1 bit"
microprocessor.
A perfunctory web search, employing effort worthy of such a device, turns
up a number
of references but neither data sheet, nor seller willing to admit stocking
them.
From memory they achieved their claim to 1 bit status fame by having an
execution unit
which returned a binary true/false when various (and necessarily limited)
tests and
operations were carried out. Presumably (and memory dimly suggests) the
obvious
AND/OR/XOR and I seem to recall a TAD or ADD. The outcome of a test would
enable
or disable the execution of subsequently fetched instructions and the
device would chug
oh so slowly up its memory until some text condition was met, whereupon the
instruction
decoding was reenabled and execution recommenced. All program locations were
ALWAYS accessed sequentially as an endless loop with program flow including
any
conditional jumps being achieved by turning off execution, meandering
through address
space and then reenabling execution when the relevant test of condition
produced a true
result.
From dim recollection, the title "1-bit" was a misnomer as you effectively
built tests of a
width that suited externally using such hardware as requisite.
I never used the device but spent some hours with friends poring over data
sheets
attempting to identify a way in which it could be sensibly and economically
used. As we
never discovered one we were never among the buyers of the 10 or so devices
that I
imagine they sold in this country.
And, when was this? I'd guesstimate, based on other memory cues, about
1981-1982,
although that seems rather late in considering the general state of the art
by then.
RIP 14500
Copyright 2003 by The Ganssle Group. All Rights Reserved. You may
distribute this for
information.
The Ganssle Group, www.ganssle.com
<https://mail.google.com/mail/u/0/www.ganssle.com>

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Harold Hallikainen
2017-10-10 01:32:59 UTC
Permalink
Post by mike brown
Anyone ever use a CDP1802?
I used to have a Sunrise Electronics ZAP-80 EPROM programmer that used the
RCA CDP1802. There was a problem with it interpreting Motorola hex files.
I visited the factory and demonstrated the issue. The hand patched the
code in hex to fix it.

I started with the Motorola MC6802. I started with hand assembly then used
a timeshare service called The Source that had an assembler. I learned to
count forward and backwards in hex to do the relative branches. Still
remember some of the hex code such as 7E for jmp, BD for gosub, 3F for
software interrupt which I used to set a breakpoint, etc.

Harold
--
FCC Rules Updated Daily at http://www.hallikainen.com
Not sent from an iPhone.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
RussellMc
2017-10-10 06:29:36 UTC
Permalink
Post by Harold Hallikainen
I started with the Motorola MC6802. I started with hand assembly then used
a timeshare service called The Source that had an assembler. I learned to
count forward and backwards in hex to do the relative branches. Still
remember some of the hex code such as 7E for jmp, BD for gosub, 3F for
software interrupt which I used to set a breakpoint, etc.
​$DD Halt & Catch Fire

Instructions very structured​
As notes elsewhere here recently - bit fields were order sequentially so
that instructions were formatted in a somewhat intuitive manner.
This was not the case with the Intel 8080.
This was NOT just a matter of octal versus hex representation but that the
8080 fields were not necessarily ordered left to right and in some cases
were split into two parts where the LSN or LS_Oct could be to the left or
right of the MSN and not contiguous.
To a machine assembler this is wholly irrelevant.
To a brain assembler this made life much harder - and even more so for a
brain dis-assembler.


R
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
William Westfield
2017-10-10 07:29:25 UTC
Permalink
Post by RussellMc
This was not the case with the Intel 8080.
This was NOT just a matter of octal versus hex representation but that the
8080 fields were not necessarily ordered left to right and in some cases
were split into two parts where the LSN or LS_Oct could be to the left or
right of the MSN and not contiguous.
Hmm. Such as? I remember the 8080 as being pretty strictly "<opclass><dest><src>” (in octal.)
(yeah, you may have to get a bit creative to interpret CCC for conditional instructions as <dest>, but I don’t remember anything as bad as I think you described. (I wrote an 8085 simulator, so I got relatively intimately involved…))

The Z80, OTOH, went and used up all the unused and nonsensical values, and did stuff with a prefix byte, so it got quite a bit uglier…

BillW
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
William Westfield
2017-10-10 07:35:51 UTC
Permalink
Post by RussellMc
Instructions very structured​
As long as we’re talking about binary instruction format elegance, I’ll mention that the AVR doesn’t have any - it looks very much as if you had some program assign values and field locations to operations and operands in the way that was most efficient to implementing the hardware. Most of the instructions don’t even have the bits of the register numbers contiguous. :-(

TI’S MSP430, OTOH, is quite pretty.

ARM is OK, but THUMB (which includes all the Cortex M chips) sucks :-( (the latter is somewhat predictable, given that Thumb is essentially what you get when sending ARM instructions through a compression algorithm with defaults.)

BillW
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclis
a***@stfc.ac.uk
2017-10-10 08:51:36 UTC
Permalink
Post by RussellMc
The 1974 introduced NatSemi Scamp aka SCMP aka SC/MP aka ISP-8A/600 ...
is less weird than the F8 and actually quite nice to use, but still rather strange.
Its most weird aspect was that it would increment the program counter then fetch the next instruction, meaning that after a reset the first executed instruction was in location 1 not 0.

I remember reading an article in Electronics magazine (now defunct I think) at the height of the 'microprocessor mania' of the early 1980s where some guy in the USA used a SC/MP to control the damper on the flue of his wood burning stove at his house somewhere deep in snow covered territory. It adjusted the damper to maintain a constant temperature for the gasses coming out the top of the flue, and once the damper was fully open and the temperature fell far enough it set an alarm to make you put more wood on the fire. I think it was my first experience of reading about a useful application for a one chip micro that was outside the normal computer realm (as in using a one chip micro for keyboard scanning etc).
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
RussellMc
2017-10-10 10:50:26 UTC
Permalink
Post by RussellMc
Post by RussellMc
The 1974 introduced NatSemi Scamp aka SCMP aka SC/MP aka ISP-8A/600 ...
is less weird than the F8 and actually quite nice to use, but still
rather strange.
Its most weird aspect was that it would increment the program counter then
fetch the next instruction, meaning that after a reset the first executed
instruction was in location 1 not 0.
6800: ​Storing eg the index register at the top address in a RAM page had
the entirely expected but often overlooked affect of corrupting the 1st
page byte. This is fundamental and trovial but was still a trap for many.

​I remember reading an article in Electronics magazine (now defunct I
think) at the height of the 'microprocessor mania' of the early 1980s where
some guy in the USA used a SC/MP to control the damper on the flue of his
wood burning stove at his house somewhere deep in snow covered territory.
It adjusted the damper to maintain a constant temperature for the gasses
coming out the top of the flue, and once the damper was fully open and the
temperature fell far enough it set an alarm to make you put more wood on
the fire. I think it was my first experience of reading about a useful
application for a one chip micro that was outside the normal computer realm
(as in using a one chip micro for keyboard scanning etc).

​I remember that article. MAY have been in Byte.
I may even have a paper copy. Somewhere :-)

Garglabets ...

This is NOT the one we both remember, but is Ciarcia controlling a
hydronics wood stove.
Byte Vol 5 no 2 1980
https://archive.org/stream/byte-magazine-1980-02/1980_02_BYTE_05-02_Graph_Theory_djvu.txt



​R

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.
Van Horn, David
2017-10-09 17:56:26 UTC
Permalink
This is the latest version:
https://www.digikey.com/product-detail/en/microchip-technology/ATATMEL-ICE/ATATMEL-ICE-ND/4753379


-----Original Message-----
From: piclist-***@mit.edu [mailto:piclist-***@mit.edu] On Behalf Of David C Brown
Sent: Monday, October 9, 2017 11:48 AM
To: Microcontroller discussion list - Public.
Subject: Re: [EE] AVR micros

Thanks

AVR studio looks attractive but my main problem is in understanding the
hardware programmers/debuggers. The JTAG ICE doesn't seem to be available
and anyway was a COM port device so not suitable. There is a ATMEL--ICE
(USB) that looks promising but there is also the cheaper Dragon which I don't really understand.. Guess it is over to the AVR forums

__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
Derbyshire eMail: ***@gmail.com
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>



*Sent from my etch-a-sketch*
Post by Van Horn, David
AVR Studio has always been my tool of choice. The Jtag Ice is very
useful, but not essential.
I think you'll find it a refreshing departure from the PIC. I started
using the AVRs back when the 8515 was new, and never did PIC
development again.
Could anyone give me any direct advice on getting started or direct me
to the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at http://mailman.mit.edu/
mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Chris McSweeny
2017-10-09 18:02:06 UTC
Permalink
I also switched from PICs to AVRs years ago - at the time I was interested
in performance in a small package and AVRs far outstripped PICs (and still
do). Initially I continued using assembler, but whilst I still have some
legacy stuff it's also a long time since I've done anything new apart from
in C.

Anyway, I have a Dragon, and it works fine for what I do - for through hole
devices it has space for a ZIF socket for programming which you patch to
the Dragon's programming pins - you can just use individual patch wires,
but I made up specific patch cables for my common use. For onboard
programming you simply patch from the programming pins to an onboard
programming connector. It does all normal forms of programming - SPI, JTAG,
PDI etc. so there's no obvious reason you'd need anything else.

Chris
Post by Wouter van Ooijen
Thanks
AVR studio looks attractive but my main problem is in understanding the
hardware programmers/debuggers. The JTAG ICE doesn't seem to be available
and anyway was a COM port device so not suitable. There is a ATMEL--ICE
(USB) that looks promising but there is also the cheaper Dragon which I
don't really understand.. Guess it is over to the AVR forums
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
On 9 October 2017 at 14:08, Van Horn, David <
Post by Van Horn, David
AVR Studio has always been my tool of choice. The Jtag Ice is very
useful, but not essential.
I think you'll find it a refreshing departure from the PIC. I started
using the AVRs back when the 8515 was new, and never did PIC development
again.
Could anyone give me any direct advice on getting started or direct me to
the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at http://mailman.mit.edu/
mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
David C Brown
2017-10-09 18:31:42 UTC
Permalink
Does it allow debugging to the same level as the microChip ICD?

__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
Derbyshire eMail: ***@gmail.com
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>



*Sent from my etch-a-sketch*
Post by Chris McSweeny
I also switched from PICs to AVRs years ago - at the time I was interested
in performance in a small package and AVRs far outstripped PICs (and still
do). Initially I continued using assembler, but whilst I still have some
legacy stuff it's also a long time since I've done anything new apart from
in C.
Anyway, I have a Dragon, and it works fine for what I do - for through hole
devices it has space for a ZIF socket for programming which you patch to
the Dragon's programming pins - you can just use individual patch wires,
but I made up specific patch cables for my common use. For onboard
programming you simply patch from the programming pins to an onboard
programming connector. It does all normal forms of programming - SPI, JTAG,
PDI etc. so there's no obvious reason you'd need anything else.
Chris
Post by Wouter van Ooijen
Thanks
AVR studio looks attractive but my main problem is in understanding the
hardware programmers/debuggers. The JTAG ICE doesn't seem to be
available
Post by Wouter van Ooijen
and anyway was a COM port device so not suitable. There is a ATMEL--ICE
(USB) that looks promising but there is also the cheaper Dragon which I
don't really understand.. Guess it is over to the AVR forums
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
On 9 October 2017 at 14:08, Van Horn, David <
Post by Van Horn, David
AVR Studio has always been my tool of choice. The Jtag Ice is very
useful, but not essential.
I think you'll find it a refreshing departure from the PIC. I started
using the AVRs back when the 8515 was new, and never did PIC
development
Post by Wouter van Ooijen
Post by Van Horn, David
again.
Could anyone give me any direct advice on getting started or direct me
to
Post by Wouter van Ooijen
Post by Van Horn, David
the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at http://mailman.mit.edu/
mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Van Horn, David
2017-10-09 18:57:03 UTC
Permalink
Not having done pics in ages, but the AVR Jtag allows you to single step, breakpoints (multiple), run to cursor, etc.
You can also examine/change any register, I/O, ram or EEPROM location on the fly.
It's very easy to change the code, reload and walk through.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Wouter van Ooijen
2017-10-09 16:06:41 UTC
Permalink
Post by David C Brown
Probably not the ideal place to ask
Why not? it is the same company :)
Post by David C Brown
but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.
It is the same company :)

My advice would be to switch to 32-bit chips and C++. Cortex-M0 chips
and modules are very cheap.
--
Wouter "Objects? No Thanks!" van Ooijen
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
smplx
2017-10-11 00:02:46 UTC
Permalink
Post by Wouter van Ooijen
Post by David C Brown
Probably not the ideal place to ask
Why not? it is the same company :)
Post by David C Brown
but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.
It is the same company :)
My advice would be to switch to 32-bit chips and C++. Cortex-M0 chips
and modules are very cheap.
the idea of using a HLL such as C++ is very appealing. Faster development,
easier maintenance, dumber programmers :-)

But let us not forget that big slow code that needs a lot of resources to
run also tends to eat more power. And somewhere deep inside all that
HLL code you are going to need someone with the skill to catch and fix low
level bugs and maintain the low / high level interface.

Reminds me of a project I came into contact with many years ago (it's
always many years now). A ton of code written in C. Lovingly crafted to be
platform independent and portable. Only thing was it ran like a dog and
ate batteries like a kid in a sweat shop. But the worst of it was it would
periodically stop sending or receiving data through the modem (chip) and
nobody had a clue how to fix it. It's all well and good providing a C
programmer with a black box interface but someone somewhere needs to know
what's actually going on inside the black box.

Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
John Gardner
2017-10-10 23:06:55 UTC
Permalink
...someone somewhere needs to know
what's actually going on inside the black box...

"8) Yup...
Post by smplx
Post by Wouter van Ooijen
Post by David C Brown
Probably not the ideal place to ask
Why not? it is the same company :)
Post by David C Brown
but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.
It is the same company :)
My advice would be to switch to 32-bit chips and C++. Cortex-M0 chips
and modules are very cheap.
the idea of using a HLL such as C++ is very appealing. Faster development,
easier maintenance, dumber programmers :-)
But let us not forget that big slow code that needs a lot of resources to
run also tends to eat more power. And somewhere deep inside all that
HLL code you are going to need someone with the skill to catch and fix low
level bugs and maintain the low / high level interface.
Reminds me of a project I came into contact with many years ago (it's
always many years now). A ton of code written in C. Lovingly crafted to be
platform independent and portable. Only thing was it ran like a dog and
ate batteries like a kid in a sweat shop. But the worst of it was it would
periodically stop sending or receiving data through the modem (chip) and
nobody had a clue how to fix it. It's all well and good providing a C
programmer with a black box interface but someone somewhere needs to know
what's actually going on inside the black box.
Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Ivey Cole
2017-10-10 23:49:00 UTC
Permalink
Just need a VM and write it in JAVA! No need to worry about the small stuff😀.

Sent from tin can net over high speed barbed wire network
Post by John Gardner
...someone somewhere needs to know
what's actually going on inside the black box...
"8) Yup...
Post by smplx
Post by Wouter van Ooijen
Post by David C Brown
Probably not the ideal place to ask
Why not? it is the same company :)
Post by David C Brown
but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.
It is the same company :)
My advice would be to switch to 32-bit chips and C++. Cortex-M0 chips
and modules are very cheap.
the idea of using a HLL such as C++ is very appealing. Faster development,
easier maintenance, dumber programmers :-)
But let us not forget that big slow code that needs a lot of resources to
run also tends to eat more power. And somewhere deep inside all that
HLL code you are going to need someone with the skill to catch and fix low
level bugs and maintain the low / high level interface.
Reminds me of a project I came into contact with many years ago (it's
always many years now). A ton of code written in C. Lovingly crafted to be
platform independent and portable. Only thing was it ran like a dog and
ate batteries like a kid in a sweat shop. But the worst of it was it would
periodically stop sending or receiving data through the modem (chip) and
nobody had a clue how to fix it. It's all well and good providing a C
programmer with a black box interface but someone somewhere needs to know
what's actually going on inside the black box.
Regards
..someone somewhere needs to know
what's actually going on inside the black box...
"8) Yup...
Post by smplx
Post by Wouter van Ooijen
Post by David C Brown
Probably not the ideal place to ask
Why not? it is the same company :)
Post by David C Brown
but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.
It is the same company :)
My advice would be to switch to 32-bit chips and C++. Cortex-M0 chips
and modules are very cheap.
the idea of using a HLL such as C++ is very appealing. Faster development,
easier maintenance, dumber programmers :-)
But let us not forget that big slow code that needs a lot of resources to
run also tends to eat more power. And somewhere deep inside all that
HLL code you are going to need someone with the skill to catch and fix low
level bugs and maintain the low / high level interface.
Reminds me of a project I came into contact with many years ago (it's
always many years now). A ton of code written in C. Lovingly crafted to be
platform independent and portable. Only thing was it ran like a dog and
ate batteries like a kid in a sweat shop. But the worst of it was it would
periodically stop sending or receiving data through the modem (chip) and
nobody had a clue how to fix it. It's all well and good providing a C
programmer with a black box interface but someone somewhere needs to know
what's actually going on inside the black box.
Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.
Forrest Christian (List Account)
2017-10-09 17:10:55 UTC
Permalink
My understanding is that everything is moving to MPLABX, eventually
including the avr tools.

I'm always surprised when someone complains about the microchip tools.
Personally I really like MPLABX.

What is it that you find to be a problem?
Post by David C Brown
Probably not the ideal place to ask but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.
I would be using their eight bit devices and programming in assembler. And
would want development aids equivalent to MPLAB8 and ICD2.
Could anyone give me any direct advice on getting started or direct me to
the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
David C Brown
2017-10-09 18:30:46 UTC
Permalink
The ICD2 hardware is my main problem. It only works on one of my computers
- a rather slow Shuttle running winnows XP. Won't run on my Win7 laptop
which is bluidy annoying because that is partly why I bought the laptop.

And MPLab8 is the only programme that I have used in recent years which
can lock up so thoroughly that a power off reset is needed.

__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
Derbyshire eMail: ***@gmail.com
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>



*Sent from my etch-a-sketch*

On 9 October 2017 at 18:10, Forrest Christian (List Account) <
Post by Forrest Christian (List Account)
My understanding is that everything is moving to MPLABX, eventually
including the avr tools.
I'm always surprised when someone complains about the microchip tools.
Personally I really like MPLABX.
What is it that you find to be a problem?
Post by David C Brown
Probably not the ideal place to ask but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.
I would be using their eight bit devices and programming in assembler.
And
Post by David C Brown
would want development aids equivalent to MPLAB8 and ICD2.
Could anyone give me any direct advice on getting started or direct me to
the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Neil
2017-10-09 19:20:56 UTC
Permalink
Until recently, I resisted MPLABX because (a) it wasn't (yet?) setup for
hi-res screens on WIndows 8... fonts were very small, and only
changeable for the editor (not the other panels/menus). Scaling from
the control panel increased font size, but did not scale the window, so
some buttons were off the screen. This is partially a Win 8 issue; (b)
It was slow (response), even on an i5, (c) docs were changing rapidly,
so the docs/tutorials were almost always obsolete. This is also a gripe
about the library docs being out of sync.

(a) is much better nowadays. And I can finally access the
Power-target-from-Pickit button in the IPE.
(b) I've circumvented by getting a slightly faster laptop, but it sucks
that we need an i7 for just an editor nowadays.
(c) is still an issue.
Post by Forrest Christian (List Account)
My understanding is that everything is moving to MPLABX, eventually
including the avr tools.
I'm always surprised when someone complains about the microchip tools.
Personally I really like MPLABX.
What is it that you find to be a problem?
Post by David C Brown
Probably not the ideal place to ask but I am contemplating giving up on
PICS because of the wretched development tools and AVR looks,
superficially, attractive.
I would be using their eight bit devices and programming in assembler. And
would want development aids equivalent to MPLAB8 and ICD2.
Could anyone give me any direct advice on getting started or direct me to
the better of the overwhelming number of web resources?
__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak Phone: 01663 733236
SK23 7ND web: www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>
*Sent from my etch-a-sketch*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
a***@stfc.ac.uk
2017-10-10 08:41:08 UTC
Permalink
Post by Forrest Christian (List Account)
My understanding is that everything is moving to MPLABX, eventually
including the avr tools.
I'm always surprised when someone complains about the microchip tools.
Personally I really like MPLABX.
What is it that you find to be a problem?
It is large (as in very bloated) and slow. Its interface seems to be using underlying Netbeans for its features, and Microchips usage of these features doesn't seem to be well implemented. You seem to need a real stonker of a machine with heaps of memory to run it at any speed.

The continually reported problems maintaining connection to any ICD, Pickit or RealICE. Some people have continuous problems just getting a connection while others don't seem to have a problem, and it doesn't appear to be OS platform dependant, judging by comments on the Microchip forum. The introduction of the ICD4 has been a bit of a disaster with what seems to be a not properly tested interface.

Bugs don't seem to get fixed with new releases. Each new release seems to produce its own new set of problems.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
William Westfield
2017-10-11 03:01:45 UTC
Permalink
Post by a***@stfc.ac.uk
What is it that you find to be a problem [with MPLABX]?
It is large (as in very bloated) and slow.
Sigh. Atmel Studio is actually somewhat worse, at least in the “boated” department, and particularly annoying because a lot of that bloat is “Microsoft XX runtime for Visual Studio” that apparently wants to be scattered across your disk in particular places that can’t be changed. I’m not sure about speed; AS has horrible startup time on my VM, but seems to run OK. I don’t use either one much; preferring emacs, makefiles, and command-line compilers.

BillW
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
James Cameron
2017-10-11 03:20:40 UTC
Permalink
Post by William Westfield
Post by a***@stfc.ac.uk
What is it that you find to be a problem [with MPLABX]?
It is large (as in very bloated) and slow.
Sigh. Atmel Studio is actually somewhat worse, at least in the “boated” department, and particularly annoying because a lot of that bloat is “Microsoft XX runtime for Visual Studio” that apparently wants to be scattered across your disk in particular places that can’t be changed. I’m not sure about speed; AS has horrible startup time on my VM, but seems to run OK. I don’t use either one much; preferring emacs, makefiles, and command-line compilers.
I'm also preferring emacs and makefiles.

PlatformIO has emacs integration, so it becomes a kind of library
manager and target uploader.
--
James Cameron
http://quozl.netrek.org/
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mai
William Westfield
2017-10-10 04:37:51 UTC
Permalink
I would be using their eight bit [AVR] devices and programming in assembler. Andwould want development aids equivalent to MPLAB8 and ICD2.
Could anyone give me any direct advice on getting started or direct me to the better of the overwhelming number of web resources?
The “Current” official low-end tool is the Atmel ICE. Debugging and programming, and it also works with ARM devices. (randomly goes on sale, or is offered discounted as part of a “training event.”) (Previous generation was “Jtag-ICE-3” (with USB); you mentioned the JTAG ICE with serial only - that’s several generations old at this point!)

AVRs mostly use a LVSP-like programming protocol that is SPI based and easy to implement, so there are a bunch of very cheap programmers available (“USBASP”)
On the other hand, Atmel has kept their debugging protocols and SW much more proprietary than PICs, so there aren’t many (any?) Cloned debuggers (as there are with PicKit2/3)

The best web resource is probably the “AVRFreaks” Forum: http://avrfreaks.net/

Be aware that there are two assemblers, with slightly differing syntax. There is the official Atmel assembler, which is a single-file no-linker absolute assembler, and there is the Gnu “binutils” assembler that goes with the gcc compiler (avr-as)

Most of the low-end Arduinos are AVR based, so buying an “Arduino Uno Clone” gives you a cheap development board with Bootloader and USB connection. OTOH, Some of the "Xplained Mini” boards are nearly as cheap and include support for the debugger. http://www.microchipdirect.com/product/search/all/xplainedmini?mns=xplained%20mini

"Atmel Studio” is the vendor-supported IDE. It’s essentially a shell on top of Microsoft Visual Studio, and runs on Windows only. The AVR world is anxiously awaiting Microchip action on adding AVR to MPLAB, with or without discontinuing Atmel Studio.

There are a couple of gotchas in AVR assembler:
1) the “general purpose registers” really aren’t. R0-R15 don’t operate with immediate operands, making them 2nd-class citizens.
2) Similarly, there is a limited range of “IO registers” that are accessible with special instructions like SBI (Set Bit in IO register.) on a larger AVR, hardly ANY of IO is reachable that way, and you have to do multi-step read, modify, write, sequences.
3) PC, SP, and Flags are considered IO registers making them somewhat more complicated to access than on a PIC or ARM.

BillW
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Chuck Olson
2017-10-10 18:04:17 UTC
Permalink
Post by mike brown
Anyone ever use a CDP1802?
I never used it but I remember hearing a talk at the IEEE Cherry Hill
test conference by a guy who built a hardware fault simulator for the
RCA 1802 for NASA-JPL.

I think it was this guy:

< https://ntrs.nasa.gov/search.jsp?R=19800012553 >

As I recall the 1802 was the first CMOS micro and you could get it
built/qualified for space use (ceramic packaging, Silicon on Sapphire,
etc.).

Anyway, I remember in the Q&A someone asked him something to the
effect of: "why bother with hardware fault simulation?" his response
was:

"our customer returns come in the form of fireballs"
--
Best Regards,

Chuck Olson, WB9KZY
Jackson Harbor Press
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
IVP
2017-10-10 21:33:21 UTC
Permalink
Post by mike brown
Anyone ever use a CDP1802?
Yes. It was my first computer, early 80s

http://www.emma02.hobby-site.com/eti.html

Programmed through a hex keypad

I still have it

---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Loading...