Is arduino the best?

[TerminalJack505]

Here are the project files for anyone that is interested. 

The firmware is just a slightly modified version of the code found on this site.  I will probably make some additional changes to how the LEDs work.  Right now they are enabled/disabled for each iteration of the main loop.  I looked at the assembly code generated and it isn't too chunky but my feeling is that it should probably be better optimized since it may be a problem at the higher baud rates.

The firmware was developed in Atmel Studio 6.  Eagle 6.4.0 was used for the schematic and board.  All of the components are contained in the project's library so there aren't any 3rd party (or even standard) libraries necessary.

[Anson]

Sweet with all the info you've been including in this build it makes it very educational. It also makes it easier for me to understand what could be going wrong if something isn't going right.

[TerminalJack505]

Sweet with all the info you've been including in this build it makes it very educational. It also makes it easier for me to understand what could be going wrong if something isn't going right.

Yes, hopefully you'll understand the circuit well enough that you will know what it should and shouldn't do.

There's still just a little more information that I need to provide (which I'll put in the Theory of Operation document) such as the fact that the flow control signals work only between the device and the remote.  That is, the flow control isn't under the control of the PC as is the case with most other USB-to-serial cables.  I don't imagine that would be a problem since it is very unlikely a microcontroller can overrun a PC.  Just something to be aware of.  (The PC can't overrun the device, BTW, due to the nature of how USB works and this may be the same when going the other way but I'm not certain.)  Anyway, you probably won't even need to bother with the flow control signals for most of what you'll use the device for: debug messages.

This project is just about wrapped-up so I'll probably start working on the programmer soon.  A lot of the circuitry used in this project will be re-used in the programmer project.  It will likely look pretty much like the same circuit, I imagine.

[Anson]

How's the project coming?  Any news? Any changes? Did you make a logo for it?

[TerminalJack505]

Sorry, but I've been run down with a cold for the last week and a half so I haven't put a lot of time into it.  I think I might finally be getting over it so hopefully I'll find the energy to work on it soon.

[Anson]

Cold's suck. Hope you feel better. Take your time I'm in no hurry. It's gonna take me some time to learn to use the thing anyway. Still think you should put a logo on it Come up with your own brand.

[glatocha]

So will add also my thought to this discussion.

For starter take the KIT preferably from the producer (microchip, atmel, TI so on). You will get a demo software loaded, support if needed. You will save a lot of time (no need to think "is that a software is that a hardware"). I don't know much about Atmel boards. The TI MSP430 Launch Pad used to be sold for 4,30$ now it is 10 I think. Plenty of add-ons available starting at 5$ already. For PIC the PICKit3 starter is worth to have, but u need to spent 60$.

For me also important is an IDE. I like it simply but also with lot of functions. For me the Microchip MPLAB X is good and free. The Code Composer Studio for TI also free (any restrictions? - I am not sure) was always a bit complicated for me. But if you do some PC programming then you will have no problems. 

If you are starting you need to think about the whole package. Chip, programmer, board, IDE, documentation, community, even is the website friendly.

Just save yourself time, money and nerves and don't go for any DIY stuff. Not at the first time.

[TerminalJack505]

I'm finally back to work on this project, Anson.  Here's the latest schematic.

I just need to make some breakout boards so I can breadboard the project.

As you can see from the schematic, this project is very similar to the USB-to-serial project.  Because of this, I'm not expecting any major issues.  <Knocks wood.>

As you can see in the schematic, I got some 18MHz crystals in so I'm going to try to get the firmware to work with at 18MHz instead of 12MHz.  This will allow CRC error checking to be enabled in the VUSB library.

[Anson]

Awesome.

What's the deciding factor for using an 18Mhz oscillator? Couldn't you have used a 20Mhz crystal?
 
I see you have some indicator LED's off board. Is this just for testing or do you plan on putting them on board later? I like the use of the multicolored LED's.

For debugging are you going to have just a single jumper I can remove to disconnect the capacitor?

What are you using to make the schematic sheets? These are very nice.

[TerminalJack505]

Awesome.

What's the deciding factor for using an 18Mhz oscillator? Couldn't you have used a 20Mhz crystal?
 
I see you have some indicator LED's off board. Is this just for testing or do you plan on putting them on board later? I like the use of the multicolored LED's.

For debugging are you going to have just a single jumper I can remove to disconnect the capacitor?

What are you using to make the schematic sheets? These are very nice.

The firmware uses a library called V-USB.  This library makes it possible to use USB on AVR microcontrollers that don't natively support USB.  The library is highly optimized code.  A lot of hand-crafted assembly, for example.  The library only supports a few specific clock rates and, for whatever reason, only supports CRC checking in the 18MHz version.  I imagine they could support CRC checking in the 20MHz version but don't due to some technical issue they don't want to bother with.  As someone else earlier in the thread pointed out, low speed USB is 1.5MHz and 18MHz is an integer multiple of 1.5MHz.

The 3 bi-color LEDs will be in holders attached to the case and will have a cable running back to the PCB.  At least that's what I plan on doing at this point.  Mounting them on the PCB will be a problem with the holders that I plan to use--they lock the LED into the holder.  This will make taking the PCB out of the enclosure next to impossible without destroying something (most likely the LED holders) or un-soldering the LEDs.

The debugging capability is for development of the programmer.  That is, it is for me and not the end-user (you.)  Hopefully, I won't have to use it.  A lot of those components are there 'just in case' I have to use a debugger.  If this were a mass-produced product you wouldn't see a lot of those components.  You'll basically be getting the prototype version of the board so some of those parts will be vestigial by the time you get the board.

The schematic is made in Eagle.

[Anson]

Oh ok makes sense now.

I hear a lot of people use eagle, but I also hear it's difficult to use.

[TerminalJack505]

Eagle is what I would call "an acquired taste."

Newer versions are a lot better than older versions.  At one time (4.x and earlier, I think) the interface didn't have any concept of object properties.  That is, you couldn't right-click on an object (schematic symbol, net, pad, etc.) and see all of that object's properties all neatly organized.  They finally added that, thankfully, so the interface is better than it used to be.