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.
You need to supply quite a lot more information than that.
A lot of bar code readers emits then bar code as ASCII text on some form of serial interface (PS/2, RS-232, USB, ...)
The manufacturer of the bar code reader normally have data sheets that describes exactly what variants of bar codes the reader can handle, and exactly the format of the messages sent out. Without such a datasheet, it will be up to you to figure out format and framing of the data.
Thanks for your reply.
The barcode pen just has a digital (I think TTL) output. The datasheet says that it is a raw output.
When I scope it I think I see a pulse for each black bar.
Any ideas how I can get the data from this?
Nazir,
There are probably a lot of ways of accumulating the pulse train from a barcode pen.
The concept I used was to feed the input into INT0 or INT1 and configure for edge triggering.
BUT ... Edge triggering on the humble 8051 is only detected on a negative going edge. You will need to generate an interrupt on both edges.
What I did was use an 'exclusive or' gate to programmatically invert the input signal by feeding an output port pin to the input of the gate.
As I said, there are other methods to do this, but this worked very well for me and allowed me to have two barcode pens coming into the CPU; one interrupt input per pen.
Now, I'm very confused.
Are there two "Nezir Patak" in this thread? One that needs help, and one that tells how he solved the problem - the second one also directing the answer to someone named "Nazir" and that doesn't seem to have posted in this thread...
About free code. Most people who answer questions here are professional software developers. The code we write are either owned by the company we work for, or we work as free-lance developers and the code we write may (depending on contract conditions) become the property of the customers we write it for.
Hence, there are noremally no code to give away for free.
Sorry people - And especially to Nezir,
I am the second Nezir Patak!
Not sure how I managed to do that, but I suspect it was something to do with the constant interruptions I keep getting from the phone, colleagues etc. while I was entering my response.
Anyway - Hope the real Nezir finds the text of my response helpful.
The post form for this forum could have been a bit better. Quite a lot of people regularly manages to post using funny names since a new input form always starts with the name field selected, and when entering text in the message box, the name fields are often too high up on the form to be visible.
Thanks for the suggestions and advise. We have a lot of the barcode pens already and we want to use them. I think we will try to do our own board with an 8052.
I understand that you cannot give me all the code (and greedy Erik wants me to pay to much). I would be happy for you to give me any routines to help. I found aimglobal and they have specs for different barcodes but I didnt see one for code 128. Do you know where to get the specs?
Nezir,
You can find specifications for code 128 on the aim website (but you'll have to pay!):
www.aimglobal.org/.../ProductDetails.aspx
Also found some details at:
www.neodynamic.com/.../Code_128_Barcode.aspx
Just do a search on "aim code 128" - You'll find a lot!
What product are you hoping to develop? Does it have to be code 128? Will you need to read any other types?
The reference algorithm AIM provided for that was actually pretty good. I loosely based ours on that but included things that we had learnt when we developed other decodes.
I'm a bit out of this area now, but if you're hoping to sell into the industrial market, then maybe you should look at code 39. That used to be the more accepted type.
Please also note that you WILL be looking at a quite lengthy development.
Are you sure you really need to do it?
Nezir Patak said, "greedy Erik wants me to pay too much"
David Rose, who is clearly familiar with the work involved, said, "note that you WILL be looking at a quite lengthy development"
"Lengthy Development" equals "Lots of money", especially if you're paying a US developer - so probably Erik is not being "greedy"?
Again, as David said, Are you sure you really need to do this? In other words, Are you sure you really want to incur the development costs to do this?
Reread my second post - the one after you wrote that the pen was TTL-logic.
Both Andy and Per are right to warn you about this!
When I did this, 2D barcode technology was cutting edge and development environments were far less sophisticated than the likes of Keil products.
The fact that it was done in 100% assembler with those older tools is not the reason it took so long to develop (about 6-9 man months per decode). The problem was that to do it well requires considerable understanding of a lot of intangibles; and to achieve that understanding requires time.
Ok - You might be able to find some documents on the Internet that can guide you; but it will take some considerable time.
I don't know where Erik got his figure from for a cost; maybe simply TimeTakenToDevelop*CostPerDay. I would say that instead of being greedy, he is possibly being quite generous!
So you have choices:
1 - Consider his offer 2 - Consider spending a long time doing it yourself 3 - Consider following another path
Whoops,
I should have referred to 1D barcodes being the cutting edge at the time.
and greedy Erik wants me to pay to much nothing 'greedy' there, the price reflects the time needed to make a working, reliable scan decoder.
You seem to be under the impression that this is something someone can whip up in a weekend, you are grossly mistaken.
If all you want is something that works when the pen is moved at a constant predetermined speed over a perfectly printed barcode then, of course, the price may seem unreasonable, so go do it yourself and
have fun, i hope you will.
Erik
PS do not be stupid when you give your supervisor an estimate of the time to do this.
Thanks for all youre help and advise. I will talk to my manager and list the options. I know now that this is not a weekend job and I will look for code on the internet maybe open source I hope.
Maybe if I do it I sell the code to Erik for lots of money ;)
If you want to sell to Erik - make sure to use large memory model ;)
I am not a buyer, but if you manage to make a reader that can handle all situations (speed/skew/print/jitter/etc) it will be worth "lots of money"
ERrik
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.
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.
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...
View all questions in Keil forum