Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

16f and 18f

Status
Not open for further replies.
3v0 said:
As I have said in the past, the quality of the tutorial or instruction is more (much more) important then the language used. You can teach people structured programming in pic assembly, or write butt ugly code in the latest greatest language, that sort of thing.

Yes, which was why Pascal was used, because it's well structured and forces good programming practice.

In an ideal world poeple would not touch uC's till after they were fluent in a high level language. Understood how to write clean code, that sort of thing.

Again, I would disagree, and yet again historically this wasn't the way it was taught - students weren't allowed to use a high level language until they had mastered machine code.

The mass of C questions does not show that people should learn assembler first.

I would say it does, because the questions generally are so trivial they wouldn't be asked if the poster had a little knowledge of assembler and PIC hardware.

I was surprised to see the number of PIC Pascal compilers that I found on the web.

I like Pascal. But like forth it is not main stream.

It was main stream, and (like I said before) was the high level teaching language of choice.

Spend less time with "my language is better then yours" and more time on what quality code is.

We're not discussing which language is 'better' than another, we're discussing where it's 'best' to start.
 
BeeBop said:
As far as assembly is concerned, I don't think it is a good vehicle for teaching programming, but it is the best choice for learning exactly how the hardware works.

I don't think assembler is a good vehicle for learning 'programming' either, but (as I've said all along) it forces you to understand the hardware - people are approaching PIC programming with a C compiler and a little plastic thing with lots of legs - then asking silly questions because they don't have the slightest idea what's inside the little plastic thing! :p
 
blueroomelectronics said:
I've been using Swordfish basic and in all the examples they use while/wend and in many cases for/next would be my first choice.


As I'm sure you know, while/wend is a conditional loop (which may not run even once), and for/next is a loop that runs a certain set number of iterations.

Presumably they are using a counter variable to make while/wend run a certain number of times?.

I supplied repeat/until in my BASIC compiler as well, here's a list of the commands:

**broken link removed**

Sorry, but it's not available for download :(

It was (and is) very fast though, and produces fairly nice readable code.
 
Let me jump in to discussion, I already knew C++ before I started with asm, and to be honest c++ was, I wouldn't say easier but much intuitive.

When I started learning registers, flags I realized how 'wasteful' I was. How some simple operation are now hard to implement.
And maybe it's weird, but I stopped programming in c because I simply love asm, control over every register, over every bit, the pure power, speed and minimal use of memory.

Now it's time to pass to 18f, but I'm divided between asm and c, fact is I will never do in asm what I can with c.

Ohh, and I would say definitely go with 16f and asm for start, with some knowledge of high language to see you prior mistakes and 'wastefulness'.
 
Last edited:
Most of the software I write is timing critical and like jhanus I love the ability to program almost at hardware level.

I'll spend hours on code to get precise timings and interrupts. While 20us error might be acceptable to some people the knowledge that my code will be more accurate than the crystal driving it gives me a nice warm feeling.

I think I need to get out more :p
 
Nigel,

You do not know that these clueless people would be better off with machine language. To some degree these people would not be asking silly questions if they took the time to read datasheets and manuals. That flaw is language independent.

CS education at the U level starts as far from the hardware as they can take the student. They are not allowed in uC classes till after they know how to program. Only then do they see machine language.

What we say or think is far from proof. It takes a study to find out. There are too many unknowns regarding the 'sample' seen here. Any conclusion based on it is flawed.

I ran UCSD Pascal on my H-11. :)

Programming at the machine level is on the way out. As processors become more powerful and less expensive it will become rare to use machine language outside of education or hobby programming. Even the need to understand the peripherals will become less important.
 
3v0 said:
Nigel,

You do not know that these clueless people would be better off with machine language. To some degree these people would not be asking silly questions if they took the time to read datasheets and manuals. That flaw is language independent.

But the datasheets and manuals are almost exclusively written using assembler, no C examples at all - so the exclusively C (or BASIC or whatever) programmer can't understand the datasheet, and probably never even looks at it?.

