Searching \ for '[PIC] What programming lamguage' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'What programming lamguage'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] What programming lamguage'
2011\10\20@023937 by jana1972

flavicon
face
Hi,
Thanks to all who  replied to  my thread
"How to start with PIC programming"

I decided to buy PicKit3 with the development board and start learning PIC programming.

But what language should I  start with?
In the past I used (but  only a little)  assembly language (but for different computers) and also C language.

Shall I start with assembly language or C language or different?
What would you suggest.
Are there more tutorials in assembly language or in C?
Thanks
L.

2011\10\20@025008 by IVP

face picon face
> Shall I start with assembly language or C language or different?

There's no harm in learning both assembly and HLL, but if you
choose HLL you should at least familiarise yourself with assembly
so that you can read and/or adapt other people's code

Jo

2011\10\20@031629 by slippyr4

picon face
On 20 October 2011 07:49, IVP <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote:

> > Shall I start with assembly language or C language or different?
>
>
This is likely to be a rather polarized debate!

Personally, I did a few (simple) pic16 projects in assembler then moved on
to pic18 and mcc18. I've not looked back. BUT the little bit of assembler I
did really helps understand what's going on under the bonnet.

I'd do the same again. You need a bit of assembler knowledge, but, to get
any real work done in assembler is much harder work that in something like
C. There are other arguments *for* assembler - if you're good, you could
write code that outperforms something that a C compiler will generate.

Although I've never used it myself, it may well be worth looking at JAL.
Originally created by one of the piclisters, it's a high level language
that's been designed around the pic architecture so produces pretty nice
code, and is pretty easy to learn

2011\10\20@033239 by Electron

flavicon
face

Start with ASM, for the love of God!

Then, if you feel like that, move on to higher level languages.

But start with its own language!


At 08.39 2011.10.20, you wrote:
{Quote hidden}

>

2011\10\20@043443 by Chris McSweeny

picon face
On Thu, Oct 20, 2011 at 7:39 AM,  <.....jana1972KILLspamspam@spam@centrum.cz> wrote:
> But what language should I  start with?

I'd say C, as it makes for easier and generally better programming. I
say that as somebody who's done almost all of my work with PICs using
assembler (including some in a professional capacity), and only
recently moved from assembler to C with AVRs. I have to say that in
general life is far more straightforward when working in C, as you
don't have to worry about some of the finer details.

I disagree that you even need to know assembler - at least not to
start with - as you can write perfectly functional code without
knowing what it compiles to, and there is also plenty of sample stuff
written in C.

Chris

2011\10\20@052004 by Electron

flavicon
face
At 10.34 2011.10.20, you wrote:
>On Thu, Oct 20, 2011 at 7:39 AM,  <jana1972spamKILLspamcentrum.cz> wrote:
>> But what language should I  start with?
>
>I'd say C, as it makes for easier and generally better programming. I
>say that as somebody who's done almost all of my work with PICs using
>assembler (including some in a professional capacity), and only
>recently moved from assembler to C with AVRs. I have to say that in
>general life is far more straightforward when working in C, as you
>don't have to worry about some of the finer details.
>
>I disagree that you even need to know assembler - at least not to
>start with - as you can write perfectly functional code without
>knowing what it compiles to, and there is also plenty of sample stuff
>written in C.

It's assembly, not assembler, and yes, you can certainly write perfectly
functional code even in BASIC, but this is not the point. The point is
that coding in assembly gives you a sense of the device you're developing
for, that no high level language can give. It's not just about getting the
job done, or then C wouldn't even be the best choice. It's that he wants
to LEARN PIC's, thus nothing is best than assembly. Then, as said, to do
the actual, real job, he can use whatever language fits the task. If you
need strict timing, I'd do it in assembly anyway, else it's just a matter
of development time, resources, etc.. which may favour high level languages..


>
>Chris

2011\10\20@054104 by alan.b.pearce

face picon face
> I disagree that you even need to know assembler - at least not to
> start with - as you can write perfectly functional code without
> knowing what it compiles to, and there is also plenty of sample stuff
> written in C.

Err, yes, but you do need to appreciate the underlying architecture of the chip, and why certain registers need to be initialised a certain way before something else happens, e.g. banking registers, and sometimes the details are hidden by the compiler, and sometimes not.


-- Scanned by iCritical.

2011\10\20@054910 by Isaac Marino Bavaresco

flavicon
face
Em 20/10/2011 07:19, Electron escreveu:
> It's assembly, not assembler, and yes, you can certainly write perfectly
> functional code even in BASIC, but this is not the point. The point is
> that coding in assembly gives you a sense of the device you're developing
> for,


So, when you want to re-use your C code in a completely different
architecture you must first learn its assembly language to get a sense
of the new device, then press "Build"?

The biggest advantage of C over assembly it that you can re-use most of
your code with different architectures without changing a single line.
If you start to modify your C code for every architecture it is meant to
run you will waste a lot of time. Write good code only once, adhering to
the standards so you can re-use it right away.


Isaac

2011\10\20@065024 by Wouter van Ooijen

face picon face
> Err, yes, but you do need to appreciate the underlying architecture of the chip,

Why would you *need* to appreciate it? I don't think many PC users appreciate the finer details (or any details at all) of the x86 or x386 architecture (much less the horribly complex yet very successful siblings that we use today).

I am now doing some work on a Cortex chip in C++. I am very familiar with the ARM architecture and instruction set, but I don't feel any need to dig into the Cortex instruction set. The authors of the GCC back-end have done that, so I can go on with my work very effectively without such knowledge. And later on I might switch to a PIC32, again without first digging into the instruction set architecture.

I don't say that some knowledge of the asm level can't be beneficial, but say that you *need* it is ridiculous.

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2011\10\20@070749 by M.L.

flavicon
face
On Thu, Oct 20, 2011 at 5:40 AM,  <.....alan.b.pearceKILLspamspam.....stfc.ac.uk> wrote:
> Err, yes, but you do need to appreciate the underlying architecture of the chip, and why certain registers need to be initialised a certain way before something else happens, e.g. banking registers, and sometimes the details are hidden by the compiler, and sometimes not.
>
>

Even worse - when the compiler gets something wrong and you have to
look at the disassembly to figure out what it did wrong.

-- Martin K.

2011\10\20@072020 by alan.b.pearce

