Re: [Emc-users] Serial comms within a userspace component

[Gene Heskett]

On Thursday 05 July 2012 08:27:51 Schooner did opine:

> Hi Gene
> 
> >>You did #include stdio.h I assume...
> 
> Yes and unistd.h etc, as I said it compiles fine in both and runs
> properly from the command line
> 
> >>I'm thinking that because of the type you used for 'fd', that it may
> >>well be volatile, and out of that functions 'scope' by the time you
> >>actually do the above write.
> 
> fd is a simple C int.

In the environment I was working in at that time, fd was actually an 
unsigned byte sized value because the system itself was comparatively 
small, on a pseudo 21 bit address that in my own system had been expended 
to 24 bits in order to address 2 megabytes of memory which was paged in and 
out of a 16 bit cpu's view.  Os9/Nitros9 on a Trash 80 Color Computer 3 
whose MC58B09EP cpu had been swapped out for the smarter Hitachi HD63C09EP.

That byte, IIRC was used as an offset into the opened device list that os9 
maintained.

> Rather than being a pointer, it is an index to a look-up table (the file
> descriptor table)

Much the same idea but a wider int as at least 32 bits of memory are 
available on modern machines.
 
> However you could be on to something, because stdin/stdout/stderr are
> predefined as 0,1 and 2 respectively so if the file descriptor is
> getting an erroneous value or losing the value it could still be
> pointing to a 'file', hence the print to screen
> 
> Yahoo, I have cracked it.
> 
> I was using the EXTRA_SETUP and EXTRA_CLEANUP macros to initiate serial
> connection and close and restore settings respectively. This was
> largely to keep the main section of code un-cluttered and easy to
> maintain.
> 
> Doing this necessitated a global fd accessed across several functions.
> 
> Changing the program flow, so that each function holds its own copy of
> fd, passed from the calling or called function, results in a perfectly
> executing component.
> 
> Thank you Gene, I just needed a kick in the right direction

It did seem to walk and quack like a 'scope' problem.  Glad I could help.
 
> regards

You're welcome.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
'Ooohh.. "FreeBSD is faster over loopback, when compared to Linux
over the wire". Film at 11.'
-- Linus Torvalds

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Serial comms within a userspace component

[Schooner]

Hi Gene

>>You did #include stdio.h I assume...

Yes and unistd.h etc, as I said it compiles fine in both and runs properly from 
the command line

>>I'm thinking that because of the type you used for 'fd', that it may well
>>be volatile, and out of that functions 'scope' by the time you actually do
>>the above write.

fd is a simple C int.
Rather than being a pointer, it is an index to a look-up table (the file 
descriptor table)

However you could be on to something, because stdin/stdout/stderr are 
predefined as 0,1 and 2 respectively
so if the file descriptor is getting an erroneous value or losing the value it 
could still be pointing to a 'file', hence
the print to screen

Yahoo, I have cracked it.

I was using the EXTRA_SETUP and EXTRA_CLEANUP macros to initiate serial 
connection and close and restore settings respectively.
This was largely to keep the main section of code un-cluttered and easy to 
maintain.

Doing this necessitated a global fd accessed across several functions.

Changing the program flow, so that each function holds its own copy of fd, 
passed from the calling or called function, results in
a perfectly executing component.

Thank you Gene, I just needed a kick in the right direction

regards



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Serial comms within a userspace component

[Michael Haberler]

It would help if you post the code and the invocation of the component on 
pastebin.com


what you would want to do is:
- pass the device *name* as an command line argument to the component
- open the device 
- use the resulting *file descriptor*

for examples how to pass command line arguments in a C userspace component, see 
the drivers in src/hal/user_comps

what exactly is a 'socket server'?

-m


Am 04.07.2012 um 18:22 schrieb Schooner:

> Hi
> I have been playing with a C userspace component to pass values from 
> Linuxcnc to an arduino for display on a pendant LCD.
> 
> The code works perfectly from a commandline program but when inserted 
> into a component, it compiles and runs but each
> write(fd, buff, sizeof(buff)) goes to stdout / stderr instead of the
> place fd points to, which is /dev/ttyUSB0
> 
> I can connect to a socket server from within the userspace component
> and pass the values indirectly, but it is bugging me to distraction that 
> perfectly normal serial comms code which can be shown to work elsewhere 
> will not work properly in the component.
> 
> If anyone has any ideas why this should be, I would be grateful!
> 
> regards
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Serial comms within a userspace component

[Gene Heskett]

On Wednesday 04 July 2012 14:32:06 Schooner did opine:

> Hi
> I have been playing with a C userspace component to pass values from
> Linuxcnc to an arduino for display on a pendant LCD.
> 
> The code works perfectly from a commandline program but when inserted
> into a component, it compiles and runs but each
> write(fd, buff, sizeof(buff)) goes to stdout / stderr instead of the
> place fd points to, which is /dev/ttyUSB0
> 

Basic C stuff AIRemember:

You did #include stdio.h I assume...

And what is the type of 'fd'?  studio.h should define that globally, or did 
the last time I used it. (And I am assuming you are in fact opening a path 
to it prior to the write)

I'm thinking that because of the type you used for 'fd', that it may well 
be volatile, and out of that functions 'scope' by the time you actually do 
the above write.  Some printf's to stdout as to the value of 'fd' may be 
enlightening, bearing in mind that 'fd' should be a pointer, and should 
retain its value when printf'd in the next line after the open, and should 
be identical in a printf in front of your write, both as 'fd' and as '*fd'.

OTOH its been much of a decade since I last carved any fresh C, so my 
ancient memory could well be full of it.

> I can connect to a socket server from within the userspace component
> and pass the values indirectly, but it is bugging me to distraction that
> perfectly normal serial comms code which can be shown to work elsewhere
> will not work properly in the component.
> 
> If anyone has any ideas why this should be, I would be grateful!
> 
> regards
> 
> 
> -- Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions will include endpoint security, mobile security and the
> latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
Democracy is a government where you can say what you think even if you
don't think.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Serial comms within a userspace component

[Schooner]

Hi
I have been playing with a C userspace component to pass values from 
Linuxcnc to an arduino for display on a pendant LCD.

The code works perfectly from a commandline program but when inserted 
into a component, it compiles and runs but each
write(fd, buff, sizeof(buff)) goes to stdout / stderr instead of the
place fd points to, which is /dev/ttyUSB0

I can connect to a socket server from within the userspace component
and pass the values indirectly, but it is bugging me to distraction that 
perfectly normal serial comms code which can be shown to work elsewhere 
will not work properly in the component.

If anyone has any ideas why this should be, I would be grateful!

regards

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users