Modern Device Forum

Paul,
The BUB board web page mentions that is has:
An LED which shows serial activity on both the TX and RX lines

My board only blinks the LED on RX data. No blinks on TX data.

The board appears to have the LED wired to CBUS1 which can be configured
in the FTDI chip EEPROM to blink on both RX and TX traffic but
the default behavior is RXLED, which is what I'm seeing.

It can easily be fixed by running FTDI's MPROG utility but
was this a configuration step missed in manufacturing?

================================================================

While I'll probably correct this with mprog initially, I think I'll look
at adding the another LED since having both is so useful when debugging
serial communications .
To make is easier, I plan on cheating and sharing the same current limiting resistor.
The leds will dim a bit when both are on but they still will be visible.
This way I only have to glue down 1 new component and add 2 wires
to make it work.

I had read about that setting with MPROG but it seemed to me that the BUB's we tested have all worked for both rx & tx "off the line". I wonder if I'm seeing a serial port echo or something. We develop on mostly macs so maybe it's some quirk with the way windows handles the serial port (or a mac quirk, if you want to look at that way). Tell me what system you're using. I'll fire up some BUB's on my windows machine and see what I see there.

The other LED idea will work fine - you just have to solder to the lead you want without bridging another one - a fairly delicate operation. Maybe hit the wire with some superglue after you get it working, for mechanical strength.

Paul

I did the testing on a Vista machine with the "raw" board. i.e. not even a connector
was soldered in yet.
From what I've seen, it is definitely the way the FT232R is configured.
It seems to have all the factory defaults which makes the CBUS1 pin a RX LED indicator.

I downloaded and ran MPROG and changed the EEPROM and it now it blinks for traffic either way.

Maybe its not noticed as most of the time serial traffic is bi-directional messages.
I noticed it as I was using a special test program that I can send individual bytes.
I would think that this would also show up when using one of the serial LCD boards
as that is only transmitting data with no RX traffic.

FTDI's MPROG is a pretty cool little GUI tool. Very easy to use for those running Vista.
Vista will automatically download the driver from windows update when you
plug in the BUB board and then all you have to do is download and install MPROG.

You can then scan for FTDI chips, read the EEPROM, have it decode it,
and then modify it using the GUI.
Finally, if you can have it update the FTDI chip with the modified contents.

One word of caution, when you write out the EEPROM data to the chip, make sure
to check the box for a single serial number or else MPROG will generate a new serial
number for you and then Vista will see it as a new board and you will lose a com port
because you can't detach the original com port from the "old" BUB board that had the original serial number.
(Well you can detach it can but it is not an easy or obvious process)

Since my main target is Linux,
I'll be creating a udev rule to create a special device, i.e. /dev/mdbub whenever
the bub board is plugged in so that its name is always a constant.

As far as the 2nd LED goes, it sure would be nice to have it... hint, hint.....
Eventually, I'll get around to adding it in. I'm not looking forward to the tiny soldering.


--- bill

========================================================================
On a slightly different topic but still BUB related,

I'm also looking at using the board as a DASA ISP programmer.
(It uses the FTDI bigbang mode - Support is already in avrdude for this)
I would think that this would be something that would be of high value to your Arduino customers.
They could set fuses and burn their own boot loaders without having to buy an ISP programmer.
This is an area where a slight change to the layout of the board would make things
simpler.

For DASA programming, you have to get the modem control lines as well as a ground
out to a 6pin or 10pin ISP connector.
Currently there is no ground next to the control lines.
It can still be done with the existing board but you either have to run 6 wires to the side connector
area or you can put a header in the control line area and bend up one pin and solder it to the
corner of the USB connector to get a ground.
Once you have a header in place, you can make a cable that connects to a 6 pin 2x3 female
connector that can be used for ISP programming.
Not nearly as fast as a true ISP programmer but it would still work.

The ideal solution would be to either have solder holes for a 2x3 header for the ISP cable
or have 6 solder pads 3 on top and 3 on bottom of the board (not through the board)
so that a 2x3 female header could be directly soldered to 6 pads on the board.

There are also some easy modifications that would allow the FTDI chip to automatically level adjust
to the targets voltages without adding any new components.

I'm looking at having 3 connectors on my BUB board.
- 1 for BBB/Arduino
- 1 for a serial LCD
- 1 for DASA ISP programming

I'd be happy to work with you to roll in any updates into a new version of the BUB board
if you are interested.

--- bill

I'm really interested if it can be done on both the software side and hardware side without lots of fuss.
Maybe I can just make a super-BUB or an addon kit with the cable and six pin header.

Are all the signals it needs available, on present board?

Maybe send me a link, schematic or image and I'll try and wire one up for ISP.

Paul

It can definitely be done. All the hard parts like s/w support have already been done.
There are a few other boards out there already that use "DASA" style
bit banging across the USB bus with FTDI chips.
I'm surprised that more people are not taking advantage of this capability yet.
The latest USB Arduino Duemilanove board you are selling has a nice set of solder
pads which can be used to support this as well. (maybe you could sell an ISP cable kit for that)
It will be slower than a real ISP programmer, but for fuses and for bootloader
burning, it should be perfectly fine.

Here is a link with some information on using it on the Duemilanove board:
http://www.geocities.jp/arduino_diecimi ... ex_en.html
What is there seems more complicated than it really is, or should be.
From my initial look, the current avrdude has all the needed suport for bitbanging.
I need to fully verify this for the FTDI USB based devices.

If it is not there, I see little value in having 2 avrdude programs as was done in the link
above. It unnecessarily complicates things.
The support should be added back into the mainline avrdude program
so there is a single avrdude. I'll look at this as well, if necessary.

Avrdude is very flexible, you can map any of the ISP signals to any modem control line by
simply adding a device entry to its config file. (no recompile is necessary).

I believe that it can be boiled down to soldering a few wires to make a
cable and adding a new entry to the avrdude config file.

While creating a new device is easy, and having a "mdbub" device
supported in avrdude would be kind of cool,
I'll look and see about using an existing device entry so that people won't even
have to mess with the avrdude config file.
My guess is that there is already an entry that can be used.

The "super BUB" board would be really nice. There are a few things that
could be done make it a little easier/nicer/simpler but all the signals to make it
work exist on the current board. (maybe even dual tx and rx LEDs.... )
Things like handling automatic target signal voltage levels are a bit messy with the current
board layout. But still doable with nothing but wires.

Here is an example of a board that solders a female 2x3 header directly to the board:
http://alldav.com/index.php?main_page=p ... 11f52152b4

I'll wire up my board and report back when I actually have it working.

If you want, PM me your email and we can work out some details offline.

--- bill

im really struggling trying to figure out how to add stm32 development to code blocks, i need to be able to write/edit/compile/deploy assembly and C to my board. if any of those are not possible in code blocks is there a simple way to do it another way?