You don't need to change to assembler. Access to hardware registers is the same as in C.

Compare:

bsf LATA, 2

LATABits.LATA2 = 1;

I imagine how easy it would be for you guys to translate from one to the other, but my experience with Assembly is very limited -just did a few subroutines 20 years ago for an 8088 and practically forgot everything-, and with my current knowledge of PIC programming I wouldn't be able to; probably not even a one liner like that one...

much less something like this that I just saw on the datasheet:

EXAMPLE 7-2: READING A 16-BIT FREE RUNNING TIMER

; All interrupts are disabled
MOVF TMR1H, W ; Read high byte
MOVWF TMPH
MOVF TMR1L, W ; Read low byte
MOVWF TMPL
MOVF TMR1H, W ; Read high byte
SUBWF TMPH, W ; Sub 1st read with 2nd read
BTFSC STATUS, Z ; Is result = 0
GOTO CONTINUE ; Good 16-bit read
; TMR1L may have rolled over between the read of the high and low bytes.
; Reading the high and low bytes now will read a good value.
MOVF TMR1H, W ; Read high byte
MOVWF TMPH
MOVF TMR1L, W ; Read low byte
MOVWF TMPL ; Re-enable the Interrupt (if required)
CONTINUE ; Continue with your code

 

Don't read the assembler part, read comments:

// All interrupts are disabled
TMPH = TMR1H; // Read high byte
TMPL = TMR1L; // Read low byte
if (TMR1H ==  // Read high byte
   TMPH)      // Sub 1st read with 2nd read
              // Is result = 0
goto CONTINUE;// Good 16-bit read
// TMR1L may have rolled over between the read of the high and low bytes.
// Reading the high and low bytes now will read a good value.
TMPH = TMR1H; // Read high byte
TMPL = TMR1L; // Read low byte
              // Re-enable the Interrupt (if required)
CONTINUE:     // Continue with your code

 

Don't read the assembler part, read comments:

// All interrupts are disabled
TMPH = TMR1H; // Read high byte
TMPL = TMR1L; // Read low byte
if (TMR1H ==  // Read high byte
   TMPH)      // Sub 1st read with 2nd read
              // Is result = 0
goto CONTINUE;// Good 16-bit read
// TMR1L may have rolled over between the read of the high and low bytes.
// Reading the high and low bytes now will read a good value.
TMPH = TMR1H; // Read high byte
TMPL = TMR1L; // Read low byte
              // Re-enable the Interrupt (if required)
CONTINUE:     // Continue with your code

Yes, I know. But from there I still won't be able to use it in C; since it's not telling me, nor I know, the instructions that I need to use.

 

So do I

You can connect to a PC using the UART or USB. You need to have a PIC that contains those interfaces. I also connect with SPI and I2C.

I have bit banged serial and I2C on a very small PIC's with no internal interfaces.

 

So your plan is to use an existing RS232 serial port on the computer, or to use a USB virtual port?
You somewhere around page 4 linked to a thread where you say that you need specifically COM3 for some kind of a bizzare program that can´t use any other number, do you realize that you can swap the number of the port in the device manager? And that the com number for each serial port is different on each computer, so that the customers willl basically have to change it if you want this to work for everyone?

 

So your plan is to use an existing RS232 serial port on the computer, or to use a USB virtual port?

Neither; I need to connect a device via USB with its own hardware port.

You somewhere around page 4 linked to a thread where you say that you need specifically COM3 for some kind of a bizzare program that can´t use any other number, do you realize that you can swap the number of the port in the device manager? And that the com number for each serial port is different on each computer, so that the customers willl basically have to change it if you want this to work for everyone?

I never said it has to connect to COM3; I said it has to connect to a hardware COM port, not a CDC or virtual port. COM3 is the port used by Arduino Leonardo's bootloader, and COM4 is a CDC for serial communications. The program can't connect to a CDC -the one in COM4- it can only connect to COM3, since this is the only hardware COM port available.

Why would it matter if I change the COM port? the CDC would simply be opened on the next port available to the hardware port used by the bootloader.

 

Neither; I need to connect a device via USB with its own hardware port.

I don't think I quite understand what you mean by that. If by hardware port you mean a real RS232 port inside a PC, then I think you cannot use USB in any form as you say it doesnt work with virtual com ports.

Seems to me there is some misunderstanding about what constitutes a hardware port. All serial ports over USB cable are virtual, as USB is a completely different beast so the serial port needs to be emulated as a virtual com port. As oposed to a hardware port, i.e. a physical connector that is coming right off the PC's motherboard or PCI card.

note: there may be more than one virtual port going through that usb cable, so maybe that is why you call them hardware and virtual, but for sure both are virtual.

 

Also you said this

