Setting Baud rate to variable

undrtkr

I'm writing code for a 60+ room roll out for a college. They want control of two different Elmo document cameras. These two models have different baud rates. My question is can I set a variable to a specific baud rate and insert that variable into the SET BAUD command. Here is the code I'm thinking of.

DEFINE_VARIABLE

PERSISTENT INTEGER nElmoBaudRate //Determines Baud Rate

DEFINE_START

SWITCH(cElmoModel)
{
CASE cElmo400: nElmoBaudRate = 4800
CASE cElmo4400: nElmoBaudRate = 9600
}

DATA_EVENT[dvElmo]
{
ONLINE:
{
SEND_COMMAND DATA.DEVICE,"'SET BAUD ',nElmoBaudRate,' N,8,1'"
}
}

Spire_Jeff

I believe you are going to need to either use ITOA() or store the baud rate as a characters. You might also want to consider TSET instead of SET.

Jeff

Jeff

That looks fine, although I don't think you need to use persistent memory for something you're going to set in Define_start every time.

The other thing you could do, just to use less variable memory is this

data_event[dvElmo]
{
	online:
	{
		switch(cElmoModel)
		{
			case cElmo400: send_command data.device,"'SET BAUD 4800,N,8,1'"
			case cElmo4400: send_command data.device,"'SET BAUD 9600,N,8,1'"
		}
	}
}

There's really no reason to overly complicate it by declaring a variable

J

ericmedley

Jeff wrote:

That looks fine, although I don't think you need to use persistent memory for something you're going to set in Define_start every time.

one note on this statement. You almost never want to do a SET BAUD command in the startup section. In most cases the device is not even online at startup. It's best to put it in a DATA_EVENT in the ONLINE: section. That way the command doesn't get ignored. Any type of integrated master should be done this way. NI_X100 or whatever...

Jeff

I was referring to the variable that he was setting in define_start, not the baud rate. His code had the baud set in the online event, but he was setting the variable in define start every time, which means there's no real reason for it to be persistent, because its going to reset every time you reboot the master.

J

yuri

what are the 'parameters' for them to switch between the two models?
Otherwise you could just switch the baudrate according to a button press or something...

undrtkr

Jeff wrote:

That looks fine, although I don't think you need to use persistent memory for something you're going to set in Define_start every time.

The other thing you could do, just to use less variable memory is this

data_event[dvElmo]
{
	online:
	{
		switch(cElmoModel)
		{
			case cElmo400: send_command data.device,"'SET BAUD 4800,N,8,1'"
			case cElmo4400: send_command data.device,"'SET BAUD 9600,N,8,1'"
		}
	}
}

There's really no reason to overly complicate it by declaring a variable

J

Hm, good point. The above example would make it simpler. The cElmoModel is a constant set to 1 or 2. The installer will have to set this constant to whatever model of Elmo is being used before they compile and upload to the processor. Thanks.

Jeff

of course, if you'd like to get really creative, you can have a little fun with it

**Note, I haven't tested any of this and I don't speak Elmo, it just seemed like a fun idea so I wrote this in 5 minutes. If this turns out to be a stupid idea, sorry about it**

define_variable

persistent integer nElmoModel

define_event


data_event[dvElmo]
{
	online:
	{
		switch(nElmoModel)
		{
			case 0:
			{
				send_command data.device,"'SET BAUD 4800,N,8,1'"
				send_string dvElmo,"'Version?'"
				wait 50 'ElmoModel'
				{
					send_command data.device,"'SET BAUD 9600,N,8,1'"
					send_string dvElmo,"'Version?'"
				}
			}
			case 1:
			{
				send_command data.device,"'SET BAUD 4800,N,8,1'"
			}
			case 2:
			{
				send_command data.device,"'SET BAUD 9600,N,8,1'"
			}
		}
	}
	string:
	{
		stack_var char cElmoResponse[50]
		if (cElmoResponse='Version=Elmo_400')
		{
			nElmoModel=1
			cancel_wait 'ElmoModel'
		}
		else if (cElmoResponse='Version=Elmo_4400')
		{
			nElmoModel=2
		}
	}
}

As long as you can actually query the Elmo to find out what its model number is, this should work. Otherwise you'd have to set a variable (nElmoBaud) to tell you what the baud rate was when you asked it a question and just ask it anything, and tell it to keep the baud that got you a response.

I'm not necessarily recommending you use this, but it seemed like a fun way to make it so the installer couldn't forget to set the constant.

J

ericmedley

Jeff wrote:

I was referring to the variable that he was setting in define_start, not the baud rate. His code had the baud set in the online event, but he was setting the variable in define start every time, which means there's no real reason for it to be persistent, because its going to reset every time you reboot the master.

J

Oh, I see. That makes sense. I thought you were talking about putting the SEND_COMMAND dv_my_serial_port, 'SET BAUD 9600 ETC....; command there. that was a common problem early on on this board. Been bit by it myself a few times.

Jeff

No problem, I'm fairly sure I learned not to do that myself here on this board.

On another note, has anyone ever tried anything like the little snippet I posted yesterday? Something that sends commands out at different baud rates until it finds one that works, then stores that rate in persistent memory? It seems in the abstract to me that it would work, but I'm not set up to test it. I'm intrigued by the concept, because I like being able to write code that works for multiple rooms.

J

ericmedley

Jeff wrote:

No problem, I'm fairly sure I learned not to do that myself here on this board.

On another note, has anyone ever tried anything like the little snippet I posted yesterday? Something that sends commands out at different baud rates until it finds one that works, then stores that rate in persistent memory? It seems in the abstract to me that it would work, but I'm not set up to test it. I'm intrigued by the concept, because I like being able to write code that works for multiple rooms.

J

I did it a couple times. It works just fine. It's kinda like the old dial-up modem days where the modem has to initiate the call and determine the best baud rate. One issue I ran into was a box that would lock up when it recieved communications at the wrong baud rate. That was really goofy. I totally blame the box.

It's also useful on those occasions when you have a client who just can't leave the equipment alone and gets into the settings menu and goofs things up.

It's a good idea.