Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 16:25 26 Apr 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : PIC16f1455 USB to Serial

     Page 3 of 3    
Author Message
JTR0701
Regular Member

Joined: 10/07/2013
Location: Australia
Posts: 71
Posted: 12:26am 10 Sep 2015
Copy link to clipboard 
Print this post

Avoid using RTS as it does not work on windows prior to windows 10. Well it does sort of work but only when you update DTR so there is not much point. Arduino uses DTR for reset but I believe the AVRs have an active high reset Vs active low for the PICs so keep that in mind if you are putting a R/C network on DTR as some arduinos do.

As it is, RTS and CTS for flow control purposes really are local to the bridge chip and not from the host. There is no point in the host trying to control the hardware flow control as it is just to slow. RTS (when used with DTR) and CTS are only updated or sampled once per usb frame (1mS.) It is just no use for flow control. If you wanted them for flow control (and chances are you don't) the firmware really has to generate the RTS and sample the CTS internally. Just not worth the effort unless you are trying to produce a full blown proper USB - RS232 bridge.
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 12:43am 10 Sep 2015
Copy link to clipboard 
Print this post

JTR, Yes i agree.
It might be better to adapt the code to not use the CTS and RTS pins so that they are free to do something else.

Microblocks. Build with logic.
 
Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280
Posted: 01:29am 10 Sep 2015
Copy link to clipboard 
Print this post

JTR has a point, I don't think I have actually used RTS/CTS since the 80's.
I was just curious as they are provided, but if the DTR works I see no reason to suspect the other two wont.

@TZA I would leave them in as they are needed when talking to XBee and other Radio modules and may come in useful for your modular prototyping boards.

Cheers
Chris

http://caroper.blogspot.com/
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 01:47am 10 Sep 2015
Copy link to clipboard 
Print this post

There are some USB protocol commands that would be nice to bring to the outside world.
The 'Block' i planned for this has an ICSP so that would make it possible to change the firmware to your needs.

A nice function would be to know if the host goes to sleep mode or is shutting down.
A pin could signal that to other connected hardware. Like in sleepmode it would be nice to switch to lower power. Lots of possibilities. I am happy with this particular chip as the sourcecode is reliable and allows modifications.

Microblocks. Build with logic.
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 07:39am 11 Sep 2015
Copy link to clipboard 
Print this post

Got the Microchip USB stack to work. It is a little different then the one posted at the beginning of the thread and uses a bit less memory and flash.
HEX file
If anyone is interested to colaborate on this, the sources are still private as i need to check the USB stack license first. It does allow people to use it and modify it, but unclear if it can be shared as open source.

The schematic of the circuit i will be testing this on can be found on github. This is the URL: https://github.com/MicroBlocks/BBM-Series/tree/master/U2SP5
The diode and mosfet are not really necessary for USB to Serial. They are there to add some extra functionality.

If you want to build and test a circuit, program this hex file into it first to confirm that it works. URLhttps://github.com/MicroBlocks/BBM-Series/tree/master/U2SP5/Software

Edited by TZAdvantage 2015-09-13
Microblocks. Build with logic.
 
piclover
Senior Member

Joined: 14/06/2015
Location: France
Posts: 134
Posted: 11:14am 16 Sep 2015
Copy link to clipboard 
Print this post

  Chris Roper said   OK - Found it. It was July 2014, how time flies I thought it was more recent than that here is the circuit, you need. There was not much supporting text but the circuit is self explanatory:


Hmm... Won't it be possible to invert the signals (including DTR/CTS/RTS: this way, it'd be even easier to interface to a true RS232C with just a few resistors and clamping schottky diodes) in the PIC16F1455 firmware, instead ?Edited by piclover 2015-09-17
 
Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280
Posted: 11:25am 16 Sep 2015
Copy link to clipboard 
Print this post

  piclover said  
  Chris Roper said   OK - Found it. It was July 2014, how time flies I thought it was more recent than that here is the circuit, you need. There was not much supporting text but the circuit is self explanatory:


