[TriEmbed] A Few Questions - Hopefully not stupid ones
Chip McClelland
chip at mcclellands.org
Mon Nov 30 13:45:41 CST 2015
Pete,
Thank you, I will look at that delta-encoding idea. I do have one limitation other limitation - The Arduino implementation of the ATMEGA 328 gives me only two hardware interrupts. I will need to see if there is an easy way to make use of another interrupt which the real time clock could use to trigger an hourly alarm / data-dump. This would allow me to only write the start time/date and then count hourly periods. I know we talked about this but I need to go back and see what it takes to map a 3rd interrupt.
FRAM is awesome for three main reasons:
- Very low power usage - especially when compared the the MicroSD card it is replacing
- About seven orders of magnitude more read/writes than EEPROM before burnout
- Speed - can run i2c at 1MHz rates (though I won’t write that fast here)
couple bonus features:
- 95 year data retention at room temp
- big operating range 2.7-5.5V
- no moving parts - like the MicroSD cards that keep breaking
Great point on the voltage drop to the BLE module. Need to test and keep that trace short and fat.
Thanks,
Chip
> On Nov 30, 2015, at 2:09 PM, triembed-request at triembed.org wrote:
>
> Send TriEmbed mailing list submissions to
> triembed at triembed.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> or, via email, send a message with subject or body 'help' to
> triembed-request at triembed.org
>
> You can reach the person managing the list at
> triembed-owner at triembed.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TriEmbed digest..."
>
>
> Today's Topics:
>
> 1. Re: A Few Questions - Hopefully not stupid ones (Pete Soper)
> 2. Chain-able EEPROM or Similar (Adam Haile)
> 3. Re: Chain-able EEPROM or Similar (Adam Haile)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 30 Nov 2015 13:12:58 -0500
> From: Pete Soper <pete at soper.us>
> To: triembed at triembed.org
> Subject: Re: [TriEmbed] A Few Questions - Hopefully not stupid ones
> Message-ID: <565C91AA.9070108 at soper.us>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> 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 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/ddcb4fdf/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 30 Nov 2015 13:35:42 -0500
> From: Adam Haile <email at adamhaile.net>
> To: "triembed at triembed.org" <triembed at triembed.org>
> Subject: [TriEmbed] Chain-able EEPROM or Similar
> Message-ID:
> <CAG8g-TYE-oJ8Sy+SKnsTLz6JDcL_MzUJXSHh4Rz58-WC3Cyd9A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I have *no* idea if this technically is something that exists, but I have
> to imagine it's possible.
>
> I need a small, cheap (isn't it always?) chip that can store a few bytes of
> data. Actually a single byte is all I need. And can be accessed kind of
> like a shift register where I can query an unknown number of devices int
> the chain and get, in order, the byte that each one stores.
>
> The intent here is so that I can have multiple, pre-wired, sets of LEDs
> with an arbitrary order and number of LEDs on each. This chip would store
> the LED count for each pre-wired section. Without knowing anything about
> the pre-wired sections, I need to be able to poll all these chips and from
> that know how many pre-wired sections there are, how many LEDs each has,
> and in what order. The data returned just needs to basically look like: 48,
> 36, 24, 18 (4 sections with 48, 36, 24, 18 LEDs, in that order).
>
> I assume it would use an SPI-like interface... not exactly since I can't
> use chip selects. Since I would have an arbitrary number. A 2 wire
> interface would be great. Is it possible to do something like this with
> I2C? Basically, I know what I need, but don't know what to call it.
>
> Any thoughts?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20151130/cb144dc3/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 30 Nov 2015 14:08:38 -0500
> From: Adam Haile <email at adamhaile.net>
> To: Brian <triembed at undecidedgames.net>, "triembed at triembed.org"
> <triembed at triembed.org>
> Subject: Re: [TriEmbed] Chain-able EEPROM or Similar
> Message-ID:
> <CAG8g-TZd+5eUVM6AeNdBiiN8fZy0BsoKat+sMkfx=jUpEbDt8g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Oh... yeah. Important part. The data in the chip needs to be non-volatile!
> So, the data would be stored on each chip individually and then read
> serially.
>
> On Mon, Nov 30, 2015 at 2:07 PM, Brian <triembed at undecidedgames.net> wrote:
>
>> If you can spare three pins, shift registers are (maybe) exactly what you
>> need.
>>
>> You didn't mention how the bytes get there to begin with, which does
>> affect the answer.
>>
>> Most (?) serial-out shift registers support chaining out-of-the-box; they
>> have a latch signal to preload their internal flip-flops as well as an
>> external serial input. By their very nature, the first (n) bits clocked
>> out will be their own bits, followed by whatever bits clock in on the
>> serial input. Natural chaining.
>>
>> If you have parallel inputs that can all be latched at once, a single
>> latch + clock-out + data-in is all you need on the host MCU.
>>
>> If the data comes into the registers serially, well, that's a bit more
>> complicated.
>>
>> -B
>>
>>
>> On 11/30/2015 1:35 PM, Adam Haile via TriEmbed wrote:
>>
>>> I have /no/ idea if this technically is something that exists, but I
>>> have to imagine it's possible.
>>>
>>> I need a small, cheap (isn't it always?) chip that can store a few bytes
>>> of data. Actually a single byte is all I need. And can be accessed kind
>>> of like a shift register where I can query an unknown number of devices
>>> int the chain and get, in order, the byte that each one stores.
>>>
>>> The intent here is so that I can have multiple, pre-wired, sets of LEDs
>>> with an arbitrary order and number of LEDs on each. This chip would
>>> store the LED count for each pre-wired section. Without knowing anything
>>> about the pre-wired sections, I need to be able to poll all these chips
>>> and from that know how many pre-wired sections there are, how many LEDs
>>> each has, and in what order. The data returned just needs to basically
>>> look like: 48, 36, 24, 18 (4 sections with 48, 36, 24, 18 LEDs, in that
>>> order).
>>>
>>> I assume it would use an SPI-like interface... not exactly since I can't
>>> use chip selects. Since I would have an arbitrary number. A 2 wire
>>> interface would be great. Is it possible to do something like this with
>>> I2C? Basically, I know what I need, but don't know what to call it.
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/c08911bd/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> TriEmbed mailing list
> TriEmbed at triembed.org
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>
>
> ------------------------------
>
> End of TriEmbed Digest, Vol 30, Issue 22
> ****************************************
More information about the TriEmbed
mailing list