face picon face
> > Err, yes, but you do need to appreciate the underlying architecture of the chip,
>
> Why would you *need* to appreciate it? I don't think many PC users
> appreciate the finer details (or any details at all) of the x86 or x386
> architecture (much less the horribly complex yet very successful
> siblings that we use today).
>
> I am now doing some work on a Cortex chip in C++. I am very familiar
> with the ARM architecture and instruction set, but I don't feel any need
> to dig into the Cortex instruction set. The authors of the GCC back-end
> have done that, so I can go on with my work very effectively without
> such knowledge. And later on I might switch to a PIC32, again without
> first digging into the instruction set architecture.
>
> I don't say that some knowledge of the asm level can't be beneficial,
> but say that you *need* it is ridiculous.

Um, not really, does the compiler automatically set the TRIS, LAT or PORT registers for you? All the PIC C code I have seen manipulates these in some way that is set by the writer of the end application.
Similar things happen with some of the config registers, and how they affect things like watchdog operation on some chip families.

Some of these things get ingrained in the mind better by using ASM level code rather than going to the higher level where it gets abstracted somewhat. -- Scanned by iCritical.

2011\10\20@080055 by Wouter van Ooijen

face picon face
>> I don't say that some knowledge of the asm level can't be beneficial,
>> but say that you *need* it is ridiculous.
>
> Um, not really, does the compiler automatically set the TRIS,
> LAT or PORT registers for you?

[if I use Jal: the library, not the compiler itself, will take care of that :) ]

But that has absolutely nothing to do with assembler versus C. Unless you have a library that shields you from the architecture *of the peripherals* (and you can have such a lib even in asm) you will have to learn the details of that architecture. Totally independent of the language you use.

> Some of these things get ingrained in the mind better by using ASM level
> code rather than going to the higher level where
> it gets abstracted somewhat.

I see no merit in that sentence at all. When I program on a Cortex chip I have to check how the peripherals behave, and beside some declarations (that are not part of the compiler but of a vendor-provided library) that let me write

   SysTick->VAL = 0;

instead of

   *((volatile unsigend int *)(0x123456)) = 0;

the compiler does not help me at all. It is still up to me to read and understand the SysTick peripheral. But I don't need to know whether Cortex, ARM7, or even MIPS machine instructions are used to implement my HLL statements.

Again, there are circumstances where some knowledge of assembly is beneficial, most notably in very timing critical code, compiler errors, and code size issues. But that's stuff for a seasoned professional, not for someone who is starting with PICs.

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2011\10\20@085027 by Harold Hallikainen

face
flavicon
face
Joining the conversation late... I agree that there is a need to know the
details of the peripherals, but not necessarily the architecture of the
CPU (CPU registers, etc.) in many cases. I grew up doing assembly (PDP-8,
PDP-11, MC6800, then PIC16, PIC18). Since moving to PIC24 and PIC32, the
only assembly I've had to deal with is for writing bootloaders. That's
also the place where I had to deal with linker scripts. On the PIC32, I
needed the C startup code to run before my C bootload code. Then, when the
application runs, it runs its own compiler generated startup code. I did
my bootloader startup code by looking at the disassembly of a normal
startup and adapting it to what I need. One interesting thing I found just
last week was I had a jump to the start of my C code at the end of the
startup. Worked fine in the simulator, but crashed on hardware. The PIC32
(and generally MIPS cores) executes the instruction after the jump before
doing the jump. There WAS no instruction after the jump, so the CPU
executed erased flash, which caused an exception. THAT was fun to figure
out!

So... I'm now mostly using C, but now and then have to dig into assembly.

Harold

-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\10\20@093726 by Isaac Marino Bavaresco

flavicon
face
Em 20/10/2011 08:34, Wouter van Ooijen escreveu:
>> Err, yes, but you do need to appreciate the underlying architecture of the chip,
> Why would you *need* to appreciate it? I don't think many PC users
> appreciate the finer details (or any details at all) of the x86 or x386
> architecture (much less the horribly complex yet very successful
> siblings that we use today).
>
> I am now doing some work on a Cortex chip in C++. I am very familiar
> with the ARM architecture and instruction set, but I don't feel any need
> to dig into the Cortex instruction set. The authors of the GCC back-end
> have done that, so I can go on with my work very effectively without
> such knowledge. And later on I might switch to a PIC32, again without
> first digging into the instruction set architecture.
>
> I don't say that some knowledge of the asm level can't be beneficial,
> but say that you *need* it is ridiculous.


I agree in gender, number and degree.

2011\10\20@094623 by RussellMc

face picon face
It's probably worth pointing out to Jana  / L that the JAL creator
mentioned here:

   Although I've never used it myself, it may well be worth looking at JAL..
   Originally created by one of the piclisters, it's a high level language
   that's been designed around the pic architecture so produces pretty nice
   code, and is pretty easy to learn.

Is Wouter van Ooijen, who is contributing to this discussion. His
having written a niche programming language which has achieved a life
of its own may add some extra weight to his various comments when you
are balancing opposing responses.


On 21 October 2011 01:00, Wouter van Ooijen <EraseMEwouterspam_OUTspamTakeThisOuTvoti.nl> wrote:
{Quote hidden}

...


         Russell

2011\10\20@094828 by Isaac Marino Bavaresco

flavicon
face
Em 20/10/2011 09:20, alan.b.pearcespamspam_OUTstfc.ac.uk escreveu:
>>> Err, yes, but you do need to appreciate the underlying architecture of the chip,
>> Why would you *need* to appreciate it? I don't think many PC users
>> appreciate the finer details (or any details at all) of the x86 or x386
>> architecture (much less the horribly complex yet very successful
>> siblings that we use today).
>>
>> I am now doing some work on a Cortex chip in C++. I am very familiar
>> with the ARM architecture and instruction set, but I don't feel any need
>> to dig into the Cortex instruction set. The authors of the GCC back-end
>> have done that, so I can go on with my work very effectively without
>> such knowledge. And later on I might switch to a PIC32, again without
>> first digging into the instruction set architecture.
>>
>> I don't say that some knowledge of the asm level can't be beneficial,
>> but say that you *need* it is ridiculous.
> Um, not really, does the compiler automatically set the TRIS, LAT or PORT registers for you? All the PIC C code I have seen manipulates these in some way that is set by the writer of the end application.


The pitiful semi-professional compilers need help from the programmer. I
use Hi-Tech PICC and it is plain standard ANSI C.


>
> Similar things happen with some of the config registers,


Those you need to care of, but they have nothing to do with the
instruction set and only a few with the memory organization. They are
related to the peripherals.


>  and how they affect things like watchdog operation on some chip families..


This varies on a part-by-part or group-by-group basis, it is not related
to the PIC architecture itself. Other MCU manufacturers have much
similar or much different approaches, but in the end you need to know
your peripheral's requirements. No ASM required.


>
> Some of these things get ingrained in the mind better by using ASM level code rather than going to the higher level where it gets abstracted somewhat.