If the datasheets were written from a C point of view, I would have no problem at all with people starting directly in C - they would know what they are doing (or at least have the information available!).

So the problem, as I see it, isn't down to 'C' it's down to any language not covered in the datasheets - and regardless of your view, micro-controllers don't run C, they run machine code.
 
Nigel Goodwin said:
But the datasheets and manuals are almost exclusively written using assembler, no C examples at all - so the exclusively C (or BASIC or whatever) programmer can't understand the datasheet, and probably never even looks at it?.So the problem, as I see it, isn't down to 'C' it's down to any language not covered in the datasheets
You are correct.
I will provide edited datasheets to my students that contain both ASM and C examples. I know that does not help others.

- and regardless of your view, micro-controllers don't run C, they run machine code.
:D True, but it does not make high level languages are any less useful.

A part of me is strongly in favor of machine code. At the very least firmware people should know how to read/understand the code generated by their compiler. I would like to chain people to a bench and teach them machine code in combo with computer architecture. But it is not a realistic thing to do and I would not do it as a first language.

This may seem to contradict what I said earlier about machine code being on the way out. What I want and what reality is do not always mesh.
 
3v0 said:
You are correct.
I will provide edited datasheets to my students that contain both ASM and C examples. I know that does not help others.

No, but it helps YOUR students, which is what really matters, and removes my concerns about lack of assembler knowledge.

You could always post your edited data sheets on a website somewhere, or even here if that would be helpful?.
 
Well here's my view and as I'm slowly (yes it's a lot of work) putting a book together with the help of several forum members.

The 16F has plenty of source material and scads of books, it's well covered.

So this book will cover what's not nearly as well covered the 18F
With the big three languages starting with

BASIC
  • The easiest language to pick up for almost any platform
  • Structured & Modular (not your dads BASIC for sure)
  • Supports inline assembly
  • Free Swordfish SE version will be used
then
C18
  • The serious language for PIC, you'll need it eventually
  • 18F libraries available for USB, Ethernet, etc...
  • Stepping stone to the 16bit and 32bit PICs and other microcontrollers
  • Portable code libraries
  • Supports inline assembly
  • Free C18 SE version will be used
then
Assembler
  • The language of the PIC Gurus
  • To understand any microcontroller you'll need to understand how it thinks
  • Fast & efficent
  • If you can't do it with asm then it can't be done
  • Free MPASM version will be used
 
3v0 said:
I will provide edited datasheets to my students that contain both ASM and C examples. I know that does not help others.
That's a good idea. Scott Dattalo has been providing pseudo C code at the top of his assembly language examples for years. I think it's an idea we all should consider when we publish or share our code;

Code:
;
;  increment RTC once per second
;
;  unsigned char Clock [] = { 23, 59, 59 };  // hrs, mins, secs
;
;  RTC ()                       // bump RTC
;  { unsigned char n = 2;       // index seconds array element
;    while (Clock[n]++ == 59)   // while value 59 (post inc value)
;      Clock[n--] = 0;          // set to 00 and bump array index
;    if (Clock[0] == 24)        // if rollover to 24:00:00
;      Clock[0] = 0;            // change to 00:00:00
;  }
;
ISR_RTC
        movlw   Clock+2         ;                                 |B0
        movwf   FSR             ; FSR = @Clock[2]   // seconds    |B0
ISR_R1
        movf    INDF,W          ; while (Clock[n]++ == 59)        |B0
        incf    INDF,F          ;                                 |B0
        xorlw   d'59'           ;                                 |B0
        bnz     ISR_R2          ;                                 |B0
        clrf    INDF            ;   Clock[n] = 0;                 |B0
        decf    FSR,F           ;   n--;                          |B0
        goto    ISR_R1          ;                                 |B0
ISR_R2
        movf    Clock+0,W       ; if (Clock[0] == 24)             |B0
        xorlw   d'24'           ;                                 |B0
        bnz     ISR_ALM         ;                                 |B0
        clrf    CLKHRS          ;   Clock[0] = 0;                 |B0
;
 
Last edited:
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top