The development of the kids is always interesting. Anna, two, can repeat almost everything we say (even long complicated sentences with long complicated words). She has memorized the text of books, and can "read" them. She knows the numbers up to four or five, and can point them out (as the cardinality of a group) or count them out.
Charlie, four, is interested in superheros, remote control, and trains. He has started to ask about hard concepts like death, jealousy and social exclusion. He recalls events and dreams, and recounts them understandably.
Showing posts with label development. Show all posts
Showing posts with label development. Show all posts
Friday, August 7, 2015
Friday, January 16, 2015
Playing Restaurant.
Latest development with Charlie and Anna is playing restaurant together. Charlie is chef. Daddy is waiter. Anna is customer. Daddy delivers menu (cardboard box top) to Anna on sofa. Anna places order for "fries and cookies". Charlie says "coming right up" and goes off to corner of living room and prepares food (small stand with door to act as oven). After some minutes he brings back the (invisible) food cupped in his hands. "Here you go". Places it in on an overturned sand bucket in front of Anna. Anna accepts with cupped hands and comments "mmm", makes chewing noises or somesuch. Repeat.
Labels:
chef,
Cookies,
development,
fries,
menu,
oven,
restaurant,
sofa,
waiter
Location:
153 Andover Street, Danvers, MA, USA
Thursday, December 26, 2013
New Devices – Just Give us the Pins and APIs
Recently blogged about the renaissance of the DIY
electronics pathway.
Now one can find modules for almost any function - at near
instant mail order and even at a local retail outlet.
That speaks to a message that needs to get to the developers
of new chips and modules for connectivity and core or ancillary functions. The release of such modules often involves a CPK (programmers kit) to the chip
or module API – fair enough. The supplier company often releases a development
kit - which has a reference design board, their module, a power supply and
various cables, and a DVD or CD with the CPK (or more lately a slip of paper or
QR barcode code with a website link to a CPK download *grin*)
The new paradigms of modules at retail screams out to stop
building/providing hardware development kit boards - with UARTs and LEDs and
converters and drivers power connectors and all such do dads, plus saying
nothing of CAD and revisions for a reference design.
Suppliers - just put your chip or module on a carrier with
pins (at human scale with 0.1” or 2mm spacing). Make your reference designs
utilize other modules. Refer to said modules specifically if you like.
The only things the developers add are
A. wire interconnects between modules (and the developer at
the end gets to choose which modules to use). There is no harm in a reference
/design/, just do not make it the defacto only thing the developer can use as
hardware.
B. code interconnects between module APIs.
The work in development becomes the interconnection for
pre-existing functional blocks with accessible API and pinouts. There are some
nice USB (and other protocol and wireless) bridges developers could really go to town
with given accessible pins. This is to say nothing of a fair bunch of embeddable
microcontrollers. Get humans something to get humanly started. Then the design
wins will come.
Labels:
API,
CAD,
COTS,
CPK,
design,
development,
DIY,
embedded,
interconnects,
kits,
microcontroller,
modules,
reference
Subscribe to:
Posts (Atom)