Hi everyone

I was just wondering, how difficult would it be to program a USB handler instead of using an RS232 serial connection for a microcontroller?

Is there any tutorials? I'm using a PIC and intend to write my program in C.

Also does anyone have any materials that may be useful for writing a software USART RS232 in MPASM assembley?

Thank you in advance

 

1. There is ready to use code available from Microchip.
The so called USB stack.

There are also new 16F PICs not needing a crystal for USB.

2. Forget about it in my opinion. Assembler = lots of worries. People spend weeks and then they praise an effervescent complicate and fragile assembler construct for the fact alone it works.

2 years later they can not understand it anymore themselves- a good excuse as well it can not be maintained.

The same problem takes an hour in C, a few hours maybe. It can be maintained easily.

Yes there is an AN (application note) for a software USART at 2400 baud.

But why? Use C for that, if you need better speed, use a PIC with USB host capability.

The tradeoff using C is just marginal.

The problem is the synchronization. Which will require extra lines and will make your assembler code even more complicated. Supposed the PIC is doing something else than only transmitting data. How can you detect that without a hardware serial port? At best, you can use hardware interrupt (if you have free I/O). The other resort is a very low speed like for instance 2400 kbps.

 

We are required to do it for Uni so unfortunately i won't get any marks for not doing it and justifying why lol. Where can I find this AN? I need to do it an 9600 Baud rate so is that easily changed? Any tutorials, examples or links will be helpful so I can look through them. Thanks

 

I was just wondering, how difficult would it be to program a USB handler instead of using an RS232 serial connection for a microcontroller?

Is there any tutorials? I'm using a PIC and intend to write my program in C.

The projects located at "...\Microchip Solutions\USB\Device - CDC - Serial Emulator" in the Microchip Application Library (free download) work well with the (free) compilers. The PIC works as an exchange to accept data off the USB and send it over the RS232 Tx, and receive over the RS and send back over the USB.

On the PC end it all looks like any COM device. Inside the PIC it's easy to insert your own code and change the functionality to something else. I've used it a few times when I need to control some I/O pins, USB output data is redirected to port latches instead of the RS232.

The MC documentation is sparse but the code itself is pretty well documented.

Also does anyone have any materials that may be useful for writing a software USART RS232 in MPASM assembley?

Don't know of any, and good lord why would you do that?

 

You can get a full project (PIC code and PC code) from www.waitingforfriday.com

 

You can get a full project (PIC code and PC code) from www.waitingforfirday.com

The correct URL is www.waitingforfriday.com

 

Brad Minch did it.

Look for it here. http://www.microchip.com/forums/tm.aspx?m=89669&high=brad+minch#

All his labs work.

One of the very few long threads I've read in full in my life.

 

Brad Minch did it.

Look for it here. PIC18F2455/4455 Assembler USB Firmware Available

The link is a 404.

 

The link is a 404.

Gracias for the warning. It was corrected in the post.

 

Also does anyone have any materials that may be useful for writing a software USART RS232 in MPASM assembley?

Try Microchip AN510
It's also the first result if you search for "microchip soft serial"
It's even easier on chips with timer interrupts, but gives the general idea.

 

Also does anyone have any materials that may be useful for writing a software USART RS232 in MPASM assembly?

For what processor? Blocking subroutine or interrupt driven?

There's an interrupt driven 9600 baud example for 12F683 on PICLIST.

You can use subroutines but you really have to know what you're doing and when to expect data. I have used a couple routines that will work with almost any clock by using a cycle accurate delay subsystem. Here's what the routines look like (below);

Good luck. Cheerful regards, Mike

;
Put232                          ; 19200 baud Tx subroutine
        movwf   txbyte          ; save Tx data byte               |B0
        movlw   10              ; 1 start + 8 data + 1 stop bit   |B0
        movwf   BitCtr          ; setup bit counter               |B0
        clrc                    ; C = 0 (start bit)               |B0
        goto    SendBit         ; send start bit                  |B0
NextBit
        inDlyCy(52*usecs-10)    ; 52 usecs -10 cycle loop time    |B0
        setc                    ; always shift in a 'stop' bit    |B0
        rrf     txbyte,F        ; put data bit in Carry           |B0
SendBit
        movf    GPIO,W          ; read port                       |B0
        iorlw   1<<TxPin        ; set TxPin bit to 1              |B0
        skpc                    ; if data bit = 1 skip, else      |B0
        xorlw   1<<TxPin        ; set TxPin bit to 0              |B0
        movwf   GPIO            ; precise "bit Time" intervals    |B0
        decfsz  BitCtr,F        ; done? yes, skip, else           |B0
        goto    NextBit         ; send next bit                   |B0
        return                  ;                                 |B0
;
Get232
        btfss   GPIO,RxPin      ; start bit (1)? yes, skip, else  |B0
        goto    Get232          ; loop (wait for start bit)       |B0
        DelayCy(52*usecs/2)     ; delay 1/2 bit time              |B0
        movlw   8               ;                                 |B0
        movwf   BitCtr          ; BitCtr = 8                      |B0
RxBit
        DelayCy(52*usecs-7)     ; precise 52-usec bit timing      |B0
        clrc                    ; assume '0'                      |B0
        btfss   GPIO,RxPin      ; a '0' bit? yes, skip, else      |B0
        setc                    ; set to '1'                      |B0
        rrf     rxbyte,F        ; b0 first, b7 last               |B0
        decfsz  BitCtr,F        ; done? yes, skip, else           |B0
        goto    RxBit           ; get another bit                 |B0
        movf    rxbyte,W        ; put "rxbyte" in WREG            |B0
        return                  ;                                 |B0

 