I can use things like "ClrWdt();" in C, or "INTCON = 0xc0;". Why would I
need assembly?


Note: I know and used to program very well in assembly (of a lot of
architectures). I simply don't feel the need and the patience to created
projects exclusively in assembly.


Isaac

2011\10\20@095713 by Isaac Marino Bavaresco

flavicon
face
Em 20/10/2011 10:50, Harold Hallikainen escreveu:
> Joining the conversation late... I agree that there is a need to know the
> details of the peripherals, but not necessarily the architecture of the
> CPU (CPU registers, etc.) in many cases. I grew up doing assembly (PDP-8,
> PDP-11, MC6800, then PIC16, PIC18). Since moving to PIC24 and PIC32, the
> only assembly I've had to deal with is for writing bootloaders.


My latest bootloader was written entirely in C, the closest to assembly
I went was using some "__builtin_tblrd", "__builtin_tblwt" and
"__builtin_write_NVM".


Isaac

2011\10\20@110019 by Electron

flavicon
face
At 11.48 2011.10.20, you wrote:
>Em 20/10/2011 07:19, Electron escreveu:
>> It's assembly, not assembler, and yes, you can certainly write perfectly
>> functional code even in BASIC, but this is not the point. The point is
>> that coding in assembly gives you a sense of the device you're developing
>> for,
>
>
>So, when you want to re-use your C code in a completely different
>architecture you must first learn its assembly language to get a sense
>of the new device, then press "Build"?

You're not making a point. Reuse what? Initialization code for ports in a
1024KB device? We're talking about 8-bit microcontrollers here, not NASA
sources.


>The biggest advantage of C over assembly it that you can re-use most of
>your code with different architectures without changing a single line.

Unfortunately in the small 8bit microcontrollers world there's very little
to reuse, and there's very little power too, using a HLL compiler is not
always justified.

But, again, the original poster said he wants to LEARN how PICs work. If
he wants to learn the architecture, nothing is better than knowing it, and
as you point out C abstracts this, so he needs to learn assembly language
and also study the peripherals that are integrated on the MPU.


>If you start to modify your C code for every architecture it is meant to
>run you will waste a lot of time. Write good code only once, adhering to
>the standards so you can re-use it right away.

Re-use what, please? Blink a LED?

As I said HLL's certainly have their use, but if one wants to get introduced
into the architecture of a tiny 8 bit PIC, I think that doing it with a HLL
is really overkill, and doesn't tell you much about the architecture behind
this level of abstraction.

Pointing that C allows code reuse better than asm is a different issue, and
anyway code reuse among 8 bit PICs is possible even in asm.


>
>
>Isaac
>
>

2011\10\20@110502 by Electron

flavicon
face
>At 11.48 2011.10.20, you wrote:
>>Em 20/10/2011 07:19, Electron escreveu:
>>> It's assembly, not assembler, and yes, you can certainly write perfectly
>>> functional code even in BASIC, but this is not the point. The point is
>>> that coding in assembly gives you a sense of the device you're developing
>>> for,
>>
>>
>>So, when you want to re-use your C code in a completely different
>>architecture you must first learn its assembly language to get a sense
>>of the new device, then press "Build"?
>
>You're not making a point. Reuse what? Initialization code for ports in a
>1024KB device? We're talking about 8-bit microcontrollers here, not NASA
>sources.

1024 bytes, even. :D If it was 1024KB, then it would be entirely different...


{Quote hidden}

>>-

2011\10\20@113051 by Harold Hallikainen

face
flavicon
face

> Em 20/10/2011 10:50, Harold Hallikainen escreveu:
>> Joining the conversation late... I agree that there is a need to know
>> the
>> details of the peripherals, but not necessarily the architecture of the
>> CPU (CPU registers, etc.) in many cases. I grew up doing assembly
>> (PDP-8,
>> PDP-11, MC6800, then PIC16, PIC18). Since moving to PIC24 and PIC32, the
>> only assembly I've had to deal with is for writing bootloaders.
>
>
> My latest bootloader was written entirely in C, the closest to assembly
> I went was using some "__builtin_tblrd", "__builtin_tblwt" and
> "__builtin_write_NVM".
>
>
> Isaac

I include the bootloader within my project, so I need two sets of startup
code, once for the bootloader itself (also written in C), and one for the
application. I adapted fixed code (mostly setting up the stack pointer and
related stuff) for the bootloader startup, then let the compiler and
linker build the startup code for the application (and that startup code,
which handles stack pointer and variable initialization, is in the
application area).

I know others do the bootloader and application as separate projects, then
either bootload in the application or merge the flash images. Not the way
I'm doing it, though.

Thanks!

Harold


-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\10\20@113803 by M.L.

flavicon
face
On Thu, Oct 20, 2011 at 10:59 AM, Electron <@spam@electron2k4KILLspamspaminfinito.it> wrote:
> As I said HLL's certainly have their use, but if one wants to get introduced
> into the architecture of a tiny 8 bit PIC, I think that doing it with a HLL
> is really overkill, and doesn't tell you much about the architecture behind
> this level of abstraction.

I have to agree with this. I'm not going to tell anyone which language
they have to use, or which religion they should/not be a part of, but
I think if you're learning about microcontrollers you should be
learning about status flags and peripheral registers.

Most of the people advocating that you don't need to know that are, in
fact, experts who already know all of that.

To Wouter, I respect your opinion, however, I don't see a 32 bit
microcontroller as the same beast as an 8 bit PIC. I would then make
the conclusion that if you want to learn about small resource limited
machines then you should first learn assembly.

-- Martin K

2011\10\20@114658 by Byron Jeff

flavicon
face
On Thu, Oct 20, 2011 at 08:16:28AM +0100, slippyr4 wrote:
> On 20 October 2011 07:49, IVP <KILLspamjoecolquittKILLspamspamclear.net.nz> wrote:
>
> > > Shall I start with assembly language or C language or different?
> >
> >
> This is likely to be a rather polarized debate!

It always is.

>
> Personally, I did a few (simple) pic16 projects in assembler then moved on
> to pic18 and mcc18. I've not looked back. BUT the little bit of assembler I
> did really helps understand what's going on under the bonnet.

The argument I always made in the past is that assembly was PIC lingua
franca. It was the language that Turorials and Application notes were
written in. So it was useful to learn it simply to be able to have a
discussion with others and read code that others had written.

I'm starting to think that the hand has moved on this.

>
> I'd do the same again. You need a bit of assembler knowledge, but, to get
> any real work done in assembler is much harder work that in something like
> C. There are other arguments *for* assembler - if you're good, you could
> write code that outperforms something that a C compiler will generate.

