SparkFun Forums

[adam.g]

Morning Robin,

Yes, the goal was to make the Artemis 0-3.3V compatible, but I believe the placement of the op-amp resulted in a limited range of 0-2.9 V and an increased current draw since it's always being powered. Nate did a good job of describing the issue here: https://github.com/sparkfun/MicroMod_Ar ... -742868563. My hope is that the processor board will see a hardware revision, but I suspect there's a large stock to go through first and it'll be some time.

Thanks also for the additional info on the Segger IDE. After I started researching it, I suspect that was the case. Once I have some free time I think it'll be a nice rabbit hole to dive down.

It's a coincidence that you mentioned the Adafruit GFX library and LCDs. I've been trying to troubleshoot why my SparkFun OLEDs (https://www.sparkfun.com/products/17153) are spitting out garbage pixels after a time with the Artemis (v1.x & v2.x). While these OLEDs communicate over I2C, is there any general reason why reason the OLEDs wouldn't like the Artemis?

Cheers,
Adam

Cheers,
Adam

[robin_hodgson]

The Artemis I2C interface should work just fine. I have used it a lot with zero problems. I use SPI for displays because it is so much faster. It doesn't matter so much with a monochrome 128x32 display, but for a 320x240 color LCD, there are 153K bytes to move when redrawing the entire screen. I2C won't cut it, but SPI at 16 MHz will do the trick.

If you ever want to get started with Segger, check this thread: viewtopic.php?p=222142#p222142. There is a version 1.8 document attached that explains how to get Segger version 4 to work with Artemis. Note that Segger version 5 is NOT compatible with the instructions in the doc. However, it is not hard to migrate from V4 to V5. So if you want to use the document, download the latest V4 version of Segger Embedded Studio from Segger, and have at it. Once it all works, you can upgrade to V5 at your leisure. Segger documents the migration operation themselves.

[kevin_s]

Tried running Robin's code as well as the sample ones on an Artemis Dev Kit. I've desoldered all of the leds as well as the microphone, but the lowest I can get it to sleep at is 12.1mA. I am using an Otii Arc to provide power and measure the draw by feeding 3.7v into the 3.3v and GND pins on the board as there is no MEAS on the Dev Kit.

Is there anything I might have missed?

TIA. Kevin

[robin_hodgson]

Is there a typo: was your measurement 12.1 mA or uA?

[robin_hodgson]

I don't see how you are isolating the power measurement to just the Artemis. From your description, it sounds like the USB interface chip must also be powered, which is probably why the current draw is so high. If you want to measure just the Artemis, I could cut the 3.3V trace in the backside location shown by the green 'X' in the attached picture, then feed in 3.3V power through wires plugged into the QWIIC connector. The power going into the QWIIC connector will only be powering the Artemis, plus the 1.8V linear regulator. You could remove the 1.8V regulator if needed because I think that the camera needs it, but nothing else.

[kevin_s]

Sorry maybe I missed the point of the measuring. I'm trying to get the dev kit in total measured, not just the Artemis. The end goal is to use it with the Himax hm01b0 camera, but I was trying to get a benchmark on the board first. The 12.1mA was not a typo. The board power draw started at +25mA in sleep mode before I removed the microphone and leds. I do not have the USB cable plugged in while measuring. Just running the power and ground from the meter to the board as pictured.

So maybe I'm off in thinking the Dev Kit board in total can get any lower in draw?

[robin_hodgson]

OK, now I understand.

I think you are right, and that might be as low as it will go. In sleep mode, the Artemis will be responsible for basically no power consumption at all. That means that most of the power you are measuring must be going into the the USB interface chip and potentially the camera (it looks like you have a camera present in the photo). I have the 3.3V traces highlighted in the photo I attached, and you can see that the USB chip gets 3.3V from where you are supplying it, even with no USB cable plugged in.

[E.HP.S]

I'm trying to get a similar system going where the Artemis can be put to sleep by either waiting long enough, or pressing a button. That same button should also be able to wake it up. Problem is that as soon as the code reaches the attachInterrupt line in setup, it immediately jumps into the interrupt and then proceeds to hardfault (blinking S.O.S. message). I double checked with an multimeter and oscilloscope and didn't see any signs of oscillations that could trigger a falling edge signal. Additionally, I put in some debug lines to show the button status when the interrupt triggers and held the button down before resetting the Artemis. Sure enough, the signal reads as high when left alone and low when the button is held down, but it still enters the interrupt regardless. Any idea what might be going on?

[E.HP.S]

Problem is that as soon as the code reaches the attachInterrupt line in setup, it immediately jumps into the interrupt and then proceeds to hardfault (blinking S.O.S. message).

The hardfault seems to have just been a mistake I made with the debug code, trying to print something to the serial monitor when the UART wasn't set up (sleep mode). Either way, it seems like the interrupt is being triggered constantly without any input from the button. It's pulled up both internally and externally, and has a filtering capacitor for debounce, but I don't even have the chance for debounce to even factor in it seems

[paulvha]

Have a look at https://github.com/paulvha/apollo3/tree ... PowerCntrl. Make sure to read the deepsleep.odt (a document you can open with a large number of word processors (Word, Openoffice etc).
Also look at the RTC example6

[E.HP.S]

RTC example 6 works great for the RTC timer, but I *also* want it to be button operated, which is especially where I'm having trouble. It also doesn't explain why the interrupt would trigger as soon as it's attached to the pin, regardless of button status.

[paulvha]

How did you connect the button ? (small schematic, is there a pull-up / pull-down)
Can you share the sketch you use so I can have a look?

[E.HP.S]

I'll try to get a picture. In the meantime, it's connected to pin 4 on the Artemis Nano (D18 in the .BRD file), and has a 10k pullup resistor, as well as a 1k resistor between the pullup and the button pin, and a 0.1uF capacitor between the pull-up and ground.

[E.HP.S]

How did you connect the button ? (small schematic, is there a pull-up / pull-down)
Can you share the sketch you use so I can have a look?

I actually forgot I posted most of what you were asking for on a separate topic! You can find it below.

viewtopic.php?f=169&t=60400

Let me know if I'm missing anything else you might need

[paulvha]

I see you define SLEEP_INTERRUPT as 4, but you disable that GPIO (but exclude 18?)
Do you have a pull-up resistor on line between the switch and Nano ? Else the line is floating.