Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24299 > unrolled thread
| Started by | pozz <pozzugno@gmail.com> |
|---|---|
| First post | 2016-06-23 13:52 +0200 |
| Last post | 2016-06-24 15:11 -0700 |
| Articles | 9 on this page of 49 — 11 participants |
Back to article view | Back to comp.arch.embedded
Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-23 13:52 +0200
Re: Embedded Linux: share data among different processes Jack <jack4747@gmail.com> - 2016-06-23 05:30 -0700
Re: Embedded Linux: share data among different processes Reinhardt Behm <rbehm@hushmail.com> - 2016-06-23 21:05 +0800
Re: Embedded Linux: share data among different processes Clifford Heath <no.spam@please.net> - 2016-06-24 09:45 +1000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-23 17:19 -0700
Re: Embedded Linux: share data among different processes Clifford Heath <no.spam@please.net> - 2016-06-24 13:25 +1000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-23 21:27 -0700
Re: Embedded Linux: share data among different processes Clifford Heath <no.spam@please.net> - 2016-06-24 14:40 +1000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-23 22:20 -0700
Re: Embedded Linux: share data among different processes Clifford Heath <no.spam@please.net> - 2016-06-24 17:19 +1000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 01:01 -0700
Re: Embedded Linux: share data among different processes Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-24 16:38 +0300
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 11:13 -0700
Re: Embedded Linux: share data among different processes Reinhardt Behm <rbehm@hushmail.com> - 2016-06-24 12:39 +0800
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 01:53 -0700
Re: Embedded Linux: share data among different processes Reinhardt Behm <rbehm@hushmail.com> - 2016-06-26 09:34 +0800
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-26 00:30 -0700
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-24 15:18 -0500
Re: Embedded Linux: share data among different processes Mel Wilson <mwilson@the-wire.com> - 2016-06-23 13:47 +0000
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-24 13:36 +0200
Re: Embedded Linux: share data among different processes Mel Wilson <mwilson@the-wire.com> - 2016-06-26 15:25 +0000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-23 12:11 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-24 13:40 +0200
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 10:44 -0700
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-23 12:31 -0700
Re: Embedded Linux: share data among different processes George Neuner <gneuner2@comcast.net> - 2016-06-23 17:27 -0400
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-24 13:43 +0200
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 10:48 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-27 14:46 +0200
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-27 13:41 -0700
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-24 13:52 -0700
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-24 16:42 -0500
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-27 16:00 +0200
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-27 20:06 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-28 08:41 +0200
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-28 00:27 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-28 12:50 +0200
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-28 10:01 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-29 13:10 +0200
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-29 10:47 -0700
Re: Embedded Linux: share data among different processes edward.ming.lee@gmail.com - 2016-06-29 14:01 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-30 15:11 +0200
Re: Embedded Linux: share data among different processes edward.ming.lee@gmail.com - 2016-06-30 08:19 -0700
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-23 14:53 -0500
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-23 13:05 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-24 13:54 +0200
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-24 14:27 -0500
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-24 16:39 -0500
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 15:11 -0700
Page 3 of 3 — ← Prev page 1 2 [3]
| From | edward.ming.lee@gmail.com |
|---|---|
| Date | 2016-06-29 14:01 -0700 |
| Message-ID | <56b12db1-0d16-47d1-98e2-1599d459a4c2@googlegroups.com> |
| In reply to | #24413 |
On Tuesday, June 28, 2016 at 10:01:47 AM UTC-7, Paul Rubin wrote: > pozz <pozzugno@gmail.com> writes: > > I'm going to use lighttpd. Any reason to use nginx instead? > > Lighttpd should be fine. > > > Do you mean to use the local display to show the windows of a web > > browser running on the embedded Linux? > > I meant have the local display run its own browser, viewing stuff served > by the embedded Linux. I.e. the local display would be a small tablet. > Running a browser on the embedded Linux is another idea, hmm, might be > ok if the linux distro supports it. Do you have an SD card slot on the > board? A browser is pretty heavyweight. > > > This could be fine, because the interface will be the same (for the > > user... and for the developer). > > Yes :). > > > - do I need a windows desktop environment (X.org, ...)? > > No. You'll have to run something like X on the local display if you > want to program it with Qt though. Is this a consumer product where you > need a really slick interface, or is it something industrial where it's > more about functionality? > > > - could I force the web browser window to be full-screen? > > I would avoid to see the Close Window button (the X button), > > the minimize button, the back button and so on... > > Yes, that is called "kiosk mode" and there are usually ways to do it. We just use Android Browser (Firefox based) with slide-in controls. It get as full screen as possible. BTW, not as well to do it with Chrome. Customer said: did not have to do lots of work for the app? I said: nothing for the browser, but lots of PHP backend. He did not really understand what i meant.
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2016-06-30 15:11 +0200 |
| Message-ID | <nl35p0$7oq$1@dont-email.me> |
| In reply to | #24470 |
Il 29/06/2016 23:01, edward.ming.lee@gmail.com ha scritto: > On Tuesday, June 28, 2016 at 10:01:47 AM UTC-7, Paul Rubin wrote: >> pozz <pozzugno@gmail.com> writes: >>> I'm going to use lighttpd. Any reason to use nginx instead? >> >> Lighttpd should be fine. >> >>> Do you mean to use the local display to show the windows of a web >>> browser running on the embedded Linux? >> >> I meant have the local display run its own browser, viewing stuff served >> by the embedded Linux. I.e. the local display would be a small tablet. >> Running a browser on the embedded Linux is another idea, hmm, might be >> ok if the linux distro supports it. Do you have an SD card slot on the >> board? A browser is pretty heavyweight. >> >>> This could be fine, because the interface will be the same (for the >>> user... and for the developer). >> >> Yes :). >> >>> - do I need a windows desktop environment (X.org, ...)? >> >> No. You'll have to run something like X on the local display if you >> want to program it with Qt though. Is this a consumer product where you >> need a really slick interface, or is it something industrial where it's >> more about functionality? >> >>> - could I force the web browser window to be full-screen? >>> I would avoid to see the Close Window button (the X button), >>> the minimize button, the back button and so on... >> >> Yes, that is called "kiosk mode" and there are usually ways to do it. > > We just use Android Browser (Firefox based) with slide-in controls. What is it? There some android browsers available. Do you mean mobile version of Firefox? > It get as full screen as possible. BTW, not as well to do it with Chrome. > > Customer said: did not have to do lots of work for the app? I said: nothing for the browser, but lots of PHP backend. He did not really understand what i meant. >
[toc] | [prev] | [next] | [standalone]
| From | edward.ming.lee@gmail.com |
|---|---|
| Date | 2016-06-30 08:19 -0700 |
| Message-ID | <17057327-be8f-46a8-a5e3-e5c4f51ce7b4@googlegroups.com> |
| In reply to | #24482 |
On Thursday, June 30, 2016 at 6:11:00 AM UTC-7, pozz wrote: > Il 29/06/2016 23:01, edward.ming.lee@gmail.com ha scritto: > > On Tuesday, June 28, 2016 at 10:01:47 AM UTC-7, Paul Rubin wrote: > >> pozz <pozzugno@gmail.com> writes: > >>> I'm going to use lighttpd. Any reason to use nginx instead? > >> > >> Lighttpd should be fine. > >> > >>> Do you mean to use the local display to show the windows of a web > >>> browser running on the embedded Linux? > >> > >> I meant have the local display run its own browser, viewing stuff served > >> by the embedded Linux. I.e. the local display would be a small tablet. > >> Running a browser on the embedded Linux is another idea, hmm, might be > >> ok if the linux distro supports it. Do you have an SD card slot on the > >> board? A browser is pretty heavyweight. > >> > >>> This could be fine, because the interface will be the same (for the > >>> user... and for the developer). > >> > >> Yes :). > >> > >>> - do I need a windows desktop environment (X.org, ...)? > >> > >> No. You'll have to run something like X on the local display if you > >> want to program it with Qt though. Is this a consumer product where you > >> need a really slick interface, or is it something industrial where it's > >> more about functionality? > >> > >>> - could I force the web browser window to be full-screen? > >>> I would avoid to see the Close Window button (the X button), > >>> the minimize button, the back button and so on... > >> > >> Yes, that is called "kiosk mode" and there are usually ways to do it. > > > > We just use Android Browser (Firefox based) with slide-in controls. > > What is it? There some android browsers available. Do you mean mobile > version of Firefox? Yes, both mobile and desktop versions of Firefox have full screen mode. > > > > It get as full screen as possible. BTW, not as well to do it with Chrome. > > > > Customer said: did not have to do lots of work for the app? I said: nothing for the browser, but lots of PHP backend. He did not really understand what i meant. > >
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-06-23 14:53 -0500 |
| Message-ID | <nkhegt$lup$1@dont-email.me> |
| In reply to | #24299 |
pozz wrote: > I'm new to embedded Linux so this question could be very simple for many > of you. Most probably, it isn't directly related to embedded world, but > to Linux OS generally. Anyway I think it is a common scenario in > embedded applications. > > I'm going to develop a local/remote control of an electronic device. It > communicates through a RS485 link. > The local control will be a touch-screen display (I'm going to use QT > graphic libraries). > The remote control will be HTTP (web server). > > I think a good approach will be to develop a simple application, the > poller, that communicates with the electronic device and implements the > RS485 protocol. The poller continuously acquires the current > status/settings of the device and store them in some "shared" way. > > The graphic application (QT-based) and the web server (CGI) should > access to the data retrieved by the poller. > > What is the best method to share the data generated by an application > (the poller) among two or more applications (QT and CGI)? > In this scenario, I think it's important to lock the "shared data" > before accessing them (reading or writing), in order to avoid reading > incoerent data. Indeed, if the poller writes the data at the same time > (Linux OS is multi-tasking) the web server reads them, they could be > incoerent. > > I'm thinking to use SQLite database to store the data. The poller writes > the database, HTTP and QT reads from it. It seems SQLite will take care > the multi-thread/multi-process scenario. > > Any suggestions? 1) Qt and HTTP are completely disjoint. Use of Qt is disruptive - it has its own pre-preprocessor and ... keywords specific to Qt. If I could, I would pick one and possibly carve the other off as a separate project. HTTP is, simply put, a bloated, obese protocol which cannot be put on a decent timeline. It's intentionally entanlged with TCP in very unfortunate ways. 2) You mean you will poll for data over an RS485 link, then have two possible clients on a workstation/phone/tablet/whatever that exploit this data. 2a) Is the RS485 link half or full duplex? 2b) If it is half duplex, do you have an accurate model of the line discipline? For example, with MODBUS ( which is 1/2 dux 485 and address muxed ) there will be hard[1] timers to be managed. I recommend a state machine approach. The port cannot be used by more than one request/response pair at a time and response timeouts dominate latency. [1] although they can be made to be adaptive and a select()/poll()/epoll() approach can be quite useful. Much depends on whether the responding node identifies itself in responses. But depending on your serial port architecture, this may get weird. 3) SQLite appears to have locking: https://www.sqlite.org/lockingv3.html 3a) SQL is a bloated pain in the neck. 4) A minimal technology for a shared data store under Linux is shared memory. There are shared memory filesystems or you can develop a shared library/object file which enacts an access protocol for the shared data using the System V primitives. See "System V shmem" and "System V semaphores" through Google for details. This isn't difficult but it's fiddly. It's also the highest performing approach. I;d at least consider guarding the shmem with a semaphore, although I've never established that this is completely necessary 5) Consider using pipes for shared data, possibly. Dunno how you integrate pipes with an HTTP daemon. 6) Sockets are also a good thing to consider using, although again, I have never integrated an HTTP server with sockets for another protocol. Your "poller" offers say, a TCP socket ( to be used over localhost ) and does "multiple unicast" or alternatively actual multicast transmission of the entire data store every so often, or differential ( the things that have changed ) transmission as needed. 6a) Multicast constrains you to the use of UDP. This is a nontrivial project. All this being said, there may be a good software kit to solve this problem out there; I just don't know what it is. and 7) I've seen cases where a COTS HTTP server was used to serve up Java applications to do this. That's kind of old school at this writing. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-23 13:05 -0700 |
| Message-ID | <87mvmbr7q3.fsf@nightsong.com> |
| In reply to | #24306 |
Les Cargill <lcargill99@comcast.com> writes: > This is a nontrivial project. > All this being said, there may be a good software kit to solve this > problem out there; I just don't know what it is. I did something like this (TCP over USB between the base unit and the display) and it wasn't so bad. Yes there was a ton of bloaty system code under the surface (language interpreter, network stack etc.) but who cares? The application itself was reasonably simple. The ARM CPU and 64MB of ram were a few dollars, and the "disk" was a 2GB microSD card that was another couple bucks. The user application was written like any other client-server app. The shared data was managed in the application itself, that ran in a single process (multiple threads), but using a database works perfectly well if you don't mind the overhead. If you have the memory for it, Redis could be a good alternative to SQLite, depending on what the application needs.
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2016-06-24 13:54 +0200 |
| Message-ID | <nkj72b$r1s$1@dont-email.me> |
| In reply to | #24306 |
Il 23/06/2016 21:53, Les Cargill ha scritto: > pozz wrote: >> I'm new to embedded Linux so this question could be very simple for many >> of you. Most probably, it isn't directly related to embedded world, but >> to Linux OS generally. Anyway I think it is a common scenario in >> embedded applications. >> >> I'm going to develop a local/remote control of an electronic device. It >> communicates through a RS485 link. >> The local control will be a touch-screen display (I'm going to use QT >> graphic libraries). >> The remote control will be HTTP (web server). >> >> I think a good approach will be to develop a simple application, the >> poller, that communicates with the electronic device and implements the >> RS485 protocol. The poller continuously acquires the current >> status/settings of the device and store them in some "shared" way. >> >> The graphic application (QT-based) and the web server (CGI) should >> access to the data retrieved by the poller. >> >> What is the best method to share the data generated by an application >> (the poller) among two or more applications (QT and CGI)? >> In this scenario, I think it's important to lock the "shared data" >> before accessing them (reading or writing), in order to avoid reading >> incoerent data. Indeed, if the poller writes the data at the same time >> (Linux OS is multi-tasking) the web server reads them, they could be >> incoerent. >> >> I'm thinking to use SQLite database to store the data. The poller writes >> the database, HTTP and QT reads from it. It seems SQLite will take care >> the multi-thread/multi-process scenario. >> >> Any suggestions? > > 1) Qt and HTTP are completely disjoint. Use of Qt is disruptive - it has > its own pre-preprocessor and ... keywords specific to Qt. If I could, I > would pick one and possibly carve the other off as a separate project. > > HTTP is, simply put, a bloated, obese protocol which cannot be put on a > decent timeline. It's intentionally entanlged with TCP in very > unfortunate ways. QT choice could be changed, but the embedded Linux platform I'm going to use is shipped with many ready-to-use examples of simple QT applications that use the TFT touch display. This is the main reason of QT choice. HTTP server is a requirement: the users will be able to connect to the Linux box through a simple web browser. Of course I will use a ready-to-use HTTP server (I'm thinking of lighttpd) with client-side javascripts to retrieve data from a server-side script (a simple cgi). Anyway they are really *two* different projects/processes running on the same Linux box. I couldn't understand why you compare QT and HTTP. > 2) You mean you will poll for data over an RS485 link, then have two > possible clients on a workstation/phone/tablet/whatever that exploit > this data. There is only one process that will access the RS485 link, the "poller" process running on the embedded Linux board. The data will be shared at the Linux board level, not RS485 link. > 2a) Is the RS485 link half or full duplex? Half duplex. > 2b) If it is half duplex, do you have an accurate model of the > line discipline? For example, with MODBUS ( which is 1/2 dux 485 and > address muxed ) there will be hard[1] timers to be managed. I > recommend a state machine approach. The port cannot be used by more > than one request/response pair at a time and response timeouts > dominate latency. > > [1] although they can be made to be adaptive and a > select()/poll()/epoll() approach can be quite useful. Much depends on > whether the responding node identifies itself in responses. But > depending on > your serial port architecture, this may get weird. I don't think I will have problems with protocol at the RS485 wire level. > 3) SQLite appears to have locking: > https://www.sqlite.org/lockingv3.html So it should be ok for my application. > 3a) SQL is a bloated pain in the neck. Really? I thought exactly the opposite thing. Why? > 4) A minimal technology for a shared data store under Linux is shared > memory. There are shared memory filesystems or you can develop a shared > library/object file which enacts an access protocol for the shared > data using the System V primitives. See "System V shmem" and "System V > semaphores" through Google for details. This isn't difficult but it's > fiddly. It's also the highest performing approach. I;d at least > consider guarding the shmem with a semaphore, although I've never > established that this is completely necessary At the moment I think it's the best solution for me. I started studying the shared memory under Linux. I never used it before. > 5) Consider using pipes for shared data, possibly. Dunno how you > integrate pipes with an HTTP daemon. It seems to me, shared memory fits better on my application. > 6) Sockets are also a good thing to consider using, although again, I > have never integrated an HTTP server with sockets for another protocol. > Your "poller" offers say, a TCP socket ( to be used over localhost ) > and does "multiple unicast" or alternatively actual multicast > transmission of the entire data store every so often, or differential ( > the things that have changed ) transmission as needed. Yes, sockets are another approach for inter-process communication. Maybe I will start with shared memory. > 6a) Multicast constrains you to the use of UDP. > > This is a nontrivial project. Yes, I know. > All this being said, there may be a good software kit to solve this > problem out there; I just don't know what it is. I hope it really exists and someone will point me to it. > > and > > 7) I've seen cases where a COTS HTTP server was used to serve up Java > applications to do this. That's kind of old school at this writing. >
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-06-24 14:27 -0500 |
| Message-ID | <nkk1cg$ql4$1@dont-email.me> |
| In reply to | #24323 |
pozz wrote: > Il 23/06/2016 21:53, Les Cargill ha scritto: >> pozz wrote: >>> I'm new to embedded Linux so this question could be very simple for many >>> of you. Most probably, it isn't directly related to embedded world, but >>> to Linux OS generally. Anyway I think it is a common scenario in >>> embedded applications. >>> >>> I'm going to develop a local/remote control of an electronic device. It >>> communicates through a RS485 link. >>> The local control will be a touch-screen display (I'm going to use QT >>> graphic libraries). >>> The remote control will be HTTP (web server). >>> >>> I think a good approach will be to develop a simple application, the >>> poller, that communicates with the electronic device and implements the >>> RS485 protocol. The poller continuously acquires the current >>> status/settings of the device and store them in some "shared" way. >>> >>> The graphic application (QT-based) and the web server (CGI) should >>> access to the data retrieved by the poller. >>> >>> What is the best method to share the data generated by an application >>> (the poller) among two or more applications (QT and CGI)? >>> In this scenario, I think it's important to lock the "shared data" >>> before accessing them (reading or writing), in order to avoid reading >>> incoerent data. Indeed, if the poller writes the data at the same time >>> (Linux OS is multi-tasking) the web server reads them, they could be >>> incoerent. >>> >>> I'm thinking to use SQLite database to store the data. The poller writes >>> the database, HTTP and QT reads from it. It seems SQLite will take care >>> the multi-thread/multi-process scenario. >>> >>> Any suggestions? >> >> 1) Qt and HTTP are completely disjoint. Use of Qt is disruptive - it has >> its own pre-preprocessor and ... keywords specific to Qt. If I could, I >> would pick one and possibly carve the other off as a separate project. >> >> HTTP is, simply put, a bloated, obese protocol which cannot be put on a >> decent timeline. It's intentionally entanlged with TCP in very >> unfortunate ways. > > QT choice could be changed, but the embedded Linux platform I'm going to > use is shipped with many ready-to-use examples of simple QT applications > that use the TFT touch display. This is the main reason of QT choice. > Ah, so there you go. > HTTP server is a requirement: the users will be able to connect to the > Linux box through a simple web browser. Of course I will use a > ready-to-use HTTP server (I'm thinking of lighttpd) with client-side > javascripts to retrieve data from a server-side script (a simple cgi). > > Anyway they are really *two* different projects/processes running on the > same Linux box. I couldn't understand why you compare QT and HTTP. > Possibly because one could be done away with - I don't know the customer requirements necessarily. > >> 2) You mean you will poll for data over an RS485 link, then have two >> possible clients on a workstation/phone/tablet/whatever that exploit >> this data. > > There is only one process that will access the RS485 link, the "poller" > process running on the embedded Linux board. > The data will be shared at the Linux board level, not RS485 link. > > >> 2a) Is the RS485 link half or full duplex? > > Half duplex. > > As long as you've played that game before, you should be fine. >> 2b) If it is half duplex, do you have an accurate model of the >> line discipline? For example, with MODBUS ( which is 1/2 dux 485 and >> address muxed ) there will be hard[1] timers to be managed. I >> recommend a state machine approach. The port cannot be used by more >> than one request/response pair at a time and response timeouts >> dominate latency. >> >> [1] although they can be made to be adaptive and a >> select()/poll()/epoll() approach can be quite useful. Much depends on >> whether the responding node identifies itself in responses. But >> depending on >> your serial port architecture, this may get weird. > > I don't think I will have problems with protocol at the RS485 wire level. > > >> 3) SQLite appears to have locking: >> https://www.sqlite.org/lockingv3.html > > So it should be ok for my application. > > >> 3a) SQL is a bloated pain in the neck. > > Really? I thought exactly the opposite thing. Why? > > That's my opinion, but it's based on (biased) direct observation. This is mainly true because it's completely a string interface and constructing queries dynamically requires marshalling and unmarshalling a pseudo-natural language. Plus, the infrastructure can be somewhat daunting - although I've seen mainly MS SQL Server rather than SQLite. >> 4) A minimal technology for a shared data store under Linux is shared >> memory. There are shared memory filesystems or you can develop a shared >> library/object file which enacts an access protocol for the shared >> data using the System V primitives. See "System V shmem" and "System V >> semaphores" through Google for details. This isn't difficult but it's >> fiddly. It's also the highest performing approach. I;d at least >> consider guarding the shmem with a semaphore, although I've never >> established that this is completely necessary > > At the moment I think it's the best solution for me. I started studying > the shared memory under Linux. I never used it before. > > >> 5) Consider using pipes for shared data, possibly. Dunno how you >> integrate pipes with an HTTP daemon. > > It seems to me, shared memory fits better on my application. > > I like it myself; some do not. >> 6) Sockets are also a good thing to consider using, although again, I >> have never integrated an HTTP server with sockets for another protocol. >> Your "poller" offers say, a TCP socket ( to be used over localhost ) >> and does "multiple unicast" or alternatively actual multicast >> transmission of the entire data store every so often, or differential ( >> the things that have changed ) transmission as needed. > > Yes, sockets are another approach for inter-process communication. Maybe > I will start with shared memory. > > >> 6a) Multicast constrains you to the use of UDP. >> >> This is a nontrivial project. > > Yes, I know. > > >> All this being said, there may be a good software kit to solve this >> problem out there; I just don't know what it is. > > I hope it really exists and someone will point me to it. > You'd think, wouldn't you? >> >> and >> >> 7) I've seen cases where a COTS HTTP server was used to serve up Java >> applications to do this. That's kind of old school at this writing. >> > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-06-24 16:39 -0500 |
| Message-ID | <nkk92q$k3p$1@dont-email.me> |
| In reply to | #24299 |
pozz wrote: > I'm new to embedded Linux so this question could be very simple for many > of you. Most probably, it isn't directly related to embedded world, but > to Linux OS generally. Anyway I think it is a common scenario in > embedded applications. > > I'm going to develop a local/remote control of an electronic device. It > communicates through a RS485 link. > The local control will be a touch-screen display (I'm going to use QT > graphic libraries). > The remote control will be HTTP (web server). > > I think a good approach will be to develop a simple application, the > poller, that communicates with the electronic device and implements the > RS485 protocol. The poller continuously acquires the current > status/settings of the device and store them in some "shared" way. > > The graphic application (QT-based) and the web server (CGI) should > access to the data retrieved by the poller. > > What is the best method to share the data generated by an application > (the poller) among two or more applications (QT and CGI)? > In this scenario, I think it's important to lock the "shared data" > before accessing them (reading or writing), in order to avoid reading > incoerent data. Indeed, if the poller writes the data at the same time > (Linux OS is multi-tasking) the web server reads them, they could be > incoerent. > > I'm thinking to use SQLite database to store the data. The poller writes > the database, HTTP and QT reads from it. It seems SQLite will take care > the multi-thread/multi-process scenario. > > Any suggestions? I also stumbled onto a Go implementation that looks interesting. This for an old scale with an RS232 port a guy found in a junk pile. https://gist.github.com/sielickin/8cc79f0cb6a4b4c229b9786dffcabdbe Go has a whole lot of web furniture built in. No clue how you'd add the Qt program to that, however ( I'd guess a socket server ). Dunno if Go can easily be embedded or not; but with RasPi and BB Black these days.... -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-06-24 15:11 -0700 |
| Message-ID | <nkkb83$vd3$1@dont-email.me> |
| In reply to | #24342 |
On 6/24/2016 2:39 PM, Les Cargill wrote: > I also stumbled onto a Go implementation that looks interesting. > This for an old scale with an RS232 port a guy found in a junk pile. > > https://gist.github.com/sielickin/8cc79f0cb6a4b4c229b9786dffcabdbe > > Go has a whole lot of web furniture built in. No clue how you'd add the Qt > program to that, however ( I'd guess a socket server ). > > Dunno if Go can easily be embedded or not; but with RasPi and > BB Black these days.... Inferno can easily do this (esp for applications that aren't very "demanding"). There's a nominal HTTPd included in the (free) distribution. Inferno (through its Limbo language) also supports communication channels as first-class objects. E.g., the OP's "poller" can just pass specific typed objects down a channel (like a pipe -- except the endpoints can be on different CPUs, etc.) connecting it to the "user interface/web server" task. For endpoints on the same host (i.e., you don't have to worry about handling "remote host not available" conditions), the code is trivial. One delightful advantage of the distributed capabilities of Inferno is that you can run hosted inferno on a PC and interact with the application "naturally" without any artificial IDE's. I.e., you could simulate the poller by writing a Limbo app that accepts keyboard input and passes it to the "user interface" task -- running on your target hardware -- without making any significant changes to the system as a whole. If you can pick hardware for which a *native* Inferno port is available (e.g., rpi), then your total footprint can be under ~1MB for the OS *and* your application. Limbo apps are amazingly small; and, its close enough to C that it isn't terribly intimidating though lack of support for pointers can be distressing; and, getting used to tuples takes a few *seconds* (at which point, you'll wonder how you ever lived without them!)
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.arch.embedded
csiph-web