[TriEmbed] A Few Questions - Hopefully not stupid ones

Mon Nov 30 13:19:26 CST 2015

If you are fascinated by FRAM, try one of the TI's MSP430FR LaunchPads.

On Mon, Nov 30, 2015 at 1:12 PM, Pete Soper via TriEmbed <
triembed at triembed.org> wrote:

> The Arduino gate IS a FET. :-) The concern would be if the gate's output
> voltage is high enough. It won't be the same as the Atmega's supply
> voltage. A bypass cap may be called for if the BLE board is far away and
> connected with a thin wire. A decent meter or storage 'scope could
> determine whether the peak current spec reflects reality and whether the
> supply voltage droops with a given setup.
>
> I know this isn't likely to be relevant to your case, but folks should
> know that there are layers of 'absolute max' specs for Atmega, so, for
> example, you can't expect to drive all eight pins of one register at 40ma,
> power dissipation and max temperature may be issues, etc.
>
> The reset-hold idea sounds good to me.
>
> The four byte epoch date/time encoding is very well understood and
> supported. If you want to get a head start on 2038 you could have a single
> bit in your flash to say "if set then these 32 bit timestamps are relative
> to 1/1/1970 and otherwise time zero is expressed in the null-terminated
> string following this bit".
>
> Here's a potentially dumb answer to your question after I meditated about
> just how efficient your timestamps could get.
>
> If you can trust the storage to read back what you've written you could Huffman
> code <https://en.wikipedia.org/wiki/Huffman_coding> the intervals between
> timestamps and make them just long enough to express the elapsed time from
> one measurement to the next.  If your "regular" interval between
> measurements is fixed and you can hit each reporting time within a second
> or less then you only need one bit to express the new date/time, and other
> intervals would be expressed with longer bit strings you would form as a
> side effect of traversing your "interval dictionary" that for the best case
> efficiency you would create on the fly. Your first timestamp after power up
> would be degenerate unless you got lucky, and you would necessarily have to
> run through the samples to establish the date/time of the last
> pre-power-cycle timestamp before proceeding if you don't want to just spit
> out a full 32 bit timestamp each time you start. A hugely cheaper way to go
> is to subscribe one bit of your logging data to indicate whether the
> timestamp is the full four bytes or some smaller sequence of bytes
> expressing one or more flavors of interval relative to the last full
> timestamp. Finally, if the logging data has unused bits such as the high
> order bit of seven bit ASCII characters you could perhaps express a
> timestamp with zero overhead in the nonvolatile storage.
>
> Remind me why ferromagnetic chips are more interesting than EEPROM or
> flash?
>
> -Pete
>
>
> On 11/29/2015 11:20 AM, Chip McClelland via TriEmbed wrote:
>
> All,
>
> I am building a new board and have to make some design decisions. Before
> sending to OSHPark, I wanted to see if you all could tell me if I am about
> to make any mistakes:
>
> 1) Powering a Bluetooth LE module using an Arduino IO Pin.  I am using the
> Adafruit Bluetooth LE friend.  According to this article
> <https://learn.adafruit.com/introducing-the-adafruit-bluefruit-le-uart-friend/current-measurements>
> it should only draw 15.2mA peak current.  Looking up the ATMEGA 328p specs
> <http://playground.arduino.cc/Main/ArduinoPinCurrentLimitations>  I see
> that that it can source 40mA on an IO pin.  I know that engineers like to
> add a “safety factor” so, do you think I would be OK or should I use a FET
> and have the Arduino simply control it?
>
> 2) I am moving away from storing data on a MicroSD card and want to use a
> FRAM chip instead. BTW, if you have not looked at FRAM it is awesome!  I
> will use the Fujitsu chip
> <http://www.fujitsu.com/us/Images/MB85RC256V-DS501-00017-3v0-E.pdf> and
> communicate using i2c.  Here is the question, what if I wanted to use an
> external reader to extract the data from this chip, I could expose the i2c
> pins on the boar and use a POGO pin reader to connect - that way I would
> not need to refresh the ATMEGA on the board to change to a data dump
> sketch.  So, I would connect this device to provide power, ground, SDA and
> SCL.  The thing is, I don’t want the ATMEGA on the board to get in the way
> of this.  Could I simply add a pin connected to the board’s RESET pin and
> hold it low, disabling the onboard processor and leaving the i2c bus
> available for access?
>
> 3) I want to add a date and time stamp to each event I log on the FRAM
> chip, I am thinking the best format would be UNIX or EPoC time as it will
> use only 4 bytes.  That way each event will use only 4 date/time bytes and
> one data byte and I can store a year’s worth of data on a 256k chip.  Is
> there a better way to store date and time?
>
> Thank you all for your help,
>
> Chip
>
>
>
>
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing listTriEmbed at triembed.orghttp://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> TriEmbed web site: http://TriEmbed.org
>
>
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
> TriEmbed at triembed.org
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> TriEmbed web site: http://TriEmbed.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20151130/9eb63732/attachment.htm>