Author Topic: Buffering a scanned row of data  (Read 512 times)

0 Members and 1 Guest are viewing this topic.

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Buffering a scanned row of data
« on: August 04, 2020, 10:00:27 am »
I'd like to build a application that scans row by row data while the user inserts a encoded key.

Each row has a trigger signal, and some data signals which are valid at the trigger moment until a milli seconds later. The row data is fed to a Arduino (Mega 2560), it will probably be fast enough to handle it. Reading the last data signal before it is lost. But I think buffering this data is more reliable.

I think using this ic (cd54hc377) will do the trick (using the trigger as the clock signal). It also has opportunity to ensure no new trigger can mix two rows. (Data enable)

https://www.ti.com/lit/gpn/cd54hc377

Would this ic be a good choice, or are there more suitable ones?
« Last Edit: August 04, 2020, 10:15:27 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline OM222O

  • Frequent Contributor
  • **
  • Posts: 768
  • Country: gb
Re: Buffering a scanned row of data
« Reply #1 on: August 04, 2020, 10:05:37 am »
If it doesn't have to be analyzed on an mcu, just dump all the data to a PC and let that handle everything for you. Much more options for filtering, averaging, rejecting bad data, having a lot of memory for the buffering, etc etc.
 

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Re: Buffering a scanned row of data
« Reply #2 on: August 04, 2020, 10:11:06 am »
It needs to be handled on the mcu. The signals are ok and the speed at which rows follow each other is dependent on how fast the key is inserted, but the mcu should be able to handle them with ease.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Unixon

  • Frequent Contributor
  • **
  • Posts: 400
Re: Buffering a scanned row of data
« Reply #3 on: August 04, 2020, 10:48:47 am »
ATmega2560 has entire 8-bit ports available for I/O. If you allocate all data lines to a single port you can read entire port with a single operation on a trigger interrupt. This wouldn't take that many cycles to make it unreliable. Since all operation depends on timings I can't say for sure that such buffering is not required, but I honestly doubt it.
 
The following users thanked this post: HendriXML

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Re: Buffering a scanned row of data
« Reply #4 on: August 04, 2020, 11:01:48 am »
ATmega2560 has entire 8-bit ports available for I/O. If you allocate all data lines to a single port you can read entire port with a single operation on a trigger interrupt. This wouldn't take that many cycles to make it unreliable. Since all operation depends on timings I can't say for sure that such buffering is not required, but I honestly doubt it.
Sounds interesting, will investigate it!

It's probably best to do both.

The insertion of the key can also be slowed down, but the reliability should not depend on that too much  :o.
« Last Edit: August 04, 2020, 12:51:56 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf