I been reading through some of the discussions here on the forum and while some seem close to what I need, none seem to directly address my issue of how to measure pulse width.
I would normally do this using a loop and a counter, but the imp is not fast enough to handle this situation (the pulses are between 25 microseconds and 50 microseconds).
The code I have tried looks like:
` laststate = controlPin.read();
// wait for the sensor to take over
while (controlPin.read() == laststate) {
counter++;
// imp.sleep(0.000001); // 10 us
}
`
Note that even with the sleep commented out, the counter never gets above 2.
Any suggestions? Am I relegated to using an external microcontroller to handle all of my bit banging?
Right, it’s not intended for this level of operation; even if it could work at this level, the processor has other things it needs to do - like wifi, tcp/ip, TLS and so on - so you’d have issues doing that continuously. Over time squirrel performance will improve, but it’s not a compiler.
There are ways around this, eg using a UART clocked at the appropriate rate (if the pulse is negative-going, then setting at 160,000bps UART will result in a 25us input pulse appearing as 0xf8 (4 bit times = start bit and 3 low bits) and 50us appearing as 0x80 (8 bit times = start bit and 7 low bits). This is then “sampled” by the hardware and buffered by the OS.
UARTs always have start and stop bits. My example above takes advantage of this (start bit is always low, stop bit is always high).
If you want direct data bits, you can use SPI for that - we’ve also used that to drive bit-width 1-wire protocols, eg talking to serial RGB LED controllers.
Does SPI permits receiving 1000 bytes in one call? Otherwise will be 8 bits with 15Mhz, than a gap till the next SPI read is done, again 8 bits etc.
If SPI is done to do 1k-5k byte read/write-s would be a fine “bitbang” driver to be honest since 15Mhz is good enough for most of the 1-100KHz bitbang stuffs …
Or You recommend to wait the bitbang driver and don’t build half solutions?
It would be nice if we would know the release dates (aprox) for a fixed SPI driver and the bitbang driver …
Release-14 (as release-12 has now been renamed) has better SPI support, where you can do blocks at a time. This should be out in the next couple of weeks once we have addressed a couple of issues.
Just checked release14 - unfortunatelly it is not good at all for data sampling
The SPI readblob has 8 clock, than pause of around 4 clocks, 8 clock etc. - that pauses between bytes does not matter for SPI but it does if I want to “sample” the SO pin using SPI reads … So this solution is not good at all - the data in the pauses between bytes is lost. I really wait for some good datasampler which can sample data …
Mmm, yes this would be because it’s not using DMA yet. It didn’t affect the “byte of SPI = 1 bit of bit-width encoding” because each bit was self-contained.
Maybe we don’t have anything that can really help you there yet then
