Welcome, Guest. Please login or register.

Login with username, password and session length
ArdweeNET forum

 
Pages: [1]
  Print  
Author Topic: 9600bps?  (Read 3709 times)
0 Members and 1 Guest are viewing this topic.
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« on: January 31, 2011, 02:40:11 AM »

The basic baud rate was originally set to 4800 pbs because it was envisaged that slow processors (Picaxes etc) would interface directly to the network. This is no longer the case, if you have a slow processor then you should use a BNIC chip.

So, should the baud rate be upped to 9600?

Note that this doesn't affect application processors, they can still talk to the BNIC and slower rates.
Logged

Rob, aka the GRAYnomad
garylcamp
Newbie
*
Posts: 10


View Profile WWW
« Reply #1 on: February 11, 2011, 04:36:33 AM »

You should go as fast as you can reliably go as things electronic always get faster and will probably continue for the forseeable future, up the speed. Would it be possible to allocate an extension flag for later upgrades that would tell the devices it is on a newer system and can support higher speeds (as well as bigger time code stamps, 32 bit values, etc. BUSnet 2 stuff, compatable with BUSnet 1?
Logged
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #2 on: February 11, 2011, 10:34:47 AM »

Yes faster is better.

[Thinking out aloud mode follows]

There are as yet unused flags in the frame definition, one of which could be used for this and I have been thinking about how to to a multi-speed system.

It would be nice to have a mix of say 4800, 9600 and 19200 Nodes, but I can't figure out how to implement this.

At present the bit rate is determined by timing the first character (the SYNC byte), this was intended to allow slight variations in bit rates but could be expanded to allow entirely different bit rates.

When a Node connects for the first time it can tell the MCU what rate it's capable of, so far so good. One problem is resyncing with the data stream, at present a Node waits for a HIGH for 12 bit times or more, this indicates the inter-frame break and allows the Node to resync.

This can still be accomodated, if you can time the SYNC byte you can use that to determine the resync time.

So my question is, what's the benefit or all this?

A slow chip like a Picaxe will need 4800 or even 2400, but it can't time the SYNC byte anyway. A fast chip can just run at say 19200.

As I'm proposing to make an interface chip the application doesn't have to deal directly with the network anyway.

Now maybe I'm being short sighted here and in the future an interface chip may be made to use 56400bps for example.

What this means though is that ALL interface chips have to at least be able to time the higher rates even if they can't handle data at that rate, that shouldn't be a problem.

At present a Node reads the first byte after the SYNC byte to get the address, if it's not the addressee it ignores the rest of the frame.

So we just need to add another condition, if you time a data rate faster than you can deal with you also ignore the rest of the frame.

I think this should work and should accomodate all future speeds.

So that shows the benefit of talking about things, I've just turned 180 on this and come up with a way to do it (I think).


BTW, this is another reason for moving to 485, LIN is limited to 19200bps.
Logged

Rob, aka the GRAYnomad
Pages: [1]
  Print  
 
Jump to: