Is it possible to place the ATmega328/P microcontroller into kernel mode versus user mode?
No. The 8-bit AVR core does not have any privileged modes or instructions. Nor does it have a MPU so there is no kernel vs user mode distinction.
Related
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!
I have a hardware device that controls LEDs on a panel, and it has a serial port for a PC to control the LEDs.
I would like to be able to control the LEDs from a userspace application using the Linux LED class API, i.e. via /sys/class/leds/whatever/brightness. So I'd like to make a Linux kernel driver for this device.
However, from what I've read, it seems unusual for a Linux kernel driver to open a serial device. E.g. StackOverflow question Accessing a serial port from a linux kernel module. I've read about filp_open() which can be used by kernel drivers to open device files, but its use seems to be discouraged.
On the other hand, it seems impossible to implement this in userspace because I'm not aware of a way to create a Linux LED class device from userspace.
What would be a good way to provide a Linux LED class API interface to a serial port controlled LED device?
Disregard the cautions against accessing a serial port from a Linux driver using filp_open()?
Is there some userspace way to create a Linux LED class device, so I could implement this in userspace?
Give up on the idea of using the Linux LEDs class API, and use an alternative API for the userspace application to control the LEDs?
Other?
Custom tty line discipline driver
As far as I can tell, one way to do this in Linux would be to write a custom tty line discipline kernel driver that implements the Linux LED API and sends the commands to the serial port. Then the Linux LED code can be in a kernel driver, but it's not tied to a specific serial port.
Then, to link it to a particular serial port, a userspace program would open the serial port, and use an ioctl(serial_fd, TIOCSETD, ...) call to attach the serial port to the custom line discipline driver. The line discipline driver does all the work from that point. The userspace program's only purpose is really to associate the custom line discipline driver with the right serial device.
Pseudo-driver using FUSE filesystem
One alternative would be to write a userspace program that is a "pseudo-driver", that connects to the serial device, and provides an LED API resembling the Linux kernel LED class API, but at a different location, using a FUSE filesystem.
For example, the program might be named foo-serial-leds and it could provide a number of LEDs under /var/run/foo-serial-leds/ with an API resembling the Linux kernel LED class drivers.
Then another program could control the LEDs by writing to e.g. /var/run/foo-serial-leds/status/brightness. That would be very similar to the program controlling a real Linux kernel LED class at /sys/class/leds/status/brightness, except the location on the filesystem is different. That program would be portable to another platform, with different LED devices, as long as the program has a configurable filesystem path for the LEDs it wants to control.
Two disadvantages of this:
The program that wants to control the LED must be flexible enough to access the LED file API in a different location than the normal /sys/class/leds/
These pseudo-driver LEDs can't use Linux kernel LED triggers
Custom driver to allow userspace creation of LED devices
Another option would be to write a Linux kernel driver that allows for userspace programs to create LED devices in the Linux kernel LED class. The driver could use configfs to allow userspace programs to create the LED devices, which would then appear under /sys/class/leds/. It would need to provide a way to notify the userspace program when the LED brightness is changed (maybe via sysfs_notify() on a custom sysfs attribute, which the userspace program can poll()).
With that driver in place, a userspace program could implement the LED API and write to the serial device to achieve the LED control. This program is kind of a userspace driver. I.e. it would use the Linux driver to create one or more LED-class LEDs, and open the serial port to talk to the LED hardware. When it is notified that something has written to the LED brightness, it would need to send the relevant command to the serial device.
Then other userspace programs that want to control LEDs would be able to write to the LED-class API in the usual location under /sys/class/leds/.
Linux kernel 4.10 userspace LED class driver
Update November 2017: Linux kernel 4.10 adds a userspace LED class driver, uleds. It implements something like what is described above. However, control is via a device /dev/uleds, not via configfs.
An app should open the char device file /dev/uleds once for each user LED it wants to create. It should write a struct to the file, which specifies the name of the LED. Then it should do reads from the open file handle, and will receive an int which specifies the brightness of the LED whenever that LED's brightness is changed by something else in the system. If multiple LEDs are to be created, the app should open the char device file multiple times, once for each LED.
When the app closes, and the open file handle(s) to /dev/uleds is closed, then the user LED is automatically removed.
3 Ways:
1 - You must to understand the data send to CPU Board for modify as you want data for display your message on led board.
2 - You must to have a linux API, but most of time the CPU is made in china, the chinese don't like linux.
3 - You write your own API for control LED Board with arduino or raspberry to control each pins of your LED Board.
Good luck !
I was thinking since clock timing is provided by master microcontroller to rtc/sensor etc.We can use any crystal (including internal) on microcontroller and there will be no timing problem.
is this true?
If you don't need precise timings, you can use internal RC oscillator.
Note, there is no 'internal crystal', it is only R-C circuit like this.
I don't know any MCUs with integrated quartz crystal, there is only some RTC ICs (like Maxim DS3231) feature.
If you use SPI or I2C (TWI), bus timings may have any values, and you may use simple internal RC-circuit.
If your device use UART or will measure any timeouts, you should examine oscillator parameters of your MCU. Which oscillator should be used, depends on required accuracy, parameters, provided by MCU, and some other options (like device working temperatures).
I am developing a system for which I need to program MCUs like PSoC or Atmel SAM4E or Freescale K70 Series. Currently, I am using vendor specific IDEs and Peripherals like 'Miniprog from cypress' to program them, but I want to have a generic programming tool which uses JTAG Interface and don't need any extra peripheral like MiniProg, But I am new to this and really have little idea about how to go ahead with this. So any suggestion is welcome about how to get started with setting up a JTAG programming interface.
In the above example, the SAM4E Xplained Pro Evaluation Kit does not have a JTAG port so it cannot be used with the SAM-ICE JTAG emulator.
With JTAG you can have full control of MCU, e.g. to flash and debug it, run program, stop it when you wish or set watchpoint, breakpoints, triggers for memory values and so on. Most modern MCUs have JTAG interface. That means the JTAG module is inbuilt in the crystal's system. It also means that a MCU has a physical JTAG lines, electric contacts, pins of its package. On evaluation boards, also known as starter kits, these JTAG pins combined into a separate connector. In this connector should be plugged in a JTAG adapter with, usually, USB bus on the other end, turned into your computer.
It is widely used to put a JTAG connector to the board design in order to have a debug capability for the product in all life stages.
For example, Atmel offers an evaluation board SAM4E Xplained Pro Evaluation Kit for Atmel SAM4E:
and the JTAG emulator for it:
For other MCUs you should always check for the compatibility between JTAG emulator and cores supported.
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).