But rarely is there a need to do so. Most early PIC adopters wrote in
assembly because that's what was available. Now there are a plethora of
choices.

>
> Although I've never used it myself, it may well be worth looking at JAL.
> Originally created by one of the piclisters, it's a high level language
> that's been designed around the pic architecture so produces pretty nice
> code, and is pretty easy to learn.

The original JAL was Wouter's pride and joy. He freed it and others have
picked up the flag and run with it. The library support is flat awesome. I
was thinking about a quick project when I misplaced the remote for my
Western Digital TV live player. The player will accept commands from a USB
keyboard. JAL has usb_keyboard library support that can literally be
written in 5 lines of code. Here's a sample from the library description:

http://jallib.googlecode.com/svn/trunk/doc/html/usb_keyboard.html

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
include usb_keyboard
usb_keyboard_init()

while ( !usb_is_configured() )  loop ;-- wait till USB becomes available
end loop

var byte ch
forever loop ;-- main loop
;   -- call the flush routine on a regular base in the main loop
;   -- in order to keep the USB communicaiton alive
   usb_keyboard_flush()
   if ( usb_is_configured() )
      if ( pin_x )
                  ush_keyboard_send_key( 0x00, USB_KEYBOARD_KEY_A )
      else
                  ush_keyboard_send_key( 0x00, USB_KEYBOARD_KEY_NONE )
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

It's library support like that that makes JAL attractive. The library
abstraction literally hides several hundred lines worth of USB
configuration.

BAJ



> -

2011\10\20@114753 by Bob Blick

face
flavicon
face
On Thursday, October 20, 2011 8:39 AM,  "L" wrote:

> I decided to buy PicKit3 with the development board and start learning
> PIC programming.
>
> But what language should I  start with?
> In the past I used (but  only a little)  assembly language (but for
> different computers) and
> also C language.
>
> Shall I start with assembly language or C language or different?
> What would you suggest.
> Are there more tutorials in assembly language or in C?

Hi L.,

If you plan to use other people's libraries of code, then you will
definitely need to program in C. Almost all the new examples from
Microchip are in C.

Since you have done some assembly language programming, even though it
is on another micro, you know how much memory and how many cycles it
takes to do a printf or a float, so you won't make that sort of mistake
when you are programming in C on a small microcontroller.

Cheerful regards,
Bob

-- http://www.fastmail.fm - The way an email service should be

2011\10\20@120851 by Wouter van Ooijen

face picon face
> I think if you're learning about microcontrollers you should be
> learning about status flags and peripheral registers.

If you mean the flags in peripheral registers I agree. If you mean the status register (carry, zero) I disagree. I'd rather write

   if( a > 5 ){ ... }

or even better

   if a > 5 then ... end if
   :)

than having to remember that the PIC asm substract instruction works more or less backwards, IIRC the 12-bit core does not have a substract-literal instructiopm, and the how the &^% was it that the carry flag reflected borrow: 1 == borrow or was it 1 == no borrow?

> To Wouter, I respect your opinion, however, I don't see a 32 bit
> microcontroller as the same beast as an 8 bit PIC. I would then make
> the conclusion that if you want to learn about small resource limited
> machines then you should first learn assembly.

Maybe, if your aim is to use the chip to its full potential and cram the most functionality into it. That is perfectly legitimate when your product will be produced in 1M copies and you have the time to do things optimally.

An assembly language programmer can always outperform a compiler, when given enough time. Can you recall the last time you were given 'enough time' to complete your project?