Hmm... Won't it be possible to invert the signals (including DTR/CTS/RTS: this way, it'd be even easier to interface to a true RS232C with just a few resistors and clamping schottky diodes) in the PIC16F1455 firmware, instead ?


It would be yes, if you had the resources and necessary licence for the compiler optimisations, and could understand the Microchip Stack. A hobbyist on a budget needing a quick way to invert the signals is likely to have a couple of jellybean transistors in the junk box and could build that circuit faster than it takes to load MPLAB X and make a project, let alone modify, compile and test the code.

That circuit will also work with any USB-Serial module too, it is not specific to the PIC16f1455.Edited by Chris Roper 2015-09-17
http://caroper.blogspot.com/
 
piclover
Senior Member

Joined: 14/06/2015
Location: France
Posts: 134
Posted: 11:39am 16 Sep 2015
Copy link to clipboard 
Print this post

  Chris Roper said  
  piclover said  Hmm... Won't it be possible to invert the signals (including DTR/CTS/RTS: this way, it'd be even easier to interface to a true RS232C with just a few resistors and clamping schottky diodes) in the PIC16F1455 firmware, instead ?

It would be yes, if you had the resources and necessary licence for the compiler optimisations, and could understand the Microchip Stack. A hobbyist on a budget needing a quick way to invert the signals is likely to have a couple of jellybean transistors in the junk box and could build that circuit faster than it takes to load MPLAB X and make a project, let alone modify, compile and test the code.

That circuit will also work with any USB-Serial module too, it is not specific to the PIC16f1455.
Well, if you want to invert the full signals of the original circuit described in this thread to get a fully RS232C compatible converter, you'd need 5 transistors plus the associated resistors... This would consume a lot more room on the circuit board while the software "patching" won't change a thing to the circuit itself...
I didn't look at the sources, but I guess it's "just" a matter of inverting the data on the pins at the very lowest level of the "stack". As for the optimizing compiler, are you sure it is needed at all ?
 
Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280
Posted: 12:03pm 16 Sep 2015
Copy link to clipboard 
Print this post

  piclover said  I didn't look at the sources, but I guess it's "just" a matter of inverting the data on the pins at the very lowest level of the "stack". As for the optimizing compiler, are you sure it is needed at all ?


I don't use the Microchip tools, what little C coding I have done is on the PIC32 platform using the opensource GCC compiler with full optimizations available for free.

The XC8 compiler for Microchip you have to pay for Optimizations, without them it actually artificiality inflates your object code by inserting nops and redundant jumps.

Even if it didn't deliberately bloat the code, trying to get a USB stack into a PIC16 is a tight fit, both memory and execution time wise, so I would imagine you need all the optimization you can get.

Maybe ZTA could step in and answer as he is busy working with the source and probably the Microchip Tool Chain.

I do seam to recall that the EAUSART Module in the PIC32 can actually generate inverted output in hardware, but I am not sure if PIC16 can, so it would have to be done in software which adds overhead.

Cheers
Chris

EDIT: If you did need to invert all of the signals with external hardware you may as well use a MAX232 device, rather than 5 transistors it would save the space and boost the signals too.Edited by Chris Roper 2015-09-17
http://caroper.blogspot.com/
 
piclover
Senior Member

Joined: 14/06/2015
Location: France
Posts: 134
Posted: 12:10pm 16 Sep 2015
Copy link to clipboard 
Print this post

  Chris Roper said  EDIT: If you did need to invert all the signals with external hardware you may as well use MAX232 device rather than to transistors. save the space and boost the signals too.
I did think about it, but you'd still need 3 MAX 232 to invert the 5 signals (RxD, TxD, CTS, RTS, DTR)... Quite the overkill ! :-(
It'd be cool if the original author could look into this (and with 2 unused pins on the 16F1455, we could use one to tell the chip to either invert the signals or not... That'd make it an "universal" converter)... I'd write him, but I don't speak Japanese...
 
Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280
Posted: 12:21pm 16 Sep 2015
Copy link to clipboard 
Print this post

  piclover said  I did think about it, but you'd still need 3 MAX 232 to invert the 5 signals (RxD, TxD, CTS, RTS, DTR)... Quite the overkill ! :-(


The MAX232 has 2 inverters in each direction so only one device could handle 4 signals and it is unlikely you would need DTS at the same time as RTS/CTS when talking to a normal RS232 Port.

The Original code was not meant to be a converter to RS232, it was to drive an XBee module at TTL levels, which it does so, even if we did take a crash course in Japanese, I think he would probably tell us to politely go away
http://caroper.blogspot.com/
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 01:52pm 16 Sep 2015
Copy link to clipboard 
Print this post

The PIC16F145 datasheet tells that inverting the TX and RX signals is possible.
It is on page 250.
I used the standard cdc example from Microchip as a start.
It has defines in the header file to enable/disable the handshaking signals.
With the free xc8 compiler it uses 44% of memory and 40% of flash.
It works on a polling or interrupt base. I use polling as it is a bit faster.
It does make your own program a bit more difficult because nothing can take too much time, but it is much easier to debug.
The compiler tells that it could be a lot smaller and faster, but i got it to work until 112500 baud and even 500.000 baud but have no real practical test for that as i have nothing that is that fast. Just echoing characters it seemed to do ok.
Which seems more than enough for such a modest chip,
It has no hardware output buffers on the serial side. And only a 2 character buffer on the input side. The polling frequency is high and it does check the registers if a character is available 65.000 times per second.

I disabled the RTS/CTS and only use the DTR to be able to switch between USB-Serial and Programmer mode. This programmer mode will allow you to program a PIC. The best thing about that is that when you add this to your pcb and wire it correctly it is possible to program the main mcu in place by using the USBSerial to transfer the data. Read more about that in the pic32prog thread by Robert Rozee.



Edited by TZAdvantage 2015-09-17
Microblocks. Build with logic.
 
Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280
Posted: 07:40pm 16 Sep 2015
Copy link to clipboard 
Print this post

  TZAdvantage said   With the free xc8 compiler it uses 44% of memory and 40% of flash.
It works on a polling or interrupt base. I use polling as it is a bit faster.
It does make your own program a bit more difficult because nothing can take too much time, but it is much easier to debug.


Have you seen this Page:
http://www.codeproject.com/Articles/830856/Microchip-PIC-F-USB-Stack
http://www.codeproject.com/Articles/832135/Microchip-PIC-F-USB-Stack-Part

He rewrote the Microchip Stack and got it down to 22%.
His examples are HID rather than CDC but you may find it useful.

Cheers
Chris

Edited by Chris Roper 2015-09-18
http://caroper.blogspot.com/
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 08:38pm 16 Sep 2015
Copy link to clipboard 
Print this post

Yes i know those.
Unfortunately only HID. Still interesting!
It should be possible to adapt it for CDC but i could not really find my way in his code.
I do learn a lot though from the Microchip example, so maybe in the future i have to revisit it.

Also the amount of memory and flash used is not that important when it already does want you need. Even 100% use of everything is fine.

If 75% is unused, then you have the wrong chip. Edited by TZAdvantage 2015-09-18
Microblocks. Build with logic.
 
JTR0701
Regular Member

Joined: 10/07/2013
Location: Australia
Posts: 71
Posted: 10:08pm 16 Sep 2015
Copy link to clipboard 
Print this post

  TZAdvantage said   The PIC16F145 datasheet tells that inverting the TX and RX signals is possible.
It is on page 250.


Actually on the PIC16F1xx you can only invert the TX signal, not RX. You can invert both on a PIC18 though.
 
piclover
Senior Member

Joined: 14/06/2015
Location: France
Posts: 134
Posted: 12:41am 17 Sep 2015
Copy link to clipboard 
Print this post

  TZAdvantage said   The PIC16F145 datasheet tells that inverting the TX and RX signals is possible.
