any raspberry pi people here?

onsdag den 20. juli 2022 kl. 00.18.53 UTC+2 skrev Joe Gwinn:

most if not all cortex-m have far more horsepower,memory,timers, and IO than an AVR

One interesting thing I noticed about the new AVR series (AVR-DA, AVR-DB, AVR-DD) is that the maximum clock speed dependency on power supply voltage has gone. They have an on-chip power supply regulator and work from 1.8 to 5.5V at a maximum of 24MHz at all voltages in that range. They are being promoted for safety critical applications and have some hardware features to support that together with a certified toolchain. A very simple architecture can have advantages in such domains. It does look as if Microchip have taken the AVR range and enhanced it in some very useful ways that could make these devices a good choice for a new design. John

Yes, most likely. My point being that we were bouncing between the guard-rails (too big, too small), and needed to widen our ken.

If I recall, the AVR does not need any VHDL or external FPGAs.

Joe Gwinn

Raspberry PI is a media player SOC, current models seem to be available only from scalpers.

There seems to be a "125", "25" and "54" the 54 seems closest to the SOC, the other two seem closest to the ethernet chip and PCIe to USB3 bridge.

You could check the schematic.

Ah right, so not actually "doing" IIC at all. just naively calling "iicWrite()" not even checking the response, just waiting and hoping. I can see how timing could be critical for that.

Ah, you're confused. ;) You naively assume my own iicwrite() is the same as a unix write(). My iicWrite() merely changes the state of combinational logic for presentation to the target as part a single, larger, I2C write message. It only changes the data sent down the SDA at precise (in some case ns) times, per the target's protocol. My /code snippet/ shows only /a part/ of a single message from the RPi2 controller to a target. With I2C you must wait until the /whole/ message is delivered before "checking." Danke,

On a sunny day (Mon, 25 Jul 2022 03:42:49 -0000 (UTC)) it happened "Don" snipped-for-privacy@crcomp.net wrote in snipped-for-privacy@crcomp.net:

I2C is a not-time critical protocol, that is why you can use it on a multitasking system where it is interrupted on a regular basis. I wrote my own i2c routines years ago and have used those on PIs many times see my website download link for code. No nano-nano stuff needed anywhere, usleep is fine..

<snip>

<snip>

"Brevity is the soul of wit" and "I2C is a not-time critical protocol" says it all, doesn't it? Here's the "Write Mode Timing Diagram" for the target of interest, my RPi2's target for this thread:

The third line down on the first table shows the "E Rise/Fall Time" Characteristic, tR. And tR's Max. is specified as 25 nS. Upon further reflection, it's clearly outside of my control. Ergo, the RPi2 itself must accomplish the rise time within spec.

Beings I2C doesn't qualify, another RPi2 to test for nsleep() must be devised. Stand by.

And, it turns out my homegrown iicWrite() actually does test for an error condition:

void iicWrite(char iicByte) { rdwr.msgs[0].buf[1] = iicByte;

if (ioctl(fd, I2CRDWR, &rdwr) < 0) { perror("ioctl"); snprintf(errMessage, sizeof(errMessage), "ioctl: error %d sending write", errno); errorExit(); } } Danke,

It's fairly clear that iicwrite take an integer (probably byte) parameter. I didn't miss that.

You know what I'm thinking about as well as you understand IIC. You should check for an ack bit after every byte sent, and I'm not seeing evidence of that above.

If you're having rate problems it's also possible you're not watching the clk line.

My apologies to you and the others who tried to get your point through my thick head. Jan's a polyglot. He's a superb communicator. And it finally sunk in.

Now, let's talk about the ack bit you mention. You correctly note how my code does not look for it. You can blame it on this profoundly lazy guy within me. He reasons, "Why not let a PCF8574A take care of all of the I2C ack housekeeping for you?" And, presto, the PCF8574A simplifies error checks:

void iicWrite(char iicByte) { rdwr.msgs[0].buf[1] = iicByte;

if (ioctl(fd, I2CRDWR, &rdwr) < 0) { perror("ioctl"); snprintf(errMessage, sizeof(errMessage), "ioctl: error %d sending write", errno); errorExit(); } } In the end, it's very poor communication on my part to lazily copy-and- paste a "code snippet" into my followup. My plan is to ultimately write- up my RPi BSD version of Jan's OLED code and publish it to my website. Danke,

The Raspberry pi 1 has a 64 bit counter offset 0x9100 in the Virtual Memory IO Space This is the Forth code, fetching a double precision number of the addres

: TICKS ^clk 2@ ;

This seems to be more reliable of the counters in the Intel. It is running at 1 Mhz. Others pi's (Orange pi) have similar counters.

Groetjes Albert

albert@cherry.(none) (albert) wrote in news:nnd$224d213a$6ed2eb7a@d7dff6696c7ccdd2:

Check out the new pico W rPi...

snipped-for-privacy@decadence.org wrote in news:tc36r3$14r9$1 @gioia.aioe.org:

Even better!