USB 14K50 uC operation

[majenko]

>That's pretty much what the main board is doing
Doesn't that keep reset asserted while DTR is true?

No. The DTR signal is passed through a capacitor/resistor network which turns it into a short pulse. It in effect acts like a high pass filter removing the low frequency (DC) component of the DTR signal and just using the higher frequency content of the leading / trailing edges.

Having that large a cap on the MCLR line would give the ICSP fits, and could cause power up/down issues as well.

I'm not suggesting it remain there all the time, just add it once you have finished the programming / development phase and you're ready to embed it. If you need it removable in an embedded board a simple jumper would suffice. As for power up/down issues, I have never come across any. Worst case the reset would be held low for longer than the internal POR timer holds it low anyway, so a slight delay in program start.

Arduino boards (and ChipKIT ones) have a small exposed track that can be cut to disable the DTR functionality completely - maybe we should consider adding this? They had it originally because they used the FT232 chip which of course you couldn't reprogram, so the DTR was always enabled regardless. If you have the facilities to reprogram the PIC18 then that is probably the best way to go as it is completely reversible.

[Jerry Messina]

>>No. The DTR signal is passed through a capacitor/resistor network which turns it into a short pulse

Matt -
On the schematic I have (Rev 2 dated 15/01/13), the RESET signal out of the 14K50 is shown going directly through a 100R resistor to the MCLR pin of the PIC24 with no cap (That would work better anyway than trying to rely on an RC to create a pulse).

>>As for power up/down issues, I have never come across any

With a large cap on MCLR, you have to worry about the voltage on VDD vs the voltage on the MCLR signal. If you have a large time constant on MCLR, it may not respond fast enough to sense rapid changes in VDD. If you power-cycle the board rapidly or VDD glitches, sometimes it won't initialize properly. That's why there's a market for the power supply supervisor IC's

EDIT: I just got an updated hex file for the pic18, so I'll give that a try...

[David John Barker]

The original Firewing board had RC for reset, but was a little problematic. The later boards has a standard reset circuit that I have used before in other designs and is the version you have. The new firmware should just provide a short pulse when DTR is asserted.

[Jerry Messina]

David -

I loaded the v2.3 hex file into the 14k50, and that seems to work better. When it first connects I get the message "sdAvailable = False" on the terminal window, and the board no longer stays in reset.

You can now connect to the board using Windows Hyperterm or the open source TeraTerm (to name a few), whereas before they were useless.

I think people need to be aware of this. Say you had a stand-alone app running on the board in the field for hours doing data collection. The mere fact of connecting up to it will reset it... probably not what you wanted to happen from an application standpoint.

Maybe that's how all these boards work, but that in itself doesn't mean much. Just something to consider.

Anyway, thanks for the update.

[majenko]

The original Firewing board had RC for reset, but was a little problematic. The later boards has a standard reset circuit that I have used before in other designs and is the version you have.

Oh yeah, come to think of it I do remember that now. It seems so long ago that we designed the original prototype It was what is now R5, wasn't it.

[David John Barker]

> It was what is now R5, wasn't it.

Yup, that's it...

> You can now connect to the board using Windows Hyperterm or the open source TeraTerm (to name
> a few), whereas before they were useless.

That's great news.

> Say you had a stand-alone app running on the board in the field for hours doing data collection

OK, I take your point - but let's keep some focus here:

(1) For prototyping and developing, having an auto-reset is a real plus. Indeed, many users expect it.
(2) When programming using a wireless connection, auto-reset is a must
(3) If updating firmware in the field, having auto-reset is a plus.
(4) The new firmware now works with terminal programs, again a great plus during development

That leaves the case you have outlined, where you would not want the board to reset after a few hours of data collection in the field (and assuming the only way to retrieve this data is through a 'live' 232 connection). I would say this scenario would be few and far between. However, if this was the case, I would suggest reflashing the firmware to disable DTR or modify the firmware to meet your needs. Remember, all the loader code is done on the main MCU, so re-purposing the USB chip is relatively easy. You could easily add your own set of commands to tell the 14K50 to initiate a reset. Being able to re-flash the USB chip is a real plus. You could easily take a Firewing board out of the realms of development to real a world application using a HID interface, rather than CDC. I think all of the above makes for a very flexible system...

[Jerry Messina]

I get your point, and rethinking it you're probably right. Having the reset DOES make the development side easier if you're using the IDE/loader.

It's simple enough to make any changes you might need when it comes time to deploy it, and that's the important thing.

[Jon Chandler]

An easy fix would be a jumper between the 18F14K50's reset line and /MCLR. Leave it closed during dev, open it later if serial comms are planned.

Also, I believe the microcode bootloader will pop up a message asking for the reset switch to be pressed if there's no "auto" connection.

[pverburg]

Request for David,
I'm testing a Firewing look alike board to be used with Proton24 I'm a hobyist and have no experience with USB/CDC connections.
Could I request the hex file or code to load the 14K50 to make loading the Pic24 easier?

Thanks,
Paul V.

[David John Barker]

http://www.firewing.info/pmwiki.php?n=Firewing.MainBoard#Firmware

> I'm testing a Firewing look alike board to be used with Proton24

Is this a board you are building yourself? Or is it a commercial unit?