What is the circuit driving that signal ? It appears to have too little positive drive to overcome the capacitance. Perhaps it's an open collector with too large a pull-up ?
On 21 Oct 2016 12:23 a.m., "Ilia Platone" <i...@iliaplatone.com> wrote: > sorry, no attachment, this mail contains two images, one is the previous > attempt, the second (IMG_003.JPG) was taken at 5us/div, 1v/div with a > different oscilloscope setup. > > Best Regards, > Ilia. > > On 10/20/16 18:12, Attila Kinali wrote: > >> On Thu, 20 Oct 2016 10:59:21 +0100 >> "David J Taylor" <david-tay...@blueyonder.co.uk> wrote: >> >> Actually, of the 15 Raspberry Pi cards I have only one is used in a >>> graphics >>> application. >>> >> Yes, the rpi are used for all kind of stuff and there is a huge community >> around them that helps with all kind of questions. Unfortunately, the >> rpi is also used for all kind of stuff that it is a suboptimal choice >> (to put it mildly), but people do not care or do not want to check >> for alternatives. It kind of works, that's all they care about. >> >> On the positive side they work very well with external devices for control >>> and measurement, >>> >> And for most of these applications a 32bit uC that uses a fraction of >> the power would be the right choice. Often a clock of 1MHz would be >> enough. >> >> and have a huge amount of software and hardware support for >>> a vast range of devices which makes for fast and easy development. >>> >> That's the only plus side. But then, most of the code written in C >> can be used on a uC just the same with little to no modification. >> >> I will be interested to see what is recommended for a 100 kHz event rate. >>> >> This is actually a very tough question. 100kHz means that for each event >> there is only 10µs available for detection, processing and output. Using >> a uC that would be something in the order of 1000-2000 CPU cycles. On an >> application processor (rpi and its cusins) that would be 2000 to 20'000 >> cycles. >> While 1000 cycles on a uC is quite a lot, you cannot do any fancy >> processing >> with so few cycles. >> >> On the application processor 20k cylces is plenty, but you have the >> complex >> OS that eats up a few thousand cycles itself. Addtionally there comes >> the interrupt latency that the application processors suffer from, which >> is in the order of 1-10µs... So they would need a kind of (hardware) >> system >> to queue up the events to process them in badges. Because of this, an rpi >> wouldn't work at all (bitbanging takes several µs for each operation). >> >> Going for an uC is easier in that regard as they have very little >> interrupt >> latency (usually just 5-10 cycles), but then you have problems with >> getting the output out of the uC as their I/O subsystems are usually >> optimized to work in a stand-alone fashion. >> >> Maybe one way would be to use an arm9/cortex-a5 based uC (ie not an >> application >> processor) and use their high speed I/O. >> >> For better answers, I would need to know what kind of events these are >> and what exactly need to be done/measured. >> >> Attila Kinali >> >> >> > -- > Ilia Platone > via Ferrara 54 > 47841 > Cattolica (RN), Italy > Cell +39 349 1075999 > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.