[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] Further serial port question



thanks, I'll take a closer look soon.

Josh

On Mar 29, 2009, at 5:30 AM, Hans Samuelson wrote:

Hi Josh;

Depending on the hardware you are using, there appear to be a couple of options. The attached code is what worked for me, and like me, you seem to need a direct multiple of the standard values. Hopefully it will work for you as well. 

In the interests of the cause, I contacted the manufacturers of the hardware we are using (a FTDI chipset to talk to a PIC) and they suggested that another option would have been to "edit the plist to alias the baud rate as described in:

This is even less cross-platform and is, in fact, device-specific. There does seem to be some degree of hardware dependency (kext files and the like) at rates that exceed the termios standards. Apple claimed to have implemented another code path based on the IOSSIOSPEED call, but the general online consensus seems to be that it doesn't really work; there are no functioning code snippets anywhere I could find, and the call failed to work in my attempts to shoehorn it into SC. Of course, this could well have been operator error...

Hope this is helpful,

Hans

<PyrSerialPrim.cpp>



On 29-Mar-09, at 12:45 AM, Josh Parmenter wrote:

Hi Hans,

I was just starting to look into a similar problem (I need 460800). Can you send me the diff (or the PyrSerialPort file) with the changes you made? I can start to take a look at it, and see if I can put something together that we can start to test on other platforms. My guess is this is something that could possibly change post SC 3.3, but it seems like there are reasons to be moving past the termios.h settings.

Best,

Josih

On Mar 28, 2009, at 5:32 AM, Hans Samuelson wrote:

Hello again Marije and all;

I finally managed to resolve this issue, and thought I would give you an update for the sake of anyone else who may ever find themselves facing this obscure issue.

On OS X, the "B" prefix for baudrate definitions is pretty much redundant; the sys/termios.h file effectively reverts them to integer values
(e.g.  #define B76800 76800)

I have been led to understand the definitions on other systems may vary, hence the use of the "B" prefix to allow appropriate cross-platform definitions. Essentially, the "B" prefixed baudrates serve as convenience variables that can be set on a per-OS basis. The current SC code accepts integer inputs and maps them onto these cross-platform "B" variables.

My problem was that the baudrate I needed to set (921600) is not part of the standard list, meaning that the "case... break" structure you are using for setting port speeds couldn't be extended.

In the end, the functional solution turned out to be fairly easy; simply remove the whole "case..break" structure, define baudrate in the struct as a speed_t rather than a size_t,  and call

cfsetispeed(&toptions, m_options.baudrate );
cfsetospeed(&toptions, m_options.baudrate);

with appropriate error-detection if... throw wrappers.

The FTDI device driver handles the rest, in some manner which is, I fear, still opaque to me.  I am also not sure how, or even if, this solution could be made elegantly cross-platform, so it may be no more than a patch for this specific need. However, it does work (!)

Thanks again for your suggestions,

Hans


On 5-Mar-09, at 8:24 AM, Hans Samuelson wrote:

Hi Marije;

This doesn't work, since B921600 is not defined in the sys/termios.h file in OS X (legacy issue).

That's the heart of the problem!

Thanks anyway. I am still working on this; if anyone has any other suggestions they would be most welcome.

Best,

Hans

On 4-Mar-09, at 8:20 AM, nescivi wrote:

Hiho,

try compiling SC with:

#if defined(B921600)
case 921600:
brate = B921600;
break;
#endif

added at line 243 in Source/lang/LangPrimSource/PyrSerialPrim.cpp
This will only work if OSX actually supports this baudrate.

I hope this helps.

sincerely,
Marije

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/


******************************************

/* Joshua D. Parmenter

http://www.realizedsound.net/josh/


“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono

*/