We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all,
Has anyone got any ideas about where to get some C code to read a barcode?
Ive got a pen but dont know what to plug it to.
If you want to sell to Erik - make sure to use large memory model ;)
And use an RTOS, with the critical ISR code in C and with all compiler optimizations enabled ;)
Oh, and remember to include a static function in every module called DoTheLazyDog().
I dont understand this? Is it another joke?
Yes, a private joke. :)
Erik does not like the large memory model. Don't worry about it. Just figure out how much time you are willing to spend on the above project - and what quality requirements you have for the scanning.
Just figure out how much time you are willing to spend on the above project and then multiply by, at least, 5 before giving anyone an estimate.
Erik
PS: I am not trying to "be negative" just trying to make you aware that you will have to handle an input that varies in ALL respects from scan to scan.
just visualize the read of bars like this
___ _ __| |__| |__
the width of the pulses depend on the speed of the pen movement the speed of the pen movement is not constant across the entire barcode the pen will be at different distances from the code through the scan the printing of the barcode is never perfect some will scan left to right, some the other way .. I leave it to you to imagine the remaining variables
Does the data sheet mention if the pen has a schmitt-trigger input?
When the the pen sees pure black or white, it is easy to realize that the expected output should be a zero or a one. But if the bars have fuzzy edges, the reader will have a hard time to decide where/when to switch between a zero and a one. If the reader doesn't have a hysterese, it may emit a large number of transitions when seeing these fuzzy edges.
Nezir,
The messages you're getting here are, I think, absolutely right.
The reference algorithms contain the basic functionality. I have just found a copy of one of the AIM documents (code 93) that states:
"In addition, perform such other secondary checks on quiet zones, beam acceleration, absolute timing, etc., as are deemed prudent and appropriate considering the specific reading device and application environment."
Basically, it's a massive get-out clause that gives anyone who develops such a system a massive amount of investigative and experimental research. I can assure you that this is the part that really takes time to develop.
If you do go ahead with it, give yourself plenty of time to do your own development. Maybe you'll strike gold and find something on the Internet.
Either way, good luck.
Maybe you'll strike gold and find something on the Internet.
my internet experience confirm the old saying "not all that glitters is gold".
That sounds about right.
Maybe I should have highlighted the 'maybe'!
"Maybe you'll strike gold and find something on the Internet."
If you don't understand the issues involved, how will you be able to distinguish the gold from the stuff that's just yellow and shiny - but useless...?!
Even if the source code is "free" (as in beer), there is still likely to be a lot of work to turn that into a product...