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: AustraliaPosts: 71 |
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: ThailandPosts: 2209 |
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 AfricaPosts: 280 |
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: ThailandPosts: 2209 |
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: ThailandPosts: 2209 |
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 Microblocks. Build with logic. |
||||
piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
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 ? |
||||
Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
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. http://caroper.blogspot.com/ |
||||
piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
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. 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 AfricaPosts: 280 |
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. http://caroper.blogspot.com/ |
||||
piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
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 AfricaPosts: 280 |
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: ThailandPosts: 2209 |
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. Microblocks. Build with logic. |
||||
Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
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 http://caroper.blogspot.com/ |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
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. Microblocks. Build with logic. |
||||
JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
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: FrancePosts: 134 |
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)... |
||||
piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
It is on page 250. Actually on the PIC16F1xx you can only invert the TX signal, not RX. |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
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: FrancePosts: 134 |
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 |