Emulation of IOT hardware

Emulation of IOT hardware

[Niraj Sorathiya]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

Hello Team,

Would you please give me some suggestions on how I should proceed to build
an IOT (Internet of Things) emulator ? What aspects do I need to consider
?  IOT can be anything like a smart light ,smart bulb ,smart lock ,etc.
Here smart means that the device can be controlled via the internet.


-- 


Best Regards,
Niraj

[-- Attachment #2: Type: text/html, Size: 582 bytes --]

Re: Emulation of IOT hardware

[Alex Bennée]

Niraj Sorathiya <nirajsorathiya101@gmail.com> writes:

> Hello Team,
>
> Would you please give me some suggestions on how I should proceed to
> build an IOT (Internet of Things) emulator ?

Maybe look at the Musca boards:

  https://qemu.readthedocs.io/en/latest/system/arm/musca.html

these are based ARM's IoTKit which are modern ARM M-profile boards for IoT development.

> What aspects do I
> need to consider ?  IOT can be anything like a smart light ,smart bulb ,smart lock ,etc. Here smart means that the device can be controlled
> via the internet.

It really depends on what you are interested in modelling?

One area where we currently fall down is how we handle GPIO type setups
in emulation. While we have models for displays and backends for network
and block devices we haven't got coherent way to represent (and change)
arbitrary IO pins. 

-- 
Alex Bennée

Re: Emulation of IOT hardware

[Philippe Mathieu-Daudé]

On 9/28/21 15:04, Alex Bennée wrote:
> 
> Niraj Sorathiya <nirajsorathiya101@gmail.com> writes:
> 
>> Hello Team,
>>
>> Would you please give me some suggestions on how I should proceed to
>> build an IOT (Internet of Things) emulator ?
> 
> Maybe look at the Musca boards:
> 
>   https://qemu.readthedocs.io/en/latest/system/arm/musca.html
> 
> these are based ARM's IoTKit which are modern ARM M-profile boards for IoT development.
> 
>> What aspects do I
>> need to consider ?  IOT can be anything like a smart light ,smart bulb ,smart lock ,etc. Here smart means that the device can be controlled
>> via the internet.
> 
> It really depends on what you are interested in modelling?
> 
> One area where we currently fall down is how we handle GPIO type setups
> in emulation. While we have models for displays and backends for network
> and block devices we haven't got coherent way to represent (and change)
> arbitrary IO pins. 

You can use LEDs as a starting point, see commit 7cfbde5ea1c
("hw/arm/aspeed: Add the 3 front LEDs drived by the PCA9552 #1"):

    The Witherspoon has 3 LEDs connected to a PCA9552. Add them.
    The names and reset values are taken from:

https://github.com/open-power/witherspoon-xml/blob/master/witherspoon.xml

    Example booting obmc-phosphor-image:

      $ qemu-system-arm -M witherspoon-bmc -trace led_change_intensity
      1592693373.997015:led_change_intensity LED desc:'front-fault-4'
color:green intensity 0% -> 100%
      1592693373.997632:led_change_intensity LED desc:'front-power-3'
color:green intensity 0% -> 100%
      1592693373.998239:led_change_intensity LED desc:'front-id-5'
color:green intensity 0% -> 100%
      1592693500.291805:led_change_intensity LED desc:'front-power-3'
color:green intensity 100% -> 0%
      1592693500.312041:led_change_intensity LED desc:'front-power-3'
color:green intensity 0% -> 100%
      1592693500.821254:led_change_intensity LED desc:'front-power-3'
color:green intensity 100% -> 0%
      1592693501.331517:led_change_intensity LED desc:'front-power-3'
color:green intensity 0% -> 100%
      1592693501.841367:led_change_intensity LED desc:'front-power-3'
color:green intensity 100% -> 0%
      1592693502.350839:led_change_intensity LED desc:'front-power-3'
color:green intensity 0% -> 100%
      1592693502.861134:led_change_intensity LED desc:'front-power-3'
color:green intensity 100% -> 0%
      1592693503.371090:led_change_intensity LED desc:'front-power-3'
color:green intensity 0% -> 100%

    We notice the front-power LED starts to blink at a ~2Hz rate.

Regards,

Phil.