I have tested my code on Contiki OS Cooja Simulator, I now want to transfer it to esp8266 module but could not find a proper any guide on how to transfer code from ContikiOS?
It's not that simple - "transferring" the code to a microcontroller is the easy part! What you call "transfer" is more widely known as "programming", "flashing" or "uploading" in this area. Instruction how to do it with Contiki and Contiki-NG are in the tutorial here: https://github.com/contiki-ng/contiki-ng/wiki/Tutorial:-Hello,-World!#running-the-example-on-a-real-device
However, for an embedded OS such as Contiki to work correctly on a specific microcontroller, not only must the microcontroller specified in compilation settings (so that the compilers knows what code to generate), the OS itself must be adapted to that specific microcontroller and the specific board. Each microcontroller has its own way of providing functionality that the OS needs, for example, hardware timers and interrupts. OS needs to support the microcontroller, that is, provide an adaptation layer between the OS core code and the API exposed by the hardware. Different boards may use the same microcontroller, but differ in the pins used for I/O, LEDs, peripherals available, and so on. Each of the supported boards must have a small adaptation layer in the OS as well.
Unfortunately ESP microcontrollers have never been officially supported by the Contiki OS, so you will need to get another hardware to try it out!
Related
I am involved in a project where we have some kind of IoT device. An nxp processor with an LTE modem on a PCB. The software running on it connects to the modem over a single uart interface. It will initialize the modem through AT commands, and finally made a data call to the provider (PPP).
Then, it uses lwIP (light weight IP) to open some mqtt subscriptions, and allow user code to make http get/post requests to our servers.
Every 15 minutes we want to retrieve signal strength from the modem and report this back to the server. What I do now, is put the modem back in command mode, retrieve the signal strength info, go back to data mode, and resume normal operation.
The round trip from data mode, to commando mode, and back to data mode takes several seconds (4-5 ish). This is annoying, because during that time we are not receptive for commands.
I've read about gsm mux 07.10. By following some defined protocol it allows to create virtual serial ports, over one physical uart. That sounds nice, although I realize this will go at the cost of performance (bytes will be added to each frame we send to either command mode / data mode).
The gsm mux 07.10 spec dates from 1999. I am far from an expert in mobile solutions. I was wondering: is muxing still the way to go? How does a typical smart phone deals with this for example? Do they include modems with more than one uart to have parallel access to AT commands and a live internet connection? Or do they in fact still rely on gsm mux?
If somebody would be so kind to give some insights. Also on potential C libraries that are available that implement gsm mux 07.10? It seems that TinyGSM implements it (although I can't seem to find where), and I also can find the linux kernel driver that implements gsm mux 07.10. But that driver is written on top the tty interfaces in linux, so that would mean I would have to reverse engineer the kernel driver and strip out the tty stuff and replace it with my own uart implementation.
First of all, the spec numbering is the old GSM specification numbering, so those old specs will never be updated, the new specifications with new numbering scheme will. I do not remember when the switch was made, but I do remember someone at work giving a presentation on 07.10 probably around 1998/1999, so probably a few years after that or around that time (and definitely before 2009).
The newer spec numbering scheme uses three digits for the first part.
So for instance the old AT command spec 07.07 is now 27.007, and the current 07.10 multiplex specification is 27.010.
The following is what I remember of 07.10.
The motivations for developing 07.10 was to exactly support the kind of scenario that you describe. Remember back in the mid 90's, if mobile phones had a serial interface then that was RS-232 though each manufacturer's proprietary connector at the bottom of the phone. One single serial interface.
However, in order to use 07.10 mux in serial communication you needed to install some specific serial drivers in Windows with support for 07.10 (and I think maybe there was some reliability issue with them?), and for that reason 07.10 never took of and became anything more than an rarely used solution.
Also by the end of the 90's additional serial interfaces like Bluetooth and IrDA became available on many phones, and later USB as well, which both added additional physical interfaces as well as natively multiplexing within each protocol.
So the need for multiplexing over physical RS-232 became less of an issue, and whatever little popularity 07.10 ever had dwindled down to virtual nothing.
Fast forward a couple of decades and suddenly someone asks about it on stackoverflow. Good on you :) As far as I can tell I cannot see any fundamental problems with using it for the purpose you present.
Modern smart phones that support AT commands will most likely have a code base for the AT command parsing with roots in the 90's, which most likely include the AT+CMUX command. Of course manufacturers today have zero explicit wish for supporting it, but when it is already present it will just come along with the collection of all other legacy AT commands that they support.
So if the modem supports AT+CMUX you should be good to go. I have no experience or recommendation with regards to client protocol libraries.
I have a project involving communication between a raspberry pi 2 and arduino uno, does it matter of the shields are different ?
Second when communicating do they both need to be coded in the same language?
Does anyone know of any tutorials on this subject?
Thanks
As long as both shields comply with CAN spec, and the software in both ends uses the same configuration (bitrate, CAN message structure, CAN IDs) there should be no problem in using different platforms and different languages to communicate between them.
Note that in many shields the power for the CAN transceiver is provided from the "vehicle" and not from the platform that you use (arduino, RPi) to provide better protection to the platform, and you might need to provide such power source (the arduino might do, (although the RPi can provide 5V from pin 2).
Please pardon me if this question comes as a little too basic but I have tried searching almost everywhere but haven't found a clue.
I am using the esp8266 module and have uploaded the firmware in it. I have also set it as "Access point" so that other modules are able to connect with it. My problem is that I want to control it pro-grammatically through an 8051 micro-controller. I have searched online and there is a lot of documentation on how it program it through arduino, but that doesn't solve it for me. I want to use assembly language to build a serial protocol that communicates the data from 8051 to esp8266 and then to the connected modules (such as Android device).
My question really is, "would it be possible to just connect TX/RX of 8051 to RX/TX of esp8266 and write a code in assembly that transfers data as I desire to esp8266? Or, do I have to do something else?".
At the moment the only documented way for a host controller (the 8051 in your case) to talk to the ESP8266 is to use the serial port (there is a slave SPI port but the mechanism for driving it isn't known yet). So you will have to make up a little protocol to send and receive commands and data (assuming that the standard support for an enhanced AT command set isn't sufficient for you).
The baud rate can go a lot higher than the default 115200bps, if you need it to (although I'm not sure if the 8051 could keep up).
I am currently working on a system (home projects - finally got the time yay!) and i am wondering whether it would be possible to program an arduino from a pic32? the system currently has both and given the pic32 proc has an SD card attached, i figured i could use the platform potentially to program all the other systems if there was new firmware deployed onto the SD card..
just wondered if it was possible? there doesnt seem to be anything online but maybe im googling the wrong thing? i suppose the pic32 would be acting as an ISP?
Thanks in advance..
Chris
sure, why not, it is just spi. I think just out of convenience (of something with spi on it or trivial to bit bang) I use another microcontroller to program my avr (an msp430 or mbed which program easily over usb). avrs docs are pretty good on the protocol. you can use the serial bootloader as well, but that gets into a larger number of combinations of which arduino, what speed the uart is, exactly how and you have to tickle the dtr (reset), seemed like when I was still messing with that each arduino board type was different. Where with the isp interface excluding xmega, there are chip to chip differences as far as the identification number, etc but easier come up with something more generic. And the nice thing about that spi interface is the processor is in reset so you are not relying on there being a bootloader, what version of the bootloader, or a chip with a flash that is for some reason causing a hang, etc. you should generally get the same programming experience independent as to what was programmed before.
I know both are bluetooth smart devices. I need to know whether both can be used for the same applications. If not what do they have in common and what is different about them?
A sensortag can be configured to be an iBeacon, but it is designed to be a more generic Bluetooth LE device that can be put to many other uses as well, providing many other Bluetooth services.
An iBeacon is a very specific type of Bluetooth LE device, and many types of iBeacons can only perform that one function.
Because a sensortag is so generic, it is not optimized to be an iBeacon. Its battery, for example, will not last a super long time when acting as an iBeacon.
A TI "Sensortag" is basically just an eval board for the CC2540 / CC2541 BLE chips.
Most hardware "iBeacon" implementations use either that chip, or the competing NRF51822, on a more specialized custom board.
In either case, the transmission of "iBeacon"-formatted BLE advertising packets is controlled by the custom firmware loaded into the device.
The duty cycle, which is the major determination of power consumption, is also determined by the firmware. The Sensortag does have some other onboard peripherals, but if the design is sane it should be possible to get those into a negligible powered-down state.
Answering #TimTisdall comment (below), the following link is a 3rd party, non-official iBeacon-enabled firmware update for TI's 2541DK SensorTag hardware:
hex firmware files, demonstrating iBeacon on the cc254x
For more info regarding SensorTag, see:
http://www.ti.com/ww/en/wireless_connectivity/sensortag
&
http://www.ti.com/tool/CC2541DK-SENSOR
This question was a bit ahead of the time and here are some updates: The SensorTag now officially supports iBeacon technology. Information on how to configure it to act as an iBeacon is described in the wiki.
As davidgyoung already pointed out: it wasn't build to solely work as an iBeacon, so it may come with reduced battery life. On the other hand, it provides more functionality, which makes it a valuable tool for development at a good price tag.
As noted before the SensorTag has many other sensors on board. Using a "generic" iBeacon firmware on the SensorTag results in a high current consumption. The unused sensors need to be put into sleep mode (I believe it was the Gyro implementation, which eats a lot of power when not configured correctly in sleep mode).