Hidden latencies and delays for a running program?

That seems a bit depressing - either they are hardware guys that write buggy code because they don't understand software, or they are software guys that write buggy code because they don't understand hardware!

Personally, I've both a (digital) hardware and software guy. Maybe that means I don't understand anything...

Or maybe we are minor deities?

Well, my customers are always expecting miracles!

That was the intent of my innuendo. If you're keen on *knowing* these sorts of things, it's not hard to tease approximate answers from published documents.

Ah, OK.

Understood.

Your meaning was understood. (at least by *me* :> )

Then you're different than many (most?). I recall a close friend asking me for some help in specifying an ADC (*board*!) for use in his thesis. I inquired as to what he was trying to do:

"I want to attach a knob to the device so you can turn the knob to adjust simulation rates instead of having to type in numbers; it seems like a more intuitive interface. I could just read the ADC and use *that* value to set the speed at which I run the simulation"

"Um, why don't you just use a little RC oscillator -- running at some nominally convenient frequency -- that you can use to trigger a LOW PRIORITY interrupt (i.e., if you *miss* the IRQ, you don't really care!) and measure the time between interrupts?"

Software mindset (his) vs. hardware mindset (mine).

I came from a hardware background (wanting to design processors) but, too late, realized that the CS curriculum (a subset of the EE curriculum) would primarily expose me to *software*.

[The *other* EE options wouldn't give me the background I wanted, either! So, I had to aggressively pursue the courses that I wanted to get the background that I felt I needed for *my* goals]

As a result, my hardware designs (logic) look a lot like software and my software designs look a lot like *hardware*. And, it also explains why I have so little problems dealing with parallelism, pointers, etc. -- I "see" the hardware involved and think nothing of it.

In hindsight, I hit the sweet spot with my education and experience. Most of the folks that I know who do hardware have very boring jobs. And, those who do software end up feeling like the tail being wagged by the dog (being *handed* some hardware and told -- by a hardware guy who "doesn't understand" :> -- that they can make it do what is needed in the product)

[I write the code for the hardware I design so I make all the tradeoffs to *my* advantage -- regardless of which hat I'm wearing! :> ]

Ditto. Though I find myself even shedding much of those activities as projects get more complex -- complexity invariably *only* possible to provide in software. The *application* is where all the fun lies, not the hardware or software!

Thanks, Don. What an exposition! It looks like a buffer approach is going to be best. Is there a preferred way to share memory? Could a SATA SSd be somehow accessed by two cpu's?

I think someone already asked you to learn to snip, and I know I have asked you to stop using the abominable google groups - get a newsreader, and get a newserver.

Forget the SSD. You haven't a clue what you need or want - but I can guarantee 100% without a doubt that you will never get anything working with SATA or SSD's except as normal disks attached to a PC card running a full OS (such as Linux). No experienced developer would ever consider bare-metal access to an SSD, and the level of ignorance shown by your questions here beggars belief.

Please give up on this project. You are not qualified for it. The problem is not that you don't know all the issues - that is normal at the start of a project. Your problems are:

1. You have no idea what the project should do.
2. You have no idea of the real requirements.
3. You do not understand that 1 and 2 are problems.
4. You do not understand any of the hardware involved in possible implementations.
5. You do not understand any of the software involved.
6. You do not understand that 4 and 5 are problems.
7. You are fixed on certain ideas for a solution, though they have no connection with reality.
8. You repeatedly ask the same questions in different ways, and politely thank people for their answers even though you do not read what they write, do not understand the little you read, and do not take advantage of the good advice you get.

Tell your boss that you cannot do the project alone - you need help, from someone who is able to plan and organise, who can find the right people to talk to, and get the information needed and get the work done.

I am not telling you this to be cruel or unkind - I am telling you this because it will save you and everyone around you considerable pain and wasted time and money if you change direction now, rather than in a year's time when you have still got nowhere.

David

[...BIG SNIP...]

Complete nonsense on Raspberry Pi some OLD benchmarks for a system using ARM and GPIO and Linux from userland and lower on this page

Some GPIO libraries have attained some high speeds and one has made an application that talks to a GPIO deamon and does a multi-channel logic analyzer wit display from multiple GPIO inputs. See

and piscope on

So this proves to me you have done NO research or even anything useful you are just asking questions until someone either

a) gives an answer agreeing with your 'solution' which is not a solution

b) says they will give you the complete works for FREE

c) point you at a pre-made solution that matches you changing specification and probably has to be FREE, which obviously needs to have a TPI - Tele-Pathy Interface

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
  Raspberry Pi Add-ons 
 Timing Diagram Font 
 For those web sites you hate

[my original lengthy reply elided]

Please edit any included text to remove anything not germane to your followup comments. *Not* doing so is rude -- it says "My time is SO much more important than YOURS... I can't be bothered to take the time to trim my response appropriately but *you* (all) should be willing to spend YOUR time scrolling through it LOOKING for any comments I may have chosen to embed within it." When you are counting on the benevolence of others to HELP YOU with your query, it's sort of silly to ANNOY them in the process!

You are only sharing memory between two different parts of the same program (presumably, a single CPU). The issue will be ensuring that those two different pieces of code don't BOTH try to access the same parts of memory concurrently (or nearly so) given that they will

*probably* be invoked asynchronously wrt each other (e.g., the producer most likely an ISR).

Keywords you may find helpful: mutex, critical region, atomic operation, FIFO management, synchronization, etc.

This is *old* technology. You should be able to find examples of code that does exactly this (as it is encountered in damn near every application that talks to the outside world).

You don't need two CPUs -- that just makes things more complicated: then you have to physically share access to a single peripheral along with any state defining each CPU's past/current accesses to it.

Do yourself a favor: write a little piece of code that takes keys from the (PC?) keyboard and copies them to a contiguous area in memory (e.g., a "buffer" os some nontrivial size). When the buffer is full, print out its contents.

I.e., if the buffer is big enough for 26 characters and you type the keys 'a' through 'z', it should print "abcdefghijklmnopqrstuvwxyz" AFTER you have typed the final 'z' (which "filled" the buffer).

Then, terminate the program.

*BUT*, as you are copying each keystroke detected, invoke sleep(2) -- or something quivalent -- to ensure the program is "stuck" in the copying act for a noticeable amount of time (e.g., 2 seconds) before being able to check for the next keystroke. In effect, the PROGRAM will only be looking for a keystroke every ~2 seconds.

Then, start the program and type the letters of the alphabet, slowly, pausing a *few* seconds between each. Verify the output is as expected once you type the final 'z'.

Repeat the exercise but, this time, type one character every ONE *second*. Once you get to 'z', start typing '*' until the program spits out it's result.

Repeat this, yet again, typing two characters every second (this should be easy to do, physically).

Then, again, at *three* per second... etc.

Look at your results. Think about what you *thought* was happening (when you wrote the code). Think about what *must*, instead be happening.

Don't GUESS -- invest some of YOUR precious time experimenting.