It is on page 250.
I used the standard cdc example from Microchip as a start.
It has defines in the header file to enable/disable the handshaking signals.
With the free xc8 compiler it uses 44% of memory and 40% of flash.[/Quote]So, when applied to the original firmware and schematic this thread was started about, does it mean that the code would still fit when recompiled with a freeware XC8 compiler ? If the answer is yes, it'd be worth investigating a software solution to TxD/RxD/CTS/RTS (and, if really needed, DTR) signals...

[quote]It works on a polling or interrupt base. I use polling as it is a bit faster.
It does make your own program a bit more difficult because nothing can take too much time, but it is much easier to debug.
The compiler tells that it could be a lot smaller and faster, but i got it to work until 112500 baud and even 500.000 baud but have no real practical test for that as i have nothing that is that fast. Just echoing characters it seemed to do ok.
Which seems more than enough for such a modest chip,[/quote]Indeed... I never myself used any RS232C device with baud rates above 115200...

[quote]I disabled the RTS/CTS and only use the DTR to be able to switch between USB-Serial and Programmer mode.[/quote]Well, in my case, I don't care about the programming feature (there's ICSP for this purpose), but on hardware handshaking support, so RTS/CTS is a *must have* (they do allow reliable, high speed serial communication with devices without buffer or with a very small buffer). The original firmware would do just fine for my needs, if only the signals were inverted (i.e. RS232-compatible)...
Edited by piclover 2015-09-18
 
piclover
Senior Member

Joined: 14/06/2015
Location: France
Posts: 134
Posted: 01:06am 17 Sep 2015
Copy link to clipboard 
Print this post

  JTR0701 said  
  TZAdvantage said   The PIC16F145 datasheet tells that inverting the TX and RX signals is possible.
It is on page 250.


Actually on the PIC16F1xx you can only invert the TX signal, not RX.
Yes, it indeed looks like it... Chapter 23.1.1.3 of the datasheet for the "Transmit polarity" and no equivalent in the Receive section... Which means we'd only need to invert the RxD line (CTS and RTS being software-generated, it'd be no problem to invert them in software unlike RxD/TxD which also must deal at the UART level with start, stop and parity bits).Edited by piclover 2015-09-18
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 06:29am 17 Sep 2015
Copy link to clipboard 
Print this post

I saw the same SCKP bit in the receiver, but it is greyed out, meaning not available for asynchronous. Bummer.

The code mentioned by Chris at the start of this thread has RTS/CTS enabled.
So you probably can just use that.
If transmit has to be inverted it would only be a single line to add.

The code i use is the standard example code form Microchip.
In that code there are these lines in usb_config.h
[code]
//#define USB_CDC_SUPPORT_DSR_REPORTING //Signal from UART peripheral device, to CDC/USB host. Indicates UART peripheral is ready to receive data and/or commands.
#define USB_CDC_SUPPORT_DTR_SIGNALING //Signal sent from the USB/CDC host, down to the UART peripheral device
//#define USB_CDC_SUPPORT_HARDWARE_FLOW_CONTROL //Implements RTS/CTS UART flow control.
[/code]
You just unremark the ones you need. The code is already present, it is just not compiled when it is not defined.

With about 50% flash and about 50% memory free when compiled with the free XC8 compiler you still have room to add your own stuff if needed.

Microblocks. Build with logic.
 
piclover
Senior Member

Joined: 14/06/2015
Location: France
Posts: 134
Posted: 11:22am 18 Sep 2015
Copy link to clipboard 
Print this post

  TZAdvantage said  .../...
The code is already present, it is just not compiled when it is not defined.

With about 50% flash and about 50% memory free when compiled with the free XC8 compiler you still have room to add your own stuff if needed.

Many thanks for the info and the pointers: I'll probably give it a try soon. :)
 
     Page 3 of 3    
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2024