egg|anbo|egg has quit [Remote host closed the connection]
redstarcomrade has quit [Quit: Connection closed for inactivity]
redstarcomrade has joined #glasgow
sm2n_ has joined #glasgow
sm2n has quit [Ping timeout: 268 seconds]
GNUmoon has quit [Ping timeout: 276 seconds]
redstarcomrade has quit [Quit: Connection closed for inactivity]
GNUmoon has joined #glasgow
egg|anbo|egg has joined #glasgow
GNUmoon has quit [Ping timeout: 276 seconds]
GNUmoon has joined #glasgow
Eli2_ has joined #glasgow
Eli2 has quit [Ping timeout: 252 seconds]
egg|anbo|egg_ has joined #glasgow
egg|anbo|egg has quit [Ping timeout: 240 seconds]
egg|anbo|egg_ has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
<d1b2>
<cfy_yfc> what is the Glasgow Explorer revision you are using? me = C2
<d1b2>
<cfy_yfc> dunno if there was a change regarding the pulls between C1 and C2 though
bvernoux has joined #glasgow
icb has quit [Ping timeout: 252 seconds]
icb has joined #glasgow
<miek>
C1
FFY00_ has joined #glasgow
FFY00 has quit [Ping timeout: 268 seconds]
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
FFY00 has joined #glasgow
FFY00_ has quit [Ping timeout: 268 seconds]
redstarcomrade has joined #glasgow
egg|anbo|egg has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GregNGM has quit [Quit: ]
<d1b2>
<Attie> @cfy_yfc - sorry I've not had a look at this yet... can you share more details about your test setup and results? (i.e: applet code, are you doing input or output, pk-pk / attenuation for pull vs no-pull, etc...?)
<d1b2>
<Attie> I hope to have a look this evening
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
uartist has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
<d1b2>
<cfy_yfc> basically reusing parts of the I2C code to implement the PIC MCU programming protocol; Glasgow Explorer I/Os were connected to Saleae for debugging (or oscilloscope) I2C = clock; data PIC = ICSPCLK and ICSPDAT so data needs to be tri-stated in both cases as it is a single-wire protocol
<d1b2>
<Attie> so, if you're talking about "open drain" with pull-ups, then the rise time is direcrly linked to the pull up strength
<d1b2>
<Attie> if you're talking about push-pull, with pull up/down, then there shouldn't be much of an impact...
<d1b2>
<cfy_yfc> PICkit 3 schematic; left part: Programmer (to be emulated with Glasgow); right part: Chip to be programmed
<d1b2>
<cfy_yfc> I do not think this has anything to do with 'open drain'; should be push-pull with the only difference being that pull-down is used instead of pull-up for the I2C scenario
<d1b2>
<Attie> I'd imagine (but don't know), that when the host is transmitting it's push-pull... when the target is transmitting it may be open-collector, or there may be some turnaround and associated timings
<d1b2>
<Attie> either way, if you're using the I2C as a base, you're probably operating in open-drain... i.e: Hi-Z and pull-up for a 1, and Lo-Z for a 0
<d1b2>
<Attie> these decisions will affect timings dramatically, paired with the size of the pull up/down resistor (Glasgow's onboard is 10kOhm)
<d1b2>
<cfy_yfc> hm okay so probably a good idea then to check a lower value for R / bypass the 10k as indicated on the board
<d1b2>
<cfy_yfc> aside from that it works very well; Glasgow rocks 😉
<d1b2>
<cfy_yfc> not sure how it is internally done in PIC microcontrollers
<d1b2>
<Attie> is it a 2-way protocol?
<d1b2>
<cfy_yfc> single-wire bidirectional (on data); clk always provided by the programmer
<d1b2>
<Attie> ok, then I'd suggest you look into bus turnaround timings, and aim to operate it push-pull... consider the pull down only as a fail safe - to give the bus a know state on Rx of no target is connected
<d1b2>
<Attie> ... especially if you're aiming for 100MHz(!)
<d1b2>
<cfy_yfc> stock programmer does 500 kHz; Glasgow currently does around 200 kHz; according to the data sheet it can go up to 10 MHz; just saying: other code/applets worked well with the I/Os actually being able to deliver up to 100 MHz (tested -- works)
<d1b2>
<Attie> *known state if no target
<d1b2>
<cfy_yfc> *datasheet of the PIC MCU says it could do 10 MHz
<d1b2>
<Attie> that sounds much more reasonable :)
<d1b2>
<cfy_yfc> so I guess I need to look into this open-drain/value of R thingy more in detail; learning something new every day 😉
<electronic_eel>
PICs are notorious for having "thousands" of completely different programming mechanisms
<d1b2>
<Attie> there are lots of resources around sizing the pull-up resistors for i2c, might be a good place to start
<electronic_eel>
only if it is really open drain. the pulldowns instead of pullups will change tha characteristics and what the bus can do
<electronic_eel>
maybe the pulldowns are just used to prevent floating inputs? but 4k7 is a bit strong for that
<d1b2>
<cfy_yfc> I just thought a good way to learn Glasgow is to do an actual project so why not choose a crappy 8-bit PIC and try to program it with the Glasgow; at least the programming protocol is rather well documented
<electronic_eel>
yeah, that sounds like a good idea
<electronic_eel>
just don't expect that any other pic with a similar name will use the same protocol
<d1b2>
<cfy_yfc> GlasgowExplorer revd4 --> digipot for pull-resistors 😉
<d1b2>
<Attie> ... sigh
<electronic_eel>
digipot for pulls: that will be fun to design in a safe way...
<electronic_eel>
i fear we have to invest our brain capacity for more mundane tasks, like finding replacement parts or desings for the voltage regulators of the ports
<d1b2>
<cfy_yfc> global chip crisis sucks ... glad to have the C2 revision at hand
bvernoux has quit [Quit: Leaving]
GNUmoon has joined #glasgow
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]