<Joerg-Neo900>
so for a maybe 1000 programmed GP5 we now need to find a way to handle that ourselves
<Joerg-Neo900>
umm, isn't that what I linked above?
<wpwrak>
r108 vs. r109 :)
<Joerg-Neo900>
ooh
<ceene>
could it be replaced with a small pic?
<ceene>
microchip is nice enough to preprogramm their microcontrollers before sending them out to you
<ceene>
and i think the cost was less than 1 euro per unit?
<ceene>
and i believe you could ask for as few as 10 units
<Joerg-Neo900>
I don't like small pics for this
<ceene>
just asked it the rates for PIC18F4550 in PDIP (assuming I just wanted to get Microchip's HID bootloader onto them): $29 setup fee + $0.23 per device, minimum order $60 USD.
<ceene>
from some forum
<wpwrak>
it's a pity i2c doesn't have some discovery / enumeration protocol, and that silego didn't see fit to invent their own
<ceene>
i2cdetect does something like that
<ceene>
don't know how, though
<wpwrak>
that, plus in-ciruit programming capability would make the little critters perfect
<ceene>
i always like pics
<wpwrak>
ceene: what i mean is to assign the i2c address dynamically, too
<ceene>
they're tiny, resilient and basically immortal
<ceene>
i made one of them spit out lots of smoke but kept working afterwards
<Joerg-Neo900>
wpwrak: I thought about we inventing our own, so we are generic with programming and could reach the 3k with the 3 GP we have
<Joerg-Neo900>
but honestly, we probably will have to program them naually and retape
<Joerg-Neo900>
manually
<Joerg-Neo900>
0.5min / chip?
<Joerg-Neo900>
~3000*0.5/60
<Joerg-Neo900>
~3000/30
<Joerg-Neo900>
WUT?
<Joerg-Neo900>
~ping
<Joerg-Neo900>
grrr
<ceene>
~pong
<wpwrak>
just 4 days :)
<Joerg-Neo900>
24h days yeah
<Joerg-Neo900>
dafaq!
<wpwrak>
Joerg-Neo900: you don't eat or sleep anyway ;-)
<wpwrak>
block diagram has "good" silego link again
<Joerg-Neo900>
ta!
<ceene>
what about a small cpld?
<ceene>
don't know if xilinx/altera provide preprogrammed chips
infobot has joined #neo900
<Joerg-Neo900>
the nice feature is: those GP are in-circuit-programmable
<wpwrak>
ceene: the silegos are basically small cplds
<Joerg-Neo900>
~3000*0.5/60/8
<infobot>
3.125
<ceene>
and
<ceene>
could they be programmed by the cpu itself?
<wpwrak>
just not in-circuit flashable. but yes, we should be able to get away with just flashing the I2C address and doing everything else in sw
<Joerg-Neo900>
yes, when you can reach them via I2C
<ceene>
so first you have to make them addressable
<Joerg-Neo900>
exactly
<ceene>
don't they have a default value that can be used?
<Joerg-Neo900>
yes, but obviously only for one on one I2C bus
<ceene>
there's gonna be more than one
<ceene>
isn't its address changeable by hardware?
<ceene>
by setting one gpio to 0/1 to change its address?
<Joerg-Neo900>
I really don't get it why Silego doesn't ofer them with different preprogrammed I2C addr
<Joerg-Neo900>
no
<ceene>
:(
<Joerg-Neo900>
only when you would configure them accordingly :-)
<Joerg-Neo900>
they are 20-pin package and except for VDD and GND every pin is configurable
<Joerg-Neo900>
2*3mm
<Joerg-Neo900>
no external components
<ceene>
xilinx's smallest cpld is a qfg32
<ceene>
with 21 i/o user available pins
<wpwrak>
Joerg-Neo900: maybe write to them, suggest such preprogrammed addresses ? there are only 16 choices, so it wouldn't be all that messy
<Joerg-Neo900>
yes
<Joerg-Neo900>
and such a product would be generic enough to sell to many customers
<wpwrak>
indeed
<Joerg-Neo900>
assuming the NVS can get reprogrammed several times, as long as you don't need to clear any bit in it
<wpwrak>
then they'd just have to add in-circuit OTP programming, and then the chip would be perfect :)
<Joerg-Neo900>
that won't fly, Vpp = 7+V iirc
<wpwrak>
add a charge pump or tweak something with an external supply
<Joerg-Neo900>
I'll ping A.Zonenberg what he thinks about it
<Joerg-Neo900>
hey, that could _actually_ work
<ceene>
what is gonna be these silego function on neo?
<Joerg-Neo900>
have a series R on I2C so you can short I2C bus on inactive GP chips, program the RAM as usual in the chip you're dealing with, then apply a Vpp to pin20(?) which is protected from normal device Vdd by a schottky diode
<Joerg-Neo900>
ceene: we have one for IR management, one for RF-monitor management on modem, and one for I-forgot-what
<wpwrak>
sim power selection
<Joerg-Neo900>
right
<Joerg-Neo900>
which actually been the first one we implemented
<wpwrak>
plus another one for PCM multiplexing (v2 only)
<Joerg-Neo900>
that's an interim helper chip, yes
<Joerg-Neo900>
the nice thing about them is: throw in and forget, during circuit design. worry about their config later
<Joerg-Neo900>
and it's very simple and quick and straight forward to develop some stuff loike PCM mux in their excellent development kit (devboard and app)
<wpwrak>
silego is what happens when a lazy engineer stumbles across a mysterious bottle on a beach on a deserted island, then rubs the bottle ...
<Joerg-Neo900>
PCM mux is a nobrainer
<Joerg-Neo900>
just connect input to output, done
<ceene>
i2c protocol is like someone tied a couple wires together and decided it was gonna be able to scale to whatever you could think of
<Joerg-Neo900>
nah, that's onewire ;-P
<Joerg-Neo900>
I2C is already pretty sane concept
<ceene>
except for random addressing
<Joerg-Neo900>
low pincount, not too slow, very low requirements on interface
<Joerg-Neo900>
for 'smart addressing' use the one wire daisychaining like used in those smart RGB LEDs
<Joerg-Neo900>
but that's slow
<Joerg-Neo900>
and basically a knockoff of JTAG
<wpwrak>
now there's an idea: use silegos with default I2C address but daisy-chain SDA :)
<Joerg-Neo900>
I pondered that already
<Joerg-Neo900>
didn't I?
<Joerg-Neo900>
I thought I mentioned that in our internal chan
<wpwrak>
unfortunately, you can't change the i2c address over i2c. else, you could implement enumeration this way
<Joerg-Neo900>
umm you can't?
<Joerg-Neo900>
but... they use same I2C for programming the chip!
<wpwrak>
section 19.4.6.1 I2C Serial Command Register Protection
<Joerg-Neo900>
the dadashit has ZILCH info about programming the NVM :-/
<Joerg-Neo900>
I don't know _how_ the do/protect it but the general procedure is to have RAM content flashed to NVM aiui. So under certain conditions you have to be able to program the I2C addr in RAM
<Joerg-Neo900>
also 19.4.6.1 in my dadashit seems to not even mention the I2C addr itself as protected
<Joerg-Neo900>
ooh >> reg<1867:1864> I2C Control Code Bit [3:0] is protected from I2C write<<
<Joerg-Neo900>
so either that only applies while not-Vpp, or they do some other weird magic there
<Joerg-Neo900>
I'll test that in devboard soonish
<Joerg-Neo900>
for now I MUST run, to check if there's still a real world out there