PDA

View Full Version : Renard Driver



chilloutdocdoc
06-03-2011, 02:03 PM
Alright, I'll look into working on that, I'm going to hopefully test the Renard output either tonight or early next weekend. I'm not sure if I'll be developing a PCB for it or not, I'll look into the possibility. What I would like to see is if it can be modified to do more than one Renard output per cog. The ideal situation would be one cog handling each of the headers, which leaves 4 data pins, which means four seperate renard outputs.

Josh

DynamoBen
06-03-2011, 02:09 PM
...I'm going to hopefully test the Renard output either tonight or early next weekend. I'm not sure if I'll be developing a PCB for it or not, I'll look into the possibility.

RPM sent me an updated Renard driver today that I need to code review and get up on the site. The PCB part I expect will have two purposes, DMX and Renard. The big dilemma is if it should be galvonically isolated. I'm person request is it had both types of headers on it.


What I would like to see is if it can be modified to do more than one Renard output per cog. The ideal situation would be one cog handling each of the headers, which leaves 4 data pins, which means four seperate renard outputs.


Except that you might want to make the board more universal and allow Data in (see previous comment), that then would eat up 3 pins.

chilloutdocdoc
06-03-2011, 02:14 PM
RPM sent me an updated Renard driver today that I need to code review and get up on the site. The PCB part I expect will have two purposes, DMX and Renard. The big dilemma is if it should be galvonically isolated. I'm person request is it had both types of headers on it.

Except that you might want to make the board more universal and allow Data in (see previous comment), that then would eat up 3 pins.

Both great ideas that I'll run with I'll wait to test the updated Renard library. One feature I'll be coding in is a self check to make sure it's not trying to send out more channels then the data-rate can handle.

DynamoBen
06-03-2011, 02:16 PM
Both great ideas that I'll run with I'll wait to test the updated Renard library. One feature I'll be coding in is a self check to make sure it's not trying to send out more channels then the data-rate can handle.

Code has been posted, it has been moved from unreleased to released...enjoy.

DynamoBen
06-03-2011, 02:20 PM
Code has been posted, it has been moved from unreleased to released...enjoy.

You know what would be nice is to make this object also receive Renard data. That then would turn the DMX board into a Renard board!

Enhancement has been added to the issue tracker/bug database.

chilloutdocdoc
06-03-2011, 02:44 PM
While a great feature to have, I personally don't see much of a need for it, I could be wrong however.

So the renard object is tested to be working?

DynamoBen
06-03-2011, 03:03 PM
While a great feature to have, I personally don't see much of a need for it, I could be wrong however.

If all you have is renard stuff, the PropController could act as a renard node.


So the renard object is tested to be working?

RPM assured me that it is working, I don't have hardware to confirm so a second opinion would be a good thing. Also I think it only does the slower speed right now, it might be worth while to have a low and high speed option.

chilloutdocdoc
06-03-2011, 03:32 PM
Low speed as in 57600 baud rate? I think a 115k would be really useful as that's what will really make it powerful as it almost doubles the data that you can put out.

RPM
06-03-2011, 04:05 PM
Low speed as in 57600 baud rate? I think a 115k would be really useful as that's what will really make it powerful as it almost doubles the data that you can put out.

The Renard object is fully capable of running at 115200, there's just no method of changing it from the calling object and it currently must be changed directly in the Renard object.

I've been working on my variant of jstjohnz E680 code to create an E1.31 to DMX (and Renard) bridge that once completed, will be able to run on the PropController with a few simple changes to port assignments. This should help with the requests for some "ready to run projects".

chilloutdocdoc
06-03-2011, 04:34 PM
So, do you think changing the baud rate to a long and just passing it in with the Start method would work, and then that way the object would just have to be restarted to work with a new rate?

RPM
06-03-2011, 05:30 PM
So, do you think changing the baud rate to a long and just passing it in with the Start method would work, and then that way the object would just have to be restarted to work with a new rate?

That should work. You can also add a PUB routine to the Renard object to change the baud rate on the fly by calling it with the new baud rate. This way you won't have to reload the Renard object once it's been started.

chilloutdocdoc
06-03-2011, 06:07 PM
so would the new PUB just set the new baud rate and call start? or would it set the new baud rate and bitticks (seems to be the only other variable that baudrate affects)

Learning as I go here :)

DynamoBen
06-03-2011, 06:15 PM
So, do you think changing the baud rate to a long and just passing it in with the Start method would work, and then that way the object would just have to be restarted to work with a new rate?

I would add it to the start method. If you want just 57_600 and 115_200 then you could just do true and false (high speed == true). Then when it starts you have the correct baud rate, obviously if you need to change speeds after launch you would need a PUB like RPM mentioned.

I proactively made the change, let me know what you think. As usual code is untested since I don't have hardware.

chilloutdocdoc
06-03-2011, 06:17 PM
I like it, I'll give it a whirl tonight if I get a chance. Doesn't provide the opportunity to use a different rate, but we can update that later.

Edit: Working on the E1.31 object now.

P. Short
06-03-2011, 07:32 PM
Using a default of 57600 would fit better with the default Renard baud rate. Remember, not everyone has the PIC programmer needed to change the baud rate of the Renard controllers.

chilloutdocdoc
06-03-2011, 07:42 PM
Using a default of 57600 would fit better with the default Renard baud rate. Remember, not everyone has the PIC programmer needed to change the baud rate of the Renard controllers.

Good idea Phil, we'll set the default to 57600 but I know some people may need the 115k

ukewarrior
06-03-2011, 09:07 PM
I agree.
This speed seems to be the 'default' that has been shipped with most group buys.


Using a default of 57600 would fit better with the default Renard baud rate. Remember, not everyone has the PIC programmer needed to change the baud rate of the Renard controllers.

DynamoBen
06-03-2011, 09:26 PM
I agree.
This speed seems to be the 'default' that has been shipped with most group buys.

No worries folks its just a true / false choice.

chilloutdocdoc
06-04-2011, 10:22 AM
No worries folks its just a true / false choice.

Exactly, also it'll be configurable with the menu when that gets implemented. So for those that want to use a different speed, it's entirely possible.

DynamoBen
06-04-2011, 02:43 PM
RPM made some improvments to the Renard driver. One is the baudrate is no longer true/false its 0/1 (0=57600 baud, 1=115200 baud).

Also now you can call a method to change baud rate dynamically see "setbaudrate".

The driver version is now 1.2

budude
06-04-2011, 03:04 PM
I like this project - it will allow me to use the PropController for everything instead of a mix of dongles and ethernet. Between this and the E680 (yes, I know there is pixel code for the PropController but it's already a working piece of hardware) I think I will be covered.

The only thing we need now is an LEDTriks driver!

chilloutdocdoc
06-04-2011, 03:05 PM
HA we could possibly do that...