I have a small project at hand to write a library for the RDM70 radio modules I sell. What I have so far is written in C, and runs (with appropriate macro's for I/O pin access) on either a 16F or an LPC2148. I would not dream of writing this in PIC assembler. (I know, I should write a Jal version! But I forgot to include the adapter PCBs in my last Olimex order, so the project on the backburner now).

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2011\10\20@125209 by Sergey Dryga

flavicon
face
Electron <electron2k4 <at> infinito.it> writes:


> It's assembly, not assembler, and yes, you can certainly write perfectly
> functional code even in BASIC, but this is not the point. The point is
> that coding in assembly gives you a sense of the device you're developing
> for, that no high level language can give. It's not just about getting the
> job done, or then C wouldn't even be the best choice. It's that he wants
> to LEARN PIC's, thus nothing is best than assembly. Then, as said, to do
> the actual, real job, he can use whatever language fits the task. If you
> need strict timing, I'd do it in assembly anyway, else it's just a matter
> of development time, resources, etc.. which may favour high level languages.

Learning PIC has nothing, or very little, to do with assembly.  The sense of a
device comes from reading docs on architecture (which have very little assembly
code there, and I never read that assembly anyway).  Access to all the registers
is available directly from C, or through macros and functions provided by
compilers.  I actually found that learning assembly to any functional level
takes too much time that I do not have.  e.g. in 'C' one can type:
printf("Hello, world\r\n");

the same output in assembler will take a lot more typing.  
So, my recommendation for the OP is to start with HLL, C or JAL, and read
datasheets carefully to learn the architecture.  Or better yet, just start with
anything, it's easy to switch after you had a taste of the development and
understand what works for you better.

The 'C', JAL or assembly all have their places and I understand arguments that
assembly allows for more efficient code, given 'sufficient time' as Wouter puts
it.  In reality, for small projects such as hobby, there is no problem to go to
higher level PIC if memory/performance is limiting, unlike projects that would
be produced in millions units where even $0.01 cost per PIC is important.
Sergey Dryga
http://beaglerobotics.com

2011\10\20@130652 by Mark Hanchey

flavicon
face
On 10/20/2011 2:39 AM, RemoveMEjana1972TakeThisOuTspamcentrum.cz wrote:
>
> Shall I start with assembly language or C language or different?
> What would you suggest.
> Are there more tutorials in assembly language or in C?
> Thanks
> L.
>

The one reason I would suggest learning assembly first is to get proper chip support. What I mean by this is that in the PIC line of chips there is a lot of variety. Choices are great but that also comes with the downside that the software tools have to support that variety. The problem with C tools on the pic is that you have to depend on the people creating the compiler and hope they have taken the time to look at your specific chip and implement all of its features, often that doesn't happen. When you encounter a feature on a chip that your favorite compiler doesn't support, for whatever reason , you are left with the decision of changing compilers or changing chips. If you know assembly you can still continue to use a chip in your current compiler by writing ,usually fairly short, assembly routines in the C code.

Assembly also helps because sometimes setting registers on the pic is easier done with assembly than with the provided libraries.

For example :
__asm__ volatile(“disi #0x3FFF”); // disable temporarily all interrupts

It can be done in C but that done in assembly is just quicker.
Good luck
Mark

2011\10\20@131143 by Bob Ammerman

flavicon
face
> compilers.  I actually found that learning assembly to any functional
> level
> takes too much time that I do not have.  e.g. in 'C' one can type:
> printf("Hello, world\r\n");

Yeah, but you better know that "printf" will take up several K of your limited code space.

Knowing a bit of the under-the-hood stuff (not necessarily the assembly language) would leave you in a much better position to know that such things will happen.

BTW: Look at "puts()" as an alternative to "printf". If you need formatted values try things like "itoa()" or write your own simple formatting function.

-- Bob Ammerman
RAm Systems

2011\10\20@135838 by Sergey Dryga

flavicon
face
Bob Ammerman <picram <at> roadrunner.com> writes:

>
> > compilers.  I actually found that learning assembly to any functional
> > level
> > takes too much time that I do not have.  e.g. in 'C' one can type:
> > printf("Hello, world\r\n");
>
> Yeah, but you better know that "printf" will take up several K of your
> limited code space.

You are absolutely right, as usual.  If I were to develop a real-time system
with us resolution, I would probably not use printf().  But I now have a 0.1 s
real-time system, have 8 printf("%Ul\t", long) executing each 0.1 s; it runs on
16F877A, uses about 50% of RAM (there are other things it does, not just printf)
and has enough idle time to handle more tasks.  If I run out of space, I will
just go to 18F and the problem is solved!

>
> Knowing a bit of the under-the-hood stuff (not necessarily the assembly
> language) would leave you in a much better position to know that such things
> will happen.

Completely agree, and, since I started PICking on 16F84, I often find myself
trying to minimize the code only to realize that improvement is minimal in terms
of code size/execution time.  But again, it is highly dependent on the type of
device.

>
> BTW: Look at "puts()" as an alternative to "printf". If you need formatted
> values try things like "itoa()" or write your own simple formatting
> function.
> Thanks for the pointers to that, I will keep it in mind.
Sergey Dryga
http:/beaglerobotics.com


2011\10\20@141223 by Sergey Dryga

flavicon
face

Mark Hanchey <mark <at> pixeltrickery.com> writes:

> Assembly also helps because sometimes setting registers on the pic is
> easier done with assembly than with the provided libraries.

C does allow direct access to registers etc.

>
> For example :
> __asm__ volatile(“disi #0x3FFF”); // disable temporarily all interrupts

or, in C:
INTCONbits.GIE = 0; //disable interrupts

>
> It can be done in C but that done in assembly is just quicker.

That is a matter of opinion and personal experiences.

> Good luck
> Mark
>
Agree, good luck.

Sergey
http://beaglerobotics.com


2011\10\20@144919 by Isaac Marino Bavaresco

flavicon
face
Em 20/10/2011 13:37, M.L. escreveu:
> On Thu, Oct 20, 2011 at 10:59 AM, Electron <spamBeGoneelectron2k4spamBeGonespaminfinito.it> wrote:
>> As I said HLL's certainly have their use, but if one wants to get introduced
>> into the architecture of a tiny 8 bit PIC, I think that doing it with a HLL
>> is really overkill, and doesn't tell you much about the architecture behind
>> this level of abstraction.
> I have to agree with this. I'm not going to tell anyone which language
> they have to use, or which religion they should/not be a part of, but
> I think if you're learning about microcontrollers you should be
> learning about status flags and peripheral registers.


C won't hide the peripheral registers from you, unless you use a very
comprehensive library (that implements and hides everything for you) you
will always have to deal with them


>
> Most of the people advocating that you don't need to know that are, in
> fact, experts who already know all of that.


That's to some extend true. But I'm not saying that you don't need to
know that, I'm saying that you don't need to program in assembly.
There's a difference.


Isaac

2011\10\20@145325 by Isaac Marino Bavaresco

flavicon
face
Em 20/10/2011 12:59, Electron escreveu:
> At 11.48 2011.10.20, you wrote:
>> Em 20/10/2011 07:19, Electron escreveu:
>>> It's assembly, not assembler, and yes, you can certainly write perfectly
>>> functional code even in BASIC, but this is not the point. The point is
>>> that coding in assembly gives you a sense of the device you're developing
>>> for,
>>
>> So, when you want to re-use your C code in a completely different
>> architecture you must first learn its assembly language to get a sense
>> of the new device, then press "Build"?
> You're not making a point. Reuse what?


Let's see: LCD routines; I2C, SPI, etc. bit-banged interfaces; AES
encryption/decryption routines, keyboard decoding routines,
communication protocols handling, and so on...

Those are a few real examples of what I already re-used across PIC16F,
PIC18, PIC24, dsPIC, AVR, PIC32, ARM9 @ 400MHz.

I usually leave the  lowest level routines (testing/setting/resetting
bits, initialization, etc.) in a separate file that I adapt for each
platform, sometimes as sub-routines and sometimes as macros (for one
platform a function may be a macro and for other it may be a real function)..


>  Initialization code for ports in a
> 1024KB device? We're talking about 8-bit microcontrollers here, not NASA
> sources.


Leave all initialization and low level routines in a separate file for
each peripheral. E.g.: LCD.c, LCD.h, LCD_HW.c, LCD_HW.h.
LCD.c includes LCD.h and LCD_HW.h; other modules see only LCD.h.

The "*_HW" files are hardware dependent but usually they are small
(perhaps less than 10% of the code for each module). These files must be
adapted or completely rewritten across platforms.

I use one init function for each "module" (LCDInit, SPIInit), etc. and
call them all in my "main" function or elsewhere.

SPIInit calls SPI_HWInit if necessary.

The LCD.c, SPI.c, I2C.c, etc. don't know a thing about hardware, they
compile without changes across all the platforms (sometimes we need some
conditional compilation for platforms with weird limitations or non
compliant compilers).



>
>
>> The biggest advantage of C over assembly it that you can re-use most of
>> your code with different architectures without changing a single line.
> Unfortunately in the small 8bit microcontrollers world there's very little
> to reuse, and there's very little power too, using a HLL compiler is not
> always justified.


I reuse a lot of code. I can't speak for others.


>
> But, again, the original poster said he wants to LEARN how PICs work. If
> he wants to learn the architecture, nothing is better than knowing it, and
> as you point out C abstracts this, so he needs to learn assembly language
> and also study the peripherals that are integrated on the MPU.


He MUST learn it anyway, irrespective of what language he uses. How
would him initialize and use the peripherals?


>> If you start to modify your C code for every architecture it is meant to
>> run you will waste a lot of time. Write good code only once, adhering to
>> the standards so you can re-use it right away.
> Re-use what, please? Blink a LED?


If all you do is to blink a LED, then there's little to reuse. My
projects are much more complex than this.


{Quote hidden}

Even between PIC16 and PIC18 you must rewrite some parts because some
instructions with the same name behave differently


Isaa

2011\10\20@152734 by Peter Johansson

picon face
On Thu, Oct 20, 2011 at 2:39 AM,  <TakeThisOuTjana1972EraseMEspamspam_OUTcentrum.cz> wrote:

> Thanks to all who  replied to  my thread
> "How to start with PIC programming"
>
> I decided to buy PicKit3 with the development board and start learning PIC programming.
>
> But what language should I  start with?
> In the past I used (but  only a little)  assembly language (but for different computers) and
> also C language.
>
> Shall I start with assembly language or C language or different?
> What would you suggest.
> Are there more tutorials in assembly language or in C?

I have been a software engineer for 20+ years and while I have diddled
with uCs in the past I have gotten into them much more intensely over
the past six months.  I started with C, and while I have been looking
at the generated ASM since the beginning I only recently started
writing a few projects completely from scratch in assembly.  In most
cases it was unnecessary, but it really helped cement my understanding
of the architecture.

My suggestion is that you learn C and assembly side-by-side.  Write
all of your small sample programs in both C and assembly, and then
compare the code the C compiler generates with your own code.
Knowledge of just how your compiler does things can really help when
stepping through your code in the debugger.

Chances are you will probably wind up coding entirely in C,
particularly if your compiler has a very good optimizer for your MCU,
but the time spent learning assembly will be time well spent.

-p.

2011\10\20@154009 by M.L.

flavicon
face

On Thu, Oct 20, 2011 at 2:12 PM, Sergey Dryga <RemoveMEsergeyspamTakeThisOuTdryga.us> wrote:
>>
>> For example :
>> __asm__ volatile(“disi #0x3FFF”); // disable temporarily all interrupts
>
> or, in C:
> INTCONbits.GIE = 0; //disable interrupts
>

Those are not equivalent.

--
Martin K.

2011\10\20@155827 by Sergey Dryga

flavicon
face

M.L. <m <at> lkeng.net> writes:

> >> For example :
> >> __asm__ volatile(“disi #0x3FFF”); // disable temporarily all interrupts
> >
> > or, in C:
> > INTCONbits.GIE = 0; //disable interrupts
> >
>
> Those are not equivalent.
>
Why?  They both disable global interrupts, right?  Maybe this is a proof that
one needs to know assembly?

Thanks,
Sergey
http://beaglerobotics.com


2011\10\20@164042 by Dwayne Reid

flavicon
face
At 01:27 PM 10/20/2011, Peter Johansson wrote:

>My suggestion is that you learn C and assembly side-by-side.  Write
>all of your small sample programs in both C and assembly, and then
>compare the code the C compiler generates with your own code.
>Knowledge of just how your compiler does things can really help when
>stepping through your code in the debugger.
>
>Chances are you will probably wind up coding entirely in C,
>particularly if your compiler has a very good optimizer for your MCU,
>but the time spent learning assembly will be time well spent.

I've been deliberately staying out this discussion (I don't grok 'C', so I code exclusively in Assembler), but I think that the above advice is the best suggestion.

If you already code in 'C' for other processors, it should be a short learning curve.

Great advice, Peter.

dwayne

-- Dwayne Reid   <dwaynerEraseMEspam.....planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2011\10\20@165026 by Bob Ammerman

flavicon
face


> M.L. <m <at> lkeng.net> writes:
>
>> >> For example :
>> >> __asm__ volatile(“disi #0x3FFF”); // disable temporarily all
>> >> interrupts
>> >
>> > or, in C:
>> > INTCONbits.GIE = 0; //disable interrupts
>> >
>>
>> Those are not equivalent.
>>
> Why?  They both disable global interrupts, right?  Maybe this is a proof
> that
> one needs to know assembly?
>
> Thanks,
> Sergey
> http://beaglerobotics.com

The "disi" instruction is only valid on the 16-bit architecture chips.
(dsPIC3x and PIC24)

As written, the "disi" instruction will only disable interrupts for 0x4000 =
16384 instructions.

The INTCONbits.GIE = 0 is for one or more of the 8-bit families (I don't
remember exactly which ones).

-- Bob Ammerman
RAm Systems

2011\10\20@165038 by Isaac Marino Bavaresco

flavicon
face

Em 20/10/2011 17:58, Sergey Dryga escreveu:
> M.L. <m <at> lkeng.net> writes:
>
>>>> For example :
>>>> __asm__ volatile(“disi #0x3FFF”); // disable temporarily all interrupts
>>> or, in C:
>>> INTCONbits.GIE = 0; //disable interrupts
>>>
>> Those are not equivalent.
>>
> Why?  They both disable global interrupts, right?  Maybe this is a proof that
> one needs to know assembly?
>


1) "DISI" is a PIC24 and dsPIC instruction;
2) PIC24 and dsPICs don't have an "INTCON" register (they have INTCON1
and INTCON2) nor a "GIE" bit.
The closer to a "GIE" bit is the IPL0-IPL2 field in the "SR" register
(there's an IPL3 bit also in the "CORCON" register). When the field has
value 7 or greater all the user interrupts are disabled;
3) "DISI" disables the interrupts for a number of instruction cycles
only (16384 in that case).


Isaac

2011\10\20@165407 by M.L.

flavicon
face

On Thu, Oct 20, 2011 at 3:58 PM, Sergey Dryga <EraseMEsergeyspamdryga.us> wrote:
> M.L. <m <at> lkeng.net> writes:
>
>> >> For example :
>> >> __asm__ volatile(“disi #0x3FFF”); // disable temporarily all interrupts
>> >
>> > or, in C:
>> > INTCONbits.GIE = 0; //disable interrupts
>> >
>>
>> Those are not equivalent.
>>
> Why?  They both disable global interrupts, right?  Maybe this is a proof that
> one needs to know assembly?
>

Yes, it would seem to be evidence of that.
DISI is an instruction that disables interrupts for a literal number
of CPU cycles on a 16 bit PIC24 or dsPIC.
INTCON is a register on PIC18 and PIC16 that controls general
interrupt behavior. It does not exist on 16 bit PICs. GIE is the bit
that, as you correctly state, disables all interrupts indefinitely.

--
Martin K.

2011\10\20@173856 by Chris McSweeny

picon face
On Thu, Oct 20, 2011 at 9:53 PM, M.L. <RemoveMEmEraseMEspamEraseMElkeng.net> wrote:
{Quote hidden}

So what we're saying here is that in the context the OP was talking
about 8 bit uCs, the C version provides the correct result, and the
assembly version doesn't?

Chris

2011\10\20@190537 by Sergey Dryga

flavicon
face
Isaac Marino Bavaresco <isaacbavaresco <at> yahoo.com.br> writes:

> 1) "DISI" is a PIC24 and dsPIC instruction;
> 2) PIC24 and dsPICs don't have an "INTCON" register (they have INTCON1
> and INTCON2) nor a "GIE" bit.
> The closer to a "GIE" bit is the IPL0-IPL2 field in the "SR" register
> (there's an IPL3 bit also in the "CORCON" register). When the field has
> value 7 or greater all the user interrupts are disabled;
> 3) "DISI" disables the interrupts for a number of instruction cycles
> only (16384 in that case).
>
> Isaac

Thanks for clarification, Isaac and several other people who replied.  I have
not moved to PIC24 or dsPICs yet, there was no need and I have decent supply of
16F and 18F parts :-). I am pretty sure that there are similarly simple 'C' instructions to access SR
and CORCON registers in PIC24/dsPIC.   Sergey
http://beaglerobotics.com

2011\10\21@005524 by RussellMc

face picon face
>>> >> For example :
....
>>> Those are not equivalent.

>> Why?  They both disable global interrupts, right?  Maybe this is a proof that
>> one needs to know assembly?

> Yes, it would seem to be evidence of that.

No.

Without meaning to comment at all on the C / Assembler 'discussion'
I'll note that the above interchange, including related comments by
others, is about architectural features and register naming in
various Microchip devices. An understanding of the issues involved is
both essential to getting it right in all cases, and completely
independent of what language you subsequently USE  to get it right.
Once the various issues are properly understood a solution in a given
case could be implemented solely  in any of C, assembler, BASIC, JAL,
.... .

No?


       Russell McMahon.

2011\10\21@041457 by Electron

flavicon
face
At 22.50 2011.10.20, you wrote:
{Quote hidden}

CPU cycles is a concept alien to C programmers, and it is so by design ;)

>
>Isaac
>
>

2011\10\21@041457 by Electron

flavicon
face
At 20.53 2011.10.20, you wrote:
{Quote hidden}

You seem to willingly ignore that the OP said he wants to BEGIN TO LEARN
with small 8bit PIC's. Talking about NASA software on Cray doesn't address
the needs of the OP.

Moreover, LCD routines; I2C, SPI, etc. bit-banged interfaces; AES
>encryption/decryption routines, keyboard decoding routines,
>communication protocols handling, and so on... can be reused also in asm.


