00:07 <davidc___> whitequark: you might also be able to program a SLG46583 to implement an LDO+foldback in the same part. (might be able to incorporate the setpoint DAC)

00:07 <davidc___> whitequark: if that looks potentially interesting; let me know and I'll see if I can order that part in (I have a programmer that should work for it)

00:08 <davidc___> no idea on the leadtime though; those are generally direct from mfg for production since they are usually ordered preprogrammed

00:08 <whitequark> not very open hardware friendly

00:08 <whitequark> proprietary toolchain, rare device, hard to obtai

00:08 <whitequark> * proprietary toolchain, rare device, hard to obtain

00:10 <davidc___> whitequark: fair enough. IIRC it comes with a full bitstream spec, so the meaning of all the bits programmed would be know; just not a good way to generate them

00:11 <whitequark> i've worked on a GP4 toolchain

00:11 <whitequark> so yeah, i'm familiar with that family

00:11 <davidc___> Cool. I didn't know you had worked on that!

00:12 <whitequark> in a past life

00:19 <d1b2> <xabean> something something catgirl 9 lives

02:39 <d1b2> <j4cbo> the greenpak LDO parts are very “the large print giveth and the small print taketh away”

02:40 <d1b2> <j4cbo> for example, you have to sequence the power in to them, or else the LDOs “might” shoot Vin through to Vout during configuration

02:42 <davidc___> j4cbo: thats very good to know. I haven't used them in a design; I just know they exist

03:53 <cyborg_ar> i have used greenpak parts in the past. they are incredibly neat though they are a pain to source

04:36 <davidc___> cyborg_ar: I've always ordered direct from silego (before they were bought by dialog). Did things get much worse after that?

04:50 <cyborg_ar> eh i think it is pretty much the same. last i checked you could buy from mouser

06:44 <d1b2> <zyp> I ordered two preprogrammed reels from dialog a few weeks ago, didn't have any problems

14:10 <whitequark> esden: best price on TPS73101DBVT so far is $4.37 @ 8k

14:12 <whitequark> so not any better than what you have

14:15 <whitequark> I'm going to do a detailed comparison of TPS73101DBVT and SY20704AAC, and then write to Silergy to make sure I'm not missing anything

15:05 <d1b2> <icb> Are you looking for just in-stock, or for places with shorter lead times too? Newark/Farnell claim they'll have stock in the next couple of months for much more reasonable prices

15:40 <whitequark> icb: can they actually provide 8k of them at that point? it's not enough to look at the website, you have to RFQ

15:45 <d1b2> <icb> I didn't check far enough to see. Just saw it as an option you could consider

17:17 <d1b2> <davoid> would anyone with good previous experience using the glasgow have time to do some freelance work with a tailored software implementation? simplified spec: dual uart bridge, dual i2c (switchable role), dual spi (one with a host driver for an external ADC/voltmeter), plus a set of configurable gpio's (in/out pu/pd/od/hiz)

17:37 <electronic_eel> @davoid the "dual" thing in your mini spec is what would worry me. current glasgow doesn't have mechanism yet to communicate with multiple applets at once. so this would all have to be implemented as a custom patch

17:37 <whitequark> what is a "tailored software implementation"?

17:38 <whitequark> you can communicate with multiple applets fine, just not using the CLI

17:40 <electronic_eel> wasn't splitting the bytestream coming from the fx2 into data blocks designated to the different applets on the fpga still on the todo list?

17:41 <whitequark> you can do two right now

17:41 <whitequark> so dual something is fine

17:43 <electronic_eel> ah, two is possible? i thought the whole encoding of a target id was still missing. but you found some nice mechanism that wouldn't blow up when some escape char was in the datastream repeatedly (don't remember the name right now)

17:45 <whitequark> there is no encoding

17:45 <whitequark> we have four EPs

17:45 <whitequark> two per applet work fine

17:46 <electronic_eel> ah, ok, so it can be differentiated over the usb endpoints now. is there any applet making use of this right now?

17:49 <electronic_eel> about the SY20704AAC: the dropout voltage is 300mV vs. the 30mV of the TPS73101DBVT. when you want to set a port voltage of 5V this is going to be a problem

17:51 <electronic_eel> maybe we could add a small stepup regulator (combined for both ports), then we wouldn't have to worry about the dropout or shunt burden voltage

17:52 <davidc___> electronic_eel: It'll be a problem even for the TPS7310

17:52 <electronic_eel> esden: rs claims to get some TPS73101DBVT in october this year: https://de.rs-online.com/web/p/spannungsregler/1624905/

17:53 <davidc___> electronic_eel: voltage spec for USB allows down to 4.75V

17:53 <electronic_eel> esden: so maybe give them a call

17:53 <davidc___> electronic_eel: (quoting from TI summary; haven't pulled up the spec)

17:53 <electronic_eel> davidc___: yeah, it is already on the margin and you need a usb psu going a bit above 5 v

17:54 <electronic_eel> but going from 30 mV to 300 will blow it i'd say

17:54 <davidc___> electronic_eel: yeah; and I've seen 4.5V commonly

17:54 <davidc___> electronic_eel: (general field experience with random laptops, random cables, and ~280ma load)

17:58 <whitequark> <electronic_eel> "ah, ok, so it can be differentia..." <- sorta, but mostly it's that you can already run multiple applets in parallel

17:58 <d1b2> <davoid> we'll have a python async runner on top that could read from each "pipe"/uart(s)

18:00 <d1b2> <davoid> custom == primarily helping out, holding hands, making sure the complete setup is done in an optimal way (not knowing the inner works and do's & dont's) of your architecture

18:03 <d1b2> <davoid> sounds like it can work then! most important thing is that we 1) can fit all peripherals in the ice, running at the same time 2) that uart1/2 i2c1/2 spi1/2 can stream their in/out data in an asynchronous manner

18:10 <d1b2> <davoid> yes.. especially with longer cables / thin copper. we usually boost the 5V when 5.0V out is expected, like in a hub, to ensure that you get the proper 5.1V or whatever