1. Dawud Beale

    Thread Starter Member

    Feb 10, 2012
    275
    7
    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
     
  2. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    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.
     
  3. Dawud Beale

    Thread Starter Member

    Feb 10, 2012
    275
    7
    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
     
  4. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,395
    1,607
    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.

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

    Senior Member

    May 10, 2008
    487
    71
    Last edited: Feb 24, 2013
  6. atferrari

    AAC Fanatic!

    Jan 6, 2004
    2,653
    768
  7. atferrari

    AAC Fanatic!

    Jan 6, 2004
    2,653
    768
    Last edited: Feb 20, 2013
  8. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,395
    1,607
  9. atferrari

    AAC Fanatic!

    Jan 6, 2004
    2,653
    768
    Gracias for the warning. It was corrected in the post.
     
    ErnieM likes this.
  10. Markd77

    Senior Member

    Sep 7, 2009
    2,803
    594
    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.
     
    Dawud Beale likes this.
  11. MMcLaren

    Well-Known Member

    Feb 14, 2010
    759
    116
    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

    Code ( (Unknown Language)):
    1. ;
    2. Put232                          ; 19200 baud Tx subroutine
    3.         movwf   txbyte          ; save Tx data byte               |B0
    4.         movlw   10              ; 1 start + 8 data + 1 stop bit   |B0
    5.         movwf   BitCtr          ; setup bit counter               |B0
    6.         clrc                    ; C = 0 (start bit)               |B0
    7.         goto    SendBit         ; send start bit                  |B0
    8. NextBit
    9.         inDlyCy(52*usecs-10)    ; 52 usecs -10 cycle loop time    |B0
    10.         setc                    ; always shift in a 'stop' bit    |B0
    11.         rrf     txbyte,F        ; put data bit in Carry           |B0
    12. SendBit
    13.         movf    GPIO,W          ; read port                       |B0
    14.         iorlw   1<<TxPin        ; set TxPin bit to 1              |B0
    15.         skpc                    ; if data bit = 1 skip, else      |B0
    16.         xorlw   1<<TxPin        ; set TxPin bit to 0              |B0
    17.         movwf   GPIO            ; precise "bit Time" intervals    |B0
    18.         decfsz  BitCtr,F        ; done? yes, skip, else           |B0
    19.         goto    NextBit         ; send next bit                   |B0
    20.         return                  ;                                 |B0
    21. ;
    22. Get232
    23.         btfss   GPIO,RxPin      ; start bit (1)? yes, skip, else  |B0
    24.         goto    Get232          ; loop (wait for start bit)       |B0
    25.         DelayCy(52*usecs/2)     ; delay 1/2 bit time              |B0
    26.         movlw   8               ;                                 |B0
    27.         movwf   BitCtr          ; BitCtr = 8                      |B0
    28. RxBit
    29.         DelayCy(52*usecs-7)     ; precise 52-usec bit timing      |B0
    30.         clrc                    ; assume '0'                      |B0
    31.         btfss   GPIO,RxPin      ; a '0' bit? yes, skip, else      |B0
    32.         setc                    ; set to '1'                      |B0
    33.         rrf     rxbyte,F        ; b0 first, b7 last               |B0
    34.         decfsz  BitCtr,F        ; done? yes, skip, else           |B0
    35.         goto    RxBit           ; get another bit                 |B0
    36.         movf    rxbyte,W        ; put "rxbyte" in WREG            |B0
    37.         return                  ;                                 |B0
    38.  
    39.  
     
    Dawud Beale likes this.
  12. Dawud Beale

    Thread Starter Member

    Feb 10, 2012
    275
    7
    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
     
  13. atferrari

    AAC Fanatic!

    Jan 6, 2004
    2,653
    768
    Hola Mike,

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

    Google directs me to PERL but I am not conversant.

    Just a brief definition or a link would be enough.

    Gracias.
     
  14. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,395
    1,607
    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.
     
  15. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    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.
     
  16. Markd77

    Senior Member

    Sep 7, 2009
    2,803
    594
    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).
     
    Dawud Beale likes this.
  17. Dawud Beale

    Thread Starter Member

    Feb 10, 2012
    275
    7
    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
     
  18. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    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.
     
  19. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    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?
     
  20. Dawud Beale

    Thread Starter Member

    Feb 10, 2012
    275
    7
    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
     
Loading...