>I usually leave the  lowest level routines (testing/setting/resetting
>bits, initialization, etc.) in a separate file that I adapt for each
>platform, sometimes as sub-routines and sometimes as macros (for one
>platform a function may be a macro and for other it may be a real function).

Me too, and I do it in asm..

[...]

>If all you do is to blink a LED, then there's little to reuse. My
>projects are much more complex than this.

We're talking about HIS needs here, not mine or yours..

I do a lot of C++ coding (on the PC, where I did and do a lot of x86 asm
too, expecially in the past). Let's not turn this into a war between asm
and C++, please.

The OP wants to BEGIN with small 8 bit PIC's, blink a LED, sort of that, and
to get a feeling of the architecture.

What about ADA and its modules? Maybe he can set up a team of developers for
his blink a LED project, so team management is also important. ;P

2011\10\21@075901 by M.L.

flavicon
face

On Fri, Oct 21, 2011 at 12:54 AM, RussellMc <RemoveMEapptechnzTakeThisOuTspamspamgmail.com> wrote:
> Without meaning to comment at all on the C / Assembler 'discussion'
> I'll note that the above interchange, including related comments by
> others, is about architectural features and register naming in
> various Microchip devices. An understanding of the issues involved is
> both essential to getting it right in all cases, and completely
> independent of what language you subsequently USE  to get it right.
> Once the various issues are properly understood a solution in a given
> case could be implemented solely  in any of C, assembler, BASIC, JAL,
> ... .
>
> No?

DISI is a CPU instruction and INTCON is a register.
I don't know how you can say that you need to know this regardless of
what language you are using, without in fact commenting on the C vs.
ASM discussion.

IIRC C30 doesn't have a built-in macro/function for DISI, requiring
you to know what the assembler instruction would be if you are
programming in C. So you'd kind of have to know assembler already.

--
Martin K.

2011\10\21@102712 by Electron

flavicon
face
At 13.58 2011.10.21, you wrote:
{Quote hidden}

And that doesn't make it portable I'm afraid.


>
>--
>Martin K.
>
>

2011\10\21@105405 by M.L.

flavicon
face
On Fri, Oct 21, 2011 at 10:26 AM, Electron <RemoveMEelectron2k4KILLspamspaminfinito.it> wrote:

>>IIRC C30 doesn't have a built-in macro/function for DISI, requiring
>>you to know what the assembler instruction would be if you are
>>programming in C. So you'd kind of have to know assembler already.
>
> And that doesn't make it portable I'm afraid.
>

Sure it is. If you want to port your code to another processor you put
all of your low-level hardware abstraction into defined locations (in
the source code) so that you know what to change when you move to a
different processor.

I'm of course ignoring all reasonable questions as to why you would
need to port your whole project to different microcontroller anyway.
-- Martin K

2011\10\21@105455 by Isaac Marino Bavaresco

flavicon
face
Em 21/10/2011 12:26, Electron escreveu:
>> DISI is a CPU instruction and INTCON is a register.
>> I don't know how you can say that you need to know this regardless of
>> what language you are using, without in fact commenting on the C vs.
>> ASM discussion.
>>
>> IIRC C30 doesn't have a built-in macro/function for DISI, requiring
>> you to know what the assembler instruction would be if you are
>> programming in C. So you'd kind of have to know assembler already.
> And that doesn't make it portable I'm afraid.
>


Simply create your own DISABLEINTERRUPTS() macro with a different
definition for each architecture.
This way your sources will compile without changes across platforms.
Usually all you have to change is one header file with the platform
dependent definitions.


Isaac

2011\10\21@115759 by Isaac Marino Bavaresco

flavicon
face
Em 21/10/2011 12:53, M.L. escreveu:
> On Fri, Oct 21, 2011 at 10:26 AM, Electron <electron2k4STOPspamspamspam_OUTinfinito.it> wrote:
>
>>> IIRC C30 doesn't have a built-in macro/function for DISI, requiring
>>> you to know what the assembler instruction would be if you are
>>> programming in C. So you'd kind of have to know assembler already.
>> And that doesn't make it portable I'm afraid.
>>
> Sure it is. If you want to port your code to another processor you put
> all of your low-level hardware abstraction into defined locations (in
> the source code) so that you know what to change when you move to a
> different processor.


