uart baud rate "Bridge" - best way 1Mb -> 115200b ?

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a device that normally, for debugging, spits out data on it's TTL level uart at 1Mbaud.  

 

I'd like to replace that wired link (normally an FTDI USB->UART bridge IC etc) with a Bluetooth one, using one of the generic HC-05 style pre made modules.

 

However, i can't change the firmware in the device (for various complex reasons) and the HC-05 modules only run up to 115,200 baud (as far as i can tell).  So, i need to "bridge" 1Mbaud to 115kbaud, and of course, it'll need to include a buffer for the transmitted data because the messages have different transmission durations. (The slower uart will obs. take around 10x longer to parse out).

 

I guess the easiest way is just to use an AVR with a bit of RAM and two hardware Uarts?  It just seems like a bit of an overkill, but i can't immediately think of a simpler way of achieving this baud rate bridging??

 

Anyone got any better ideas??  smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should add that the clock setting for the bridge will be a compromise, as the baud rates are not exactly divisible?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

at 16MHz, you can get 1meg rate using the register settingof 0 or 1 (in 2x mode), with zero error (lucky you)...that's really  pushing the limit.

you won't be able to use 115.2, you will have to use 76.8K baud

 

 

why not use THIS---uart to 4.3 MEGS:
 

https://www.mouser.com/new/panasonicec/panasonic-pan1026-bluetooth-module/

 

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. May 5, 2018 - 04:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. Both 1Mbps and 115200bps must be compatible with high precision.
2. A sufficiently high processing speed is required for 1Mbps reception interrupt.

 

I think that only the xmega series meets the above conditions.
Program is not too difficult if you pay attention to processing efficiency.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I currently use 1Mb without issue on the target device, that runs a Mega644.  The data exchange is packetised, and only ever consists of 13 bytes at any time (5 header, 8 data) to bring commonality with CAN that has 8 byte long messages (my diag routines run over CAN or Usart transparently).  The exchange is clocked by the master, so when it's using bluetooth then the overall data rate will fall, but the system will cope because it's a "poll / Ack" type protocol. ie the master doesn't ask for more data until it's received the last lot back.

 

So, the entire packet (13bytes) will be received by the bridge from the target at 1Mb, and when complete (it is framed by start/stop bytes and a checksum), the bridge will then re-transmit the frame at xx baud, out to the bluetooth module. (where xx is some other baudrate)

 

I'll have to check to see what baud rates are supported by the HC-05 modules, i want to try to avoid the REALLY slow ones (like 9.6k etc....)

Last Edited: Sat. May 5, 2018 - 05:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try one of these modules...you can go to several MHz, no need for any buffer/bridge

 

https://www.mouser.com/new/panasonicec/panasonic-pan1026-bluetooth-module/

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

max_torque_2008 wrote:
I guess the easiest way is just to use an AVR with a bit of RAM and two hardware Uarts?  It just seems like a bit of an overkill, but i can't immediately think of a simpler way of achieving this baud rate bridging??  

 

Why is that an overkill, it's a single chip ?

Plenty of small MCUs with 2 UARTS.

 

max_torque_2008 wrote:
I currently use 1Mb without issue on the target device, that runs a Mega644.  The data exchange is packetised, and only ever consists of 13 bytes at any time (5 header, 8 data) to bring commonality with CAN that has 8 byte long messages (my diag routines run over CAN or Usart transparently).  The exchange is clocked by the master, so when it's using bluetooth then the overall data rate will fall, but the system will cope because it's a "poll / Ack" type protocol. ie the master doesn't ask for more data until it's received the last lot back.   So, the entire packet (13bytes) will be received by the bridge from the target at 1Mb, and when complete (it is framed by start/stop bytes and a checksum), the bridge will then re-transmit the frame at xx baud, out to the bluetooth module. (where xx is some other baudrate)

 

The payload sounds simple enough, and if is it half duplex, I'd try the module suggested above set to 1MBd - job done.

If that does not work, or you plan to make squillions of these, then you can search out the small MCUs with 2 uarts, with fractional/decent Baud dividers.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

doesn't the HC-05 have a buffer big enough for 13-byte messages?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm, the problem seems to be finding a module with exactly 1Mb as an option!  Because the original device just talked to a pc via an FTDI USB bridge, and the FTDI has  a fully flexible baud rate generator, i set 1Mb as with a 16Mhz clock that gave me 0% timing error.  Now it seems, trying to hook up to any thing i am limited to the more classical baud rates, ie 

921600 baud.  doh!

 

I may well end up with a micro in between busses, but i guess that's not so bad as i can use it to configure the bluetooth adaptor as well.....

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

did you look at this module???!?

https://www.mouser.com/new/panasonicec/panasonic-pan1026-bluetooth-module/

 

Now it seems, trying to hook up to any thing i am limited to the more classical baud rates, ie 921600

 

set your uart speed register to 0, and you get exactly 1MHz....

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!