Please implement a function to configure a given GPIO pin independently of all others.
Consider the following, common use case:

1. Device driver #1 initialized. It uses and needs to configure some GPIO pins.
2. Device driver #2 initialized. It also uses some GPIOs and needs to configure them, without disturbing the configuration from step #1.
   Currently all the GPIOs need to be configured in advance using qm_gpio_set_config() before calling the initialization driver code. First of all this requires that the code that initializes GPIOs contains device-specific information (e.g. GPIO direction, interrupt polarity, etc.). This is bad for code modularity. Additionally in some cases the GPIO direction needs to be changed on the fly, and currently QMSI does not provide an easy option to do so.

As far as I can tell, mcu_sleep() does not seem to accept values greater than 12000 (2 minutes). When a value higher than 12000 is used, the mcu_sleep() command seems to max out at 2 minutes. For a workaround multiple mcu_sleep(12000); statements can be used in a single program.

It seems like this should not be the case, so I thought I'd raise the flag.

I've been using QMSI to program the Arduino101, but recent QMSI-1.1 ROM apparently broke the serial output. I have not investigated further, but the attached patch makes it work again for me.

As far as I know, QMSI is the only way right now to create a bootrom for Arduino101: https://jira.zephyrproject.org/browse/ZEP-433

rom_serial.patch.txt

soc/quark_se/include/qm_sensor_regs.h:

/* Bitwise OR operation macro for registers in the auxiliary memory space. */

define QM_SS_REG_AUX_OR(reg, mask) \

(__builtin_arc_sr(__builtin_arc_lr(reg) | (mask), reg))

/* Bitwise NAND operation macro for registers in the auxiliary memory space. */

define QM_SS_REG_AUX_NAND(reg, mask) \

(__builtin_arc_sr(__builtin_arc_lr(reg) & (~mask), reg))

While OR and NAND are more common in hardware design space, in software space, these macros are more commonly known as set_bit and clear_bit. and especially when from a bool arithmetic point of view, A & ~B is completely different from ~(A&B).

Maybe not an issue but I've noticed that if I have RTC callback that should fire on pending alarm set by qm_rtc_set_alarm() it works fine with power_soc_halt() but not with sleep() or deep_sleep(). CPU wakes fine but callback function never starts.

For example consider attached program rtc_blink.zip. In provided form it works ok, you have both messages sent over UART and LED blinks every second but if you replace power_soc_halt() with one of sleep functions there's no callback.

Running the UART example on C1000 causes it to reset when it reaches the DMA transfer method.

Platform: Quark D2000 developer board, QMSI 1.3.1, ISSM on Windows

Issue 1: I cannot achieve TXTX xfer when using qm_i2c_master_write() with stop parameter set to false. Instead of repeated start Quark just continues sending contents of the next buffer like it was single transfer.
Similar behaviour is observed with multiple transfers via qm_i2c_master_irq_transfer().

Is there any way to produce sequence of: TX-repeated start-TX-stop on Quark? I have bunch of SMBus devices requiring such behavior to specify write register address.

Issue 2: I need transactional asynchronous I2C communication. So I've written simple FIFO queue which can be loaded with I2C operations and it's unloaded inside of I2C callback of qm_i2c_master_irq_transfer().

Everything works fine unless I try to change xfer type. So for example 10 TX or RX operations can be performed one after another but if at some place there is TXRX operation in single qm_i2c_transfer_t struct subsequent operations are not sent over the bus. What puzzles me is that I get all callbacks with proper data lengths and status codes indicating operation success.

Oscilloscope trace shows that communication ceases after last bit of RX data is sent by the slave. What's even more puzzling if I try to do TX and RX as a separate operations (so FIFO has for ex. TX, stop, TX, stop, RX, stop, TX, stop) transfer completes but there's about 2 second stall between RX and the next operation. During those 2 seconds Quark holds the bus and then continues like nothing has happened.

I've verified whole FIFO code both by running it on ARM Cortex M MCU and by unloading the queue inside RTC interrupt callback and checking data validity on Quark. So at least I know that qm_i2c_master_irq_transfer() gets valid data. I don't know is it legal to call next qm_i2c_master_irq_transfer() from operation success callback of previous one. Maybe there's other way to implement multiple asynchronous I2C transactions? Please advise.