It seems that we think similarly (see my post, one minute later than yours)..


>
> I'm of course ignoring all reasonable questions as to why you would
> need to port your whole project to different microcontroller anyway.


Don't need to be the whole project, it may be some functional part of it
that you want to incorporate in a different product.

By the way, I already did that. Ported an entire project to a completely
different MCU, from a PIC16F876 to an ATMega8535L, by request of our
Korean partner.


Isaac

2011\10\21@162027 by jana1972

flavicon
face
Thank you ALL who replied to my question about the programming languages.
I decided for assembly language because it will help me to better understand how microchips work.But in the future I may move to C because of  code productivity :-)
Thanks again
L.

2011\10\22@181716 by Gerhard Fiedler

picon face
Dwayne Reid wrote:

> At 01:27 PM 10/20/2011, Peter Johansson wrote:
>
>> My suggestion is that you learn C and assembly side-by-side.  Write
>> all of your small sample programs in both C and assembly, and then
>> compare the code the C compiler generates with your own code.
>> Knowledge of just how your compiler does things can really help when
>> stepping through your code in the debugger.
>>
>> Chances are you will probably wind up coding entirely in C,
>> particularly if your compiler has a very good optimizer for your
>> MCU, but the time spent learning assembly will be time well spent.
>
> I've been deliberately staying out this discussion (I don't grok 'C',
> so I code exclusively in Assembler), but I think that the above
> advice is the best suggestion.
>
> If you already code in 'C' for other processors, it should be a short
> learning curve.
>
> Great advice, Peter.
Agreed. The first thing on a new architecture that I do is to read the
architecture and assembly manuals, then look at compiler-generated code
and try to understand it.
What most arguments of the type "you need to understand assembly anyway"
seem to miss is that there is a huge difference between being able to
(slowly) read and understand assembly (which I agree is necessary,
together with an understanding of the architecture), and being able to
efficiently write assembly. Programming in C doesn't make the first part
unnecessary, but the second part. You don't have to memorize all the
assembly commands, which flags they affect etc... that's the compiler's
job; I just have to know the general outlines of the architecture -- and
where I can look up the details in case I need them.

Gerhar

2011\10\23@004140 by RussellMc

face picon face
> What most arguments of the type "you need to understand assembly anyway"
> seem to miss is that there is a huge difference between being able to
> (slowly) read and understand assembly (which I agree is necessary,
> together with an understanding of the architecture), and being able to
> efficiently write assembly. ...

Many would agree substantially.
Except

> ... in case I need them.

Should be

" ... when I need them." :-)

__________________________________

Real women (and men) write in machine code :-)

FWIW - the eg MC6800 makes this easy. The 8080 makes it hard. The Z80
adds icing to the 8080 cake.
Modern processors will generally be hard due to lack of logically
grouping related bits in instructions. This is because there is no
need to do so for a machine processed instruction set, which makes one
wonder what the 6800 instruction set builders had in mind.



          Russel

2011\10\23@173254 by William \Chops\ Westfield

face picon face

On Oct 22, 2011, at 9:40 PM, RussellMc wrote:

> Real women (and men) write in machine code :-)
> The 8080 makes it hard.

Bah.  Not if you write your machine code in octal like you're supposed  to!

BillW

2011\10\23@184643 by Chris McSweeny
picon face
On Sun, Oct 23, 2011 at 5:40 AM, RussellMc <spamBeGoneapptechnzSTOPspamspamEraseMEgmail.com> wrote:
> FWIW - the eg MC6800 makes this easy. The 8080 makes it hard. The Z80
> adds icing to the 8080 cake.

I presume it doesn't count if you started with assembly and hand
assembled to hex? I can't be the only person to start my low level
programming career with a ZX81, armed only with a manual and a hex
editor.

Chri

2011\10\23@190416 by Bob Blick

face
flavicon
face


On Sunday, October 23, 2011 11:46 PM, "Chris McSweeny"  wrote:
> On Sun, Oct 23, 2011 at 5:40 AM, RussellMc <KILLspamapptechnzspamBeGonespamgmail.com> wrote:
> > FWIW - the eg MC6800 makes this easy. The 8080 makes it hard. The Z80
> > adds icing to the 8080 cake.
>
> I presume it doesn't count if you started with assembly and hand
> assembled to hex? I can't be the only person to start my low level
> programming career with a ZX81, armed only with a manual and a hex
> editor.

Hello Brother!
You're not the only one. I made an audio digital delay with one, using a
ADC0820 A/D converter, a D/A like maybe the DAC0801 and an NE570
compandor for noise reduction. With a 64K third-party ram expansion.
That's about all I remember about it.

Cheers,

Bob

-- http://www.fastmail.fm - Choose from over 50 domains or use your own

2011\10\23@191208 by IVP

face picon face
> I can't be the only person to start my low level programming
> career with a ZX81, armed only with a manual and a hex editor

My very first exposure to a major construction project and personal
computing was the ETI-660. In at the deep end

http://mattmik.com/eti-660/

Based on the RCA 1802. Still have it

All programming was in hex through the keys. (remember hex
listings in magazines like Compute ! No downloads in those days)

After that introduction the fully-featured Commodore 64 was a
relative doddle to do assembly on, and 68HC and PICs after that

Jo

2011\10\23@204524 by jim

flavicon
face
My start was on a Netronics Super ELF.  I had a Video chip, a HEX keypad,
and 256 bytes of RAM.
I could display the starship Enterprise on a video monitor with that
computer.  And it only took
about 10 minutes to type in the program.
After the oohs and aahs subsided, I would then take another 10 minutes or so
to type in a different
Program to do some other bit of magic.  
Ah, the days gone by.

Jim
{Original Message removed}

2011\10\23@204846 by William \Chops\ Westfield

face picon face
>>> The 8080 makes it hard.
>>
>> Not if you write your machine code in octal
>
> the RCA 1802

Now the 1802 has nice hex-based instructions (16 registers, after all.)

But I remember being really annoyed when all the hobby publications  started using hex for 8080/z80 code, because it really does obscure  the architecture.  (7 registers plus memory.  Nice octal fields.   111=A (Accumulator), 000=B 001=C 010=D 011=E 100=H 101=L 110=M (Memory  reference through address in H:L))  MUCH easier.
All to save 33% keystrokes or paper tape length, I guess.

Hopefully front panels did the bit grouping better...

BillW

2011\10\23@210506 by IVP

face picon face
>> the RCA 1802
>
> Now the 1802 has nice hex-based instructions (16 registers, after all.)

Ah, SE

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...