Yes, the other programs work fine; for example: with a serial monitor I can see the data in/out fine through the virtual COM port 4. It's only the software I'm targetting that requires COM port 3, and listen to this... only for input (output works fine on COM port 4).

which lead me to believe said program only works with COM3. I am a bit confused about what you are actually trying to achieve, but it seems to me that the bootloader program is still holding that port open so you cant write to it.

 

Also you said this which lead me to believe said program only works with COM3. I am a bit confused about what you are actually trying to achieve, but it seems to me that the bootloader program is still holding that port open so you cant write to it.

That problem is fixed now. It was because the Arduino Leonardo, Micro and Yun don't use the hardware port for serial communications -as all other Arduinos-; it's only opened by the bootloader on start and then closed. Then, once the bootloader closes the hardware COM port, a new CDC port is opened on the next available port for use by your programs.

I described it in full here: COM port on the Arduino Leonardo

 

Now that I'm still a complete beginner with PICs, I'm doubting about starting with Assembly instead of C. The main reason is that most of the tutorials, manuals, and reference guides -including all the datasheets- are in Assembly.

What would you recommend?

Or putting it in another way: Which language do you use, and why you chose that one over the other?

 

Or putting it in another way: Which language do you use, and why you chose that one over the other?

I use Assembler most of the time, mostly because PICs look too small to me to justify C.

I believe it is a matter of personal preference. Most people prefer C.

 

I usually use assembly on 16F pics because they are not well suited for C, as least the smaller ones. I have used C sometimes on the larger ones.

I use C on 18F, 24F, and 33F because they have an instruction set better suited to C and are typically larger in memory.

Bob

 

Oooooooh! Another C vs. .asm degeneration -- almost missed it!

Can't wait to see how this turns out!

 

Oooooooh! Another C vs. .asm degeneration -- almost missed it!

Can't wait to see how this turns out!

Oh, come on!!!

Now no one is going to answer.

 

I use Assembler most of the time, mostly because PICs look too small to me to justify C.

I believe it is a matter of personal preference. Most people prefer C.

I usually use assembly on 16F pics because they are not well suited for C, as least the smaller ones. I have used C sometimes on the larger ones.

I use C on 18F, 24F, and 33F because they have an instruction set better suited to C and are typically larger in memory.

Bob

Thanks for answering...

What I noticed is that there are barely any commands or instructions in C specific for programming PICs; it's just the variables and structures to manipulated the registers. For this reason I was also wondering what's the point of using C; specially since there are only around 30 instructions in Assembly for PICs.

On the other hand, since C is a much higher level language, and since I'm more familiar with it (barely remember any Assembly), it would make it easier to do everything else that surrounds the register manipulation. For example: I would have no idea how to make a simple "switch", "for...to...next", and so on.

 

Exactly, the main advantage of using C is the clarity of the code. You can see at a first glance what that function is doing, unlike asm where you have to go through all the conditional jumps and unfamiliar instructions to see what that part of code is meant to do.

Because you say you have at least some experience with C, than C is definitely the way to go for you. You would spend a lot of time learning the internals of the processor, flags and page registers and various other things, instead of writing clear code that works right away.

 

Exactly, the main advantage of using C is the clarity of the code. You can see at a first glance what that function is doing, unlike asm where you have to go through all the conditional jumps and unfamiliar instructions to see what that part of code is meant to do.

Because you say you have at least some experience with C, than C is definitely the way to go for you. You would spend a lot of time learning the internals of the processor, flags and page registers and various other things, instead of writing clear code that works right away.

Yes, I also thought C was the way to go. I'm just doubting because most of the examples I find on the internet are in Assembly; so I was wondering what would be easier for me, and what would take me less time: learn how to pass those examples to C, or start in Assembly from scratch.

I guess the ideal would be to learn both; but I don't think I would be able to spend that much time on this.

 

Many of the the examples I'm finding use latch (LATx) to send data to the I/O pins, but it seems that the 2 PICs I have at home don't have this feature; so I'm using port (PORTx) instead.

What's the LATx for; and why some PICs don't have it?
What are the differences between using LATx and PORTx?

Thanks...

 

Many of the the examples I'm finding use latch (LATx) to send data to the I/O pins, but it seems that the 2 PICs I have at home don't have this feature; so I'm using port (PORTx) instead.

What's the LATx for; and why some PICs don't have it?
What are the differences between using LATx and PORTx?

Thanks...

Problem with PORTx is that when you read from them it goes directly from the pin, which produces several kinds of problems. To avoid these problems, Microchip introduced LATx. All non-dinosaur age PICs, including PIC16F1459, have LATx.

 

I see, so LATx is a later implementation to avoid the problems you mentioned with PORTx.

I tried LATx on both the PIC16F88 and PIC16F887 that I have at home, and none support it.

If I knew about these things before I would have ordered all 18F instead of 16F.