Are XMLSockets available in Flash Lite, and if yes in which versions, and are there differences between the regular and the lite objects?
I don't know enough to tell you the exact difference(s) between XML sockets in Flash and Flash Lite, but they are definitely supported in Flash Lite versions 2.1 and later. See the Flash Mobile Blog for an example.
We're using them to send and receive text strings in both Flash 9 (PC) and Flashlite3.1 (ARM) with no code changes. Unless there are differences in the XML parsing, you're probably good to go.
Related
I'm trying to create project which contains a drivers library and two separate application (Booltloader + app), now I want to share the drives library between the two apps in order to save space on the flash...
I saw this tutorial for IAR, but I must use Keil uvision5 and I didnt find anything helpful online.
Anyone can guide me through this?
thanks!
Splitting the code into three parts (bootloader, library, application) most likely is too much. I think it is better to combine the bootloader and the drivers in a single binary. While calling the application, the bootloader can provide information necessary to use the drivers.
A word of caution, though: a solution like this is way more tricky than just compiling the drivers in the application. Depending on the driver functions, there may be no true benefit on flash usage. In particular, if many drivers are not necessary, they will just occupy the flash instead of getting optimized-out.
Bear with me on this, I'm new to the NFC technology and also fairly new to coding.
So I have a small pet project of mine for my studies that I would like to use NFC technology to achieve. I have a device that measures gas pressure in a pipe. It does daily logs of how much gas was used and other relevant information, so I guess you can say it is a gas meter of sorts. The idea is that I want an NFC chip incorporated into the existing device, so that I can tap my phone to it and receive lets say the latest daily log.
My question is then: how do I program the chip that I incorporate into the existing gas meter? I have read tons and tons of articles and still find that I'm unsure of how to program the chip if I cannot use an app for it. I did download some apps that can code NFC tags, and I also bought some tags and managed to code one to turn on my PC for me and another to set my phone to silent when tapped. So I can use the apps just fine, but I think what I want to achieve with the meter is beyond what the apps can do for me.
So, the course for which I'm working on this project does 90% of coding in C, so I would like to also do the actual coding in C if that is possible. If not, what language do you code NFC in?
Also, how do I get the code onto the chip? Do I need some sort of writer/reader type thing?
Any input is appreciated, and I apologise if this has been asked before. I searched the website, but I didn't find anything that really answered my questions.
For a simple data-logger application like this a full blown NFC transceiver chip is likely overkill.
You're probably fine if you use one of the dual interface eeprom chips like the M24LR64-R. To the microcontroller they look just like a ordinary I²C eeprom. Reading and writing them is done using a very simple protocol.
From the NFC side they show up as a ISO15683 tag, and you can read the eeprom content back using the NfcV.transceive method. Again a simple protocol is used. All that is documented in the data-sheet.
There are other chips with the same capability from other manufacturers. I just recommended the M24LR64-R because I have first-hand experience with them and they work flawless.
I am looking for a AMQP library, preferably written in C, that will work on a small embedded device. i.e. no OS and limited RAM and code size space (256k between both RAM and code).
I have seen the following post and number of others, I have looked into Qpid and RabbitMQ, but none seem suited to a small device.
Is there a AMQP implementation that has stable C++ Client library
Can anyone suggest a AMQP library that will work on a microcontroller? All functionality is not essential, even just support for telemetry would be good.
This seems to be an old question, but maybe this still helps.
Disclaimer: I am one of the authors of uamqp-c.
There are 2 choices I know of:
-Qpic Proton C: https://github.com/apache/qpid-proton
-uamqp-c: https://github.com/Azure/azure-uamqp-c
Cheers,
/Dan
The question below was related to the 8051 family as it has only the serial ports. Now when i found out that the ARM processors have inbuilt ethernet facility i decided to mov on to the ARM's. So which would be the Most easiest one to start of and as iam aware of keil environment i would like to work on anARM which supports keil .
Thnxx,
Cheers.
The TI (formerly Luminary Micro) parts are easy to use. The eval kits are cheap and there is a lot of documentation on the Luminary Micro web site, including sample code. I've been using the LM3S6965 EVK for an ethernet project. The eval kits can be ordered with Keil, IAR, Codesourcery or Code Red compilers.
Check out the AT91SAM7X.
AT91 SAM series from Atmel is really popular between hobbyists and amateurs, you will find a lot of open source examples and excessive topics regarding this CPU's. And yes, they are widely supported in Linux community.
Check this out: http://www.at91.com
I'm working on an audio application, written in C. I need to provide live audio playback under Windows. I need to decide which audio API to use. I'm planning to use the basic waveOut API, but I wanted to check to see what the community here recommends.
I want code that will Just Work on any recent version of Windows, with no need to install libraries; and I want minimal latency.
I don't need or want any "effects", I just need to faithfully play whatever wave samples the application generates.
My understanding is that most of the professional audio applications on Windows use ASIO, which gives excellent low latency, but I don't want ASIO because I want my code to Just Work and most people don't have ASIO pre-installed on their computers. (At a later date I may go back and also add ASIO as an option, but I'm going for the most general solution first.)
Is there anything out there that would be better than waveOut for my purposes, or is that the best choice?
It depends on what you are trying to do. The basic waveOut audio API is better for streaming audio. It lets you queue up several buffers and have them automatically played in succession. But if audio is playing and you want to change it, or add something to it, that's relatively hard.
DirectX audio is better for event based audio. You can have several things playing at the same time without having to do the mixing yourself. You can add or remove little pieces of audio easily - like playing a sound when the user pulls the trigger on their gun. But streaming (i.e. playing 1 buffer after another) is harder.
waveOut is designed to facilitate playing audio that is constant, like a .mp3 file. DirectX is designed for audio that is intermittent, like feedback in a game.
ASIO is like the worst of waveOut and DirectX in terms of difficulty of programming, and it's not that stable. Applications typically can't share the audio device. However, it gives you the lowest latency access to that audio hardware. ASIO also gives you a way to synchronize playback on multiple devices.
If you don't need to be able to change what is going to be played right before it is played, and you don't need to synchronize multiple devices, then you don't need ASIO.
in addition to the options mentioned by John Knoeller, there is WASAPI which allows for much lower latencies than WaveOut, but unfortunately is only available from Windows Vista onwards.
At the time I asked this question, I wrote streaming code using the waveOut and waveIn APIs. Since then, I have discovered a useful library:
PortAudio
http://www.portaudio.com/
PortAudio is free software with a commercial-friendly license. If you write your code to call PortAudio it should be able to work with waveOut devices but also with ASIO devices under Windows; it can be then recompiled for Linux and should work with ALSA devices; and it can then be recompiled for the Mac and should work with CoreAudio devices. I haven't tested the Mac part but my project is working great with Windows and Linux.
Having written a DirectSound streaming application myself, I certainly recommend it for low-latency and ease of use. Also, it enables you to set a higher quality format for playback on legacy editions of Windows.