I am using a PIC12f1822 which I believe is interupt driven. Thanks I'll have a look through your code and see if I can follow it and understand it and learn from it

 

Blocking subroutine or interrupt driven? [/code]

Hola Mike,

What is a blocking subroutine? First time I heard of it.

Google directs me to PERL but I am not conversant.

Just a brief definition or a link would be enough.

Gracias.

 

What is a blocking subroutine? First time I heard of it.

A "blocking subroutine" in this context is a generic term (ie not PERL specific) meaning a routine that sits and waits until it's task is complete.

For example, most delay functions are blocking functions: you enter a delay and do not return until the delay is complete.

 

I am using a PIC12f1822 which I believe is interupt driven. Thanks I'll have a look through your code and see if I can follow it and understand it and learn from it

Take it as a word from someone who used assembler over years.

After 2 weeks your assembler construct indeed does what it should. It works. For that matter alone the author will be proud. It will be fragile and complicated and it will only run on specific controllers.

Other people will have a hard time understanding the code.

C language.

1 hour, very simple code, very few lines, easy to read. Bury it, forget about it. Runs on any controller.

If they demand from you to program a software USART for educational purpose, they are way back 20 to 30 years in time.

I'd refuse to do it in assembler. If it can not be easily done in C as well, hardware USART must be used. If it is NOT clear why a hardware USART can not be used? What is clear then?

The days in which programmers consulted instruction cycle times for programming and added the cycles, luckily these are over.

I have even seen a USB stack written in assembler. Yes it is actually possible. Horrific to read through it.

If you'd like to see or consult some assembler wizards, there is even a forum for that- 80x86/MASM related. Arrogance almost guaranteed, and fetishism over a few clocking cycles. When you get up in the morning and continue with your assembler project the first thought will be- How can I optimize it further? And the second: What was that bit good for again? 2 hours later that would be clear.

Years ago, I really wrote programs in 8086 assembler. COM files and even EXE files. The largest assembler source I wrote was about 300K. I do not wish back these times.

Hope you get your PIC stuff started soon.

 

I put the timer interrupt code for one I use for 9600 baud on this thread:
http://forum.allaboutcircuits.com/showthread.php?t=81343

Not very well commented, and there are a few magic numbers, but if you have a good grasp of assembler you should be able to figure it out easily enough.
It's only designed to be half duplex (doesn't send and receive at the same time) and may need a few changes for PIC12F1822 including the value loaded into TMR0 (unless you are also using 8MHz).

 

takao unfortunately I wont get a degree if I refuse to do the work. Many people did a hardware UART instead of a software UART and he failed them and asked them to redo it because they didnt design to spec.

No degree no job.

So I really don't have a choice.

We are learning C now and have to do all the same projects again in C. The idea is to teach us the difference between using C and Assembler.

The reason for programming a software UART is because not all PICs have a hardware UART

 

takao unfortunately I wont get a degree if I refuse to do the work. Many people did a hardware UART instead of a software UART and he failed them and asked them to redo it because they didnt design to spec.

No degree no job.

So I really don't have a choice.

We are learning C now and have to do all the same projects again in C. The idea is to teach us the difference between using C and Assembler.

The reason for programming a software UART is because not all PICs have a hardware UART

Does he insist on asynchronous software USART? I'd complain about him. That's too much demanded from a student. Even a synchronous software USART is not so easy.

There is not just the serial transfer as such, also the tristate and the start condition need to be programmed accurately as well timeout. It is quite a hassle to do it right.

And I use PICs for years.

For a synchronous serial I/O, I use a trick to get rid of the timeout and start condition (remember on both sides). I simply reset the slave processor with a hard MCLR, then loop for the clock signals.

So even that takes a while to do it properly for high clock frequency.

I'd also complain because cycle counting is no longer relevant for the world of work. It is a waste of precious time.

Maybe he can agree on a synchronous serial port. That's enough of a fine piece of work.

 

I mentioned "Assembler" to a manager in a professional engineering company in the year 2000. He said "Assembler is dead".

Remember this was more than 10 years ago.

Having these cheap new USB PICs, the places where a software USART is programmed will be quite limited to a few instances.

Working out a fully fledged asynchronous serial port- in the world of work most managers would say waste of time.

In most cases take whatever is available as chips and move on.

Also did your teacher mention or discuss I2C? That is as much as a prerequisite before trying to program a software USART. It is easier because the timing is asynchronous.

Did you use I2C before at all?

 

No we never used I2C yet in class. It was mentioned and thats about it.

I don't doubt that most of what I'm learning is older technology, not just in Embedded but in all subjects, but it's to give you a grounding of the principles.

Obviously I will be aiming to get up to date with the latest technology when I'm in the working environment.

I start work on jet engine control systems for a year starting in July and that opportunity has only arisen due to my going to Uni so my degree is opening up opportunities for me regardless of whether it's the most up to date technology or not.

We're programming GALs in digital and thats also obsolete and we progammed them using ABEL which has also been replaced by VHDL and Verilog, and the circuits we learned for power supplies and voltage regulation are old tech now but the idea is just to ground you in the basic ideas.

I don't think I'd want to take a course that starts off by teaching the latest industry developments because technology gets more complicated with time.

The wright brothers designed a whole aircraft but now it takes 10,000 people to do the same thing