Presently I am using Javapos for Communicating with peripherals , is any other option available to communicate with Peripherals like Pos Printer , Pos cash drawer etc with out Javapos directly to Peripherals from Java code.
Can we Use Opos or any other option like Javapos to communicate with peripherals ?
Is opos is platform independent ? whether it will work in windows and Linux ?
For question 1, according to the UPOS specification, there are JavaPOS, OPOS and POS .NET that you can use to control the peripherals without any knowledge of the hardware.
However, it is not necessary for peripheral's vendor to provide all of them for customers.
Therefore, you can only use the device/object service that the peripheral vendor provided unless you have the hardware programming guide.
For question 2, OPOS is tied to Windows because it is based on OLE and COM and it needs to communicate with hardware. (See Appendix A of the UnifiedPOS specification.)
Related
I am just learning about embedded systems and checking about wifi modules. I see in the datasheet they mention about a core processor that is integrated with rf SoC. I also see another processor on the MCU called application processor. I am confused about its purpose. What is it used for? Can someone please clarify? For reference, I was reading about the ATSAMW25 module.
Typically, devices that include wireless technologies (whether its Bluetooth/BLE, WiFi, LoRa, etc) include both the hardware required to manage the wireless connectivity and then separate hardware for running the higher-level application of the system. Frequently, managing the wireless protocol is intensive enough that it is best done with its own small processor running its own firmware to deal with connectivity and sending data over the link and might include a fair amount of proprietary firmware from the vendor (ie, Microchip in your example). To enable programmers to write their own code for the system, these protocol processors are paired with application processors, ones for whom the development tools and documentation are more openly available to developers for implementing whatever they want to do with the module. By separating the two operations (wireless/protocol and application), the code developers implement has less chance of causing fundamental problems for the wireless connectivity (like, application code hanging causes entire WiFi networks to fail) and the proprietary aspects of the system can be better protected (or another way, more documentation can be provided to developers without signing an NDA as the application processor is more "open" while the details of the wireless implementation are usually not).
In the case of the module youre looking at, the wireless hardware is all inside the ATWINC1500 and is accessed via SPI and some other GPIO by the SAMD21G (the application processor). All the code you write for the module end up running on the SAMD21G with some library/driver support to implement the wireless functions (which under the hood, are implemented by talking to the ATWINC1500). The ATWINC1500 simply runs the code the vendor (Microchip) wrote to actually do all the wireless protocol work and provides an interface for another processor (in this module, the SAMD21G) to control it.
I tested BluetoothAdapter adapter = await BluetoothAdapter.GetDefaultAsync();
and found out that IsPeripheralRoleSupported = false.
I tested on both desktop and laptop, which are both Windows10(1903), but had no luck.
Is there any way I can enable the PC to support peripheral role?
Or is this property unable to be changed?
Mike Petrichenko answered on the comment if anyone looking for the answer to this question!
You can but with very few Bluetooth Adapters. 100% working one is Laird BT851
You can not "enable" it. It depends only on hardware (Bluetooth module). Use compatible Bluetooth module (the one I posted above is compatible) and GATT server (peripheral mode) will work. Windows has very special requirements fro Bluetooth hardware to support peripheral mode and only few devices can be used.
It's a dongle (https://www.digikey.com/product-detail/en/laird-wireless-thermal-systems/BT851/BT851-ND/8251358). You should replace your one with this. Or, if you have build-in dongle, disable build-in. There are also 2 more known and tested models but they are not USB.
I am currently learning about microcontrollers and processors, and I have a couple questions about some distinctions between the two. As I understand, the MCU contains a processor that implements a processor architecture. For example, I am using a SAML22 Microcontroller that has a ARM Cortex M0 for its processor. So it would have the following:
Architecture - ARM
Processor - ARM Cortex M0
MCU - SAML22
Are the registers that I gather from the SAML22 data sheet related to the ARM Cortex M0? If so, how?
No, the microcontroller datasheet describes peripherals which are not part of the ARM core.
The SAML22 has a Cortex-M0+ core, which is described in ARM documents "Technical Reference Manual" (TRM, DDI0484) and the less detailed "Device Generic User Guide" (DGUG, DUI0662).
You are trying to overcomplicate this. an mcu has a processor. A processor has a processor. there have been processors that you can find on both an MCU and an SOC that is linux capable (not just rtos or uclinux). Its like having a few horsepower motor on your lawnmower and also having the same or similar on your golf cart. Or like having a school made of bricks or a house made of the same style/brand of bricks. Dont get hung up on that. Particularly with the rest of your question which has nothing to do with the processor used in the chip at all.
Atmel wants to make an MCU, so the either create, reuse or buy a processor, they have at least one if not more processors that are their IP but they choose to buy someone elses IP. Now they want to wrap some logic around it they can use some of their own ip or buy some. Each major block is a new discussion. Do they make their own uart from scratch, do they take a uart they created years ago and re-use that, or do they buy a uart. Do they make an ADC from scratch, do they take an ADC they made years ago and use that, do they purchase an ADC design from someone and use that. Repeat for every major or minor block in the design. Just like Honda making a car, which parts are they going to make themselves and which parts are they going to buy, and does that have any relevance to a design they made years ago, or a truck sized vehicle vs a compact car, they both have four wheels, an engine and some seats, in some cases may share some components and others completely incompatible components. but its the same story, do we make a seat, use one we already have, buy one. do we make a rear view mirror, use one we already have from a prior design, or buy them from someone else. the rear view mirror decision likely has nothing to do with the seat decision.
Registers its just a term a thing you write/store some information in. A uart has registers to make it work. A processor usually has registers to make it work. An ADC usually has registers to make it work. Consider each of these blocks as separable.
A processor core is a logic blob that is programmable in the sense that it has a set of rules and its primary interface is a memory bus where it is the master, it expects to find when fetched instructions per its design that tell it what to do, up to the chip vendor to wire that up to something that will feed it instructions. It may have some interrupt lines and a few other things but its primary interface is that memory bus. The "registers" inside are part of the design accessed by the processor internals and not generally memory mapped.
A uart is a logic blob that that is programmable, it has some sort of a memory/interface bus where it is typically a slave. It also has some other signals that go off chip, RX, TX, RTS, CTS, DTR...The registers inside the uart are addressable through the interface bus and are used to make the uart operate. It is up to the chip vendor to connect this bus in a way that it fits into the address space of a bus master that directly or indirectly can write/read the registers in the uart to make it operate. It is programmable in the sense that programming the registers per its spec makes it operate.
An ADC is a logic blob that is sometimes found to be programmable, sometimes not. The converter itself isnt usually. But when used in a chip that does more than just ADConversions there will be an additional logic blob wrapped around the ADC to make it programmable and that logic blob will have some sort of an interface bus where it is a slave. It is up to the chip vendor to connect this bus to a bus master that in some way is capable of programming the ADC to do something.
This isnt limited to ARM based microcontrollers. You look inside an intel x86 processor there is third party IP in there not invented nor created by intel, a lot of it may be but not all. Same goes for pretty much everyone else.
Processor based chips are just cars with seats and an engine and wheels that were per that design sourced from somewhere and then interfaced to each other using more IP from someone be it in house or not.
For any of these chips each IP blob has documentation uart documentation, adc documentation, processor core documentation. Sometimes the license agreement prevents the chip vendor from publishing the documentation and you have to get a driver from them in some sort of board support package or SDK in some form, countless examples of this with chip vendors you have heard of from atmel to intel to zilog. Likewise there are license agreements or common practices that guide what parts the chip vendor is going to document and how and what parts not. So generally but not always when you have specifically an ARM or MIPS core as part of a design. The processor documentation as you should generally do always, is from the processor vendor so ARM, MIPS, etc. The uart, the ADC, and some others be they in house or purchased IP are generally in the chip vendors documentation. The chip vendor ideally created the address space within the rules of the various ip, so the chip vendor often documents where in the processors address space each logic blob lives, then you go to the documentation for that logic blob to see what the individual control interfaces do, registers or memory mapped memory. Not always true though esp with uarts, you sometimes find this is a 16550 compatible and you have to go find a 16550 document from someone else and connect the dots on your own. The raspberry pi includes for example other peripherals where they basically say this is just an arm purchased blob go to arm for this, or there is a blob here and we wont show you how it works (but we publish the linux driver for it and if eager you can reverse engineer from that).
With an Atmel now Microchip ARM based product you (generally) go to arm to get info on the processor core, its general purpose registers as well as the very few internal to the core peripherals like the systick timer if present. The uart, the gpio, the address space, spi, i2c, etc are going to be in one or more Atmel documents for that part, they cover the register specs for those peripherals.
As far as how many documents it takes from the chip vendor that is very much chip vendor and over time family or product line specific. Some chip vendors as with some customers like the board design specific stuff in one document usually called a datasheet. Pinouts, electrical stuff, etc. And the other documents cover the uart register specs and such. Some designs are such that they reuse the same core components. if you have a uart then here is the register spec all of our uarts are the same. so there will be a manual for all of the chips peripherals and maybe the processor or maybe the processor core itself is in a separate manual. In some cases with that design solution, the peripherals if present are always at the same address or they are not. The one I am thinking of you find the board design stuff in the datasheet along with the address map, but the rest of the information for programmers is in the family reference manual, so you need at least those two documents.
And there are of course vendors that either make bad documents with holes as sad habit, or some that intentionally do not provide documentation without an NDA, for fear that a competitor will make a clone perhaps, or just a habit for that company that goes way back. Sometimes those closed book companies do very well sometimes that causes them pain. Broadcom and allwinner seem to do okay, allwinner docs tend to get left about by chip vendors and I guess they dont get punished, but other companies you will get called out for that possibly with a financial or other punishment. Its all in the legal agreement.
There are a few perpherals where there is only one or two designs and everyone just buys it, and despite being undocumented looking at linux/unix drivers can see that everyone uses the same IP.
Way more than you asked for but could tell from your question you were off on the wrong path.
Generally the ARM stuff is not in the chip vendor stuff, so no you wouldnt find it there. Sometimes (rare) the chip vendor will re-publish an arm document in whole or in part. Better to get it from arm directly. In the case of a cortex-m the arm peripherals on core are at fixed/well known addresses. For the cortex-a, and older arm11, arm10, arm9...The chip vendor straps a peripheral base address in the address space they have designed for that product and the internal arm peripherals if any are based off of that. so you can find two products likely from different vendors with the same core but the memory mapped peripherals inside are at different addresses for this reason. (in the technical reference manuals for the various arm cores).
I am exploring building apps (Android & iOS) for Car OBD2 Adapters that support BLE (Bluetooth Low Energy). In order for the app to be able to work with such adapters from different vendors, I presume there would be a standard set of GATT profile i.e. Services and Characteristics that these adapters would be using for standard features like engine RPM, Fuel level etc. Is this info available somewhere that I can refer while building the mobile app?
OBD2 BLE adapters don't use any fixed GATT profiles. The way most (if not all) BLE OBD2 adapters work, is that they offer one service with one or two characteristics:
A write characteristic. This one is where the mobile device can write its AT commands (in the case of, e.g., an ELM327) and PIDs to.
A notify characteristic. This is the one where the results from the car (ECUs) are returned.
Once you have access to these characteristics, you can implement the OBD2 serial protocol (e.g. using a command queue that writes and waits for the response, before transmitting the finished command to the application layer).
Some BLE adapters merge these two into one characteristic. If you want to support arbitrary adapters, you will have to add a 'select your adapter' screen where you probe the found adapters, remember the characteristics, and then communicate.
That way it's possible to write apps that work with all kinds of BLE OBD2 adapters, and not only support a selected handful of vendors, e.g., such as OBD2 Expert (Disclaimer: I'm the author of that software).
Hope that helps!
Hope this is the right place to ask - assuming so as it is related to programming.
I am looking for some hardware (say a dongle) that would open up an API for my computer to a SIM card. Does that exist anywhere?
The idea would be that I can then use my existing SIM card on its existing network/contract and with a bit of code, send/receive calls and texts. I figured that if a phone can be programmed to do it why can't a computer? I just need the hardware.
Any suggestions if this kind of thing is possible? Even by maybe integrating a phone?
You can use AT commands with any modem or phone, whose driver exposes a modem port when you connect it to a computer. Plug in the phone or modem, and go to Windows Device Manager, and look under "Modems" and see what you've got. From "properties" of the Modem, you can see which COM port it is on.
AT commands are an older method of communicating with a modem. There is a standard set of commands for GSM/GPRS/3G/4G devices available from 3GPP.org, here. Manufacturers add their own proprietary commands for more obscure functions. Many but not all of these are in the public domain.
Some newer plug-in modems may appear as a network adapter (you can see this in Windows), due to their drivers. In this case, you can use the following interfaces:
on Vista: NDIS, proprietary interfaces
on Windows 7 and 8.x Desktop apps: Windows Mobile Broadband API
on Windows 8.x, in the Metro/app area: Windows.Networking and MobileBroadband APIs.
on Windows 10, UWP, there are UWP APIs here. But they do not give as much functionality as the Desktop APIs.
On Windows 8.1 and Windows 10, if the appropriate drives are present it is possible to use the new MBIM interface via the desktop Mobile Broadband DeviceServices API. Mobile Broadband Interface Model spec available here.
On Linux, use AT commands via the serial port.
I'm a bit puzzled by your requirement to make (voice?) calls via a phone connected to a computer. Do you mean Skype? In this case, of course, you wouldn't need any interface for making calls, you would just open an IP connection over a data session - which can be done via any of the above interfaces.
(added this comment as an answer, as there was more information)
I use this GSM device: http://www.mikroe.com/click/gsm2/ connected to a basic UART like: https://www.sparkfun.com/products/718?gclid=CIj1xOzbur4CFUVbfgodCpQASQ
Then use AT COMMANDS.
I also use a piece of software called QNavigator to inspect the modem/gsm: http://www.soselectronic.com/?str=1329