highest frequency periodic interrupt?...

On 1/17/2023 3:49, Don Y wrote:
On 1/16/2023 3:56 PM, Dimiter_Popoff wrote:
I am not sure I get it, I have had such an interrupt controller on
the power cores I have used (first one on the mpc8240, late 90-s).

What happens to the core when the IRQ line from the interrupt
controller is asserted? On power, this would cause the core
to set the interrupt mask bit and go to a specific address,
roughly speaking. Then it is up to the core to clear *its*
mask bit in its MSR, no matter what the interrupt controller
does.

There is one EXTERNAL interrupt signal available.  All of the
INTERNAL (SoC) interrupt sources each connect to the NVIC
directly.  There are dozens of such sources.  The NVIC makes it
possible (to some extent) to prioritize how \"important\"
(priority) each source is.

It is the same with the power SoCs I use. What I wonder about is
how the single IRQ line/mask bit the core has is handled.
All the peripherals on the SoC go into a *peripheral*, called
the IRQ priority encoder or something. And this encoder resolves
priorities, supplies vectors etc. one way or the other.
But it has only *one* IRQ wire to the core to signal an interrupt.
Normal processors take the interrupt and enter the interrupt
handling routine - selected by whatever vector - with the interrupt
*masked*, otherwise the core would have no chance to clear the
interrupt before being interrupted again.
I see two ways out of this to allow interrupt nesting:
- the IRQ input to the core is edge sensitive and either the
IRQ is not maskable or the core unmasks itself as soon as it gets
the interrupt; the external (to the core) priority encoder would
deliver another edge only if it is of higher priority than the
last one it has delivered which is not yet reset by the core.
- the IRQ input is still level sensitive but the IACK signal from
the core to the priority encoder makes it look edge sensitive (i.e.
the priority encoder negates its IRQ to the core in response to
IACK).
Basically this would mimic 68k behaviour, the 68k core must be
doing it in some similar sort of way itself anyway.
And I suspect that *my* SoCs might do that as well... I have just never
looked into it, the IRQ latency is good enough (around 1us worst
case I think) as it is...
 
On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin
jlarkin@highlandSNIPMEtechnology.com> wrote in
cenashpl5f7cdk37nq4dab7hcdlqknptqh@4ax.com>:


We wrote one Linux program that just toggled a test point as fast as
it could. That was interesting on a scope, namely the parts that
didn\'t toggle.

That way the task switch will interrupt, any multitasker does that.

It all depends look at
\'using raspberry Pi as FM transmitter\' (80 to 100 MHz or so):
https://linuxhint.com/turn-raspberry-pi-fm-transmitter/

That code gave me the following idea,
freq_pi:
http://panteltje.com/panteltje/newsflex/download.html#freq_pi

and that was for a very old Pi model,
somebody then ported it to a later model, no idea how fast you can go on a Pi4.

So, basically, you mentioned:
\"will give it (Pi4) to some programmer\"

Now let me tell you this!!!

STUDY THE HARDWARE
that Pi4 has some quite complex very powerful hardware on board.
Using that will beat any \'just code a loop in C or asm or whatever\' or interrupt stuff.

The Pi4 would just be the dev and debug system, so I don\'t care how
fast it is. Its cost is a few percent of a PC-based dev platform. The
products will use Pico, bare metal.

The same goes for most micros, most have extra hardware on board.
What we see now is programmers who have no clue about hardware
building libraries that are bloated and slow
that then are used by others that have even less knowledge of the hardware
AND of programming and user interfaces to make modern bloat like microsore and jmail email crap.

So my advice to you: study the hardware of that Pi4 you bought for all those dollars.
Most of the time no need to learn ARM asm (and all its registers) just make use of the hardware there is.

\'A programmer\' likely will not understand the hardware and resort to bloat where it is not needed.

I\'m always impressed by how little most realtime programmers know
about, well, real time.

They usually have no clue about execution times, or how to measure
same. I buy them oscilloscopes. They are usually reluctant to use the
CPUs hard, typically by about a factor of twenty.
 
On 1/17/2023 7:36 AM, Dimiter_Popoff wrote:
On 1/17/2023 3:49, Don Y wrote:
On 1/16/2023 3:56 PM, Dimiter_Popoff wrote:
I am not sure I get it, I have had such an interrupt controller on
the power cores I have used (first one on the mpc8240, late 90-s).

What happens to the core when the IRQ line from the interrupt
controller is asserted? On power, this would cause the core
to set the interrupt mask bit and go to a specific address,
roughly speaking. Then it is up to the core to clear *its*
mask bit in its MSR, no matter what the interrupt controller
does.

There is one EXTERNAL interrupt signal available.  All of the
INTERNAL (SoC) interrupt sources each connect to the NVIC
directly.  There are dozens of such sources.  The NVIC makes it
possible (to some extent) to prioritize how \"important\"
(priority) each source is.

It is the same with the power SoCs I use. What I wonder about is
how the single IRQ line/mask bit the core has is handled.
All the peripherals on the SoC go into a *peripheral*, called
the IRQ priority encoder or something. And this encoder resolves
priorities, supplies vectors etc. one way or the other.

Yes. The NVIC has a similar role and interconnect.

But it has only *one* IRQ wire to the core to signal an interrupt.
Normal processors take the interrupt and enter the interrupt
handling routine - selected by whatever vector - with the interrupt
*masked*, otherwise the core would have no chance to clear the
interrupt before being interrupted again.
I see two ways out of this to allow interrupt nesting:
- the IRQ input to the core is edge sensitive and either the
IRQ is not maskable or the core unmasks itself as soon as it gets
the interrupt; the external (to the core) priority encoder would
deliver another edge only if it is of higher priority than the
last one it has delivered which is not yet reset by the core.

The core could signal the acknowledgement of the request
and the NVIC release the request -- unless another interrupt
of higher priority immediately follows.

The core can similarly signal the NVIC when the ISR is complete
so the NVIC would know to allow LOWER priority requests through.

- the IRQ input is still level sensitive but the IACK signal from
the core to the priority encoder makes it look edge sensitive (i.e.
the priority encoder negates its IRQ to the core in response to
IACK).

That\'s what I was suggesting, above. Remember, everything ARM is
\"pieced together\". If this was a conventional/legacy design,
the NVIC would likely be a separate chip with a bus interface
to the CPU and some special signals/handshakes for the interrupt.

When you think about it, there is a rather narrow bit of information
that must be exchanged between the two parties. So, it\'s likely
a good partitioning of functionality.

Other processors have resorted to different contortions to give
flexibility in interrupt handling *outside* the CPU. E.g.,
the 8085 allows the user to jam opcodes onto the bus. Typically,
you would jam one of the \"restart\" opcodes to force a \"call\"
to one of 8 specific addresses. But, you could jam any other
opcode if you wanted to be creative.

The Z80 had a \"vectored\" mode where you put an interrupt number
on the bus and it would use this as an offset into the interrupt
vector table.

The 8x300 didn\'t even have an IRQ! You had to build a machine
off-chip to jam opcodes onto the bus in place of instruction
fetches! (that logic also had to capture the return address
and store it EXTERNAL TO THE PROCESSOR!)

Basically this would mimic 68k behaviour, the 68k core must be
doing it in some similar sort of way itself anyway.
And I suspect that *my* SoCs might do that as well... I have just never
looked into it, the IRQ latency is good enough (around 1us worst
case I think) as it is...
 
On 1/17/2023 18:15, Don Y wrote:
On 1/17/2023 7:36 AM, Dimiter_Popoff wrote:
On 1/17/2023 3:49, Don Y wrote:
On 1/16/2023 3:56 PM, Dimiter_Popoff wrote:
I am not sure I get it, I have had such an interrupt controller on
the power cores I have used (first one on the mpc8240, late 90-s).

What happens to the core when the IRQ line from the interrupt
controller is asserted? On power, this would cause the core
to set the interrupt mask bit and go to a specific address,
roughly speaking. Then it is up to the core to clear *its*
mask bit in its MSR, no matter what the interrupt controller
does.

There is one EXTERNAL interrupt signal available.  All of the
INTERNAL (SoC) interrupt sources each connect to the NVIC
directly.  There are dozens of such sources.  The NVIC makes it
possible (to some extent) to prioritize how \"important\"
(priority) each source is.

It is the same with the power SoCs I use. What I wonder about is
how the single IRQ line/mask bit the core has is handled.
All the peripherals on the SoC go into a *peripheral*, called
the IRQ priority encoder or something. And this encoder resolves
priorities, supplies vectors etc. one way or the other.

Yes.  The NVIC has a similar role and interconnect.

But it has only *one* IRQ wire to the core to signal an interrupt.
Normal processors take the interrupt and enter the interrupt
handling routine - selected by whatever vector - with the interrupt
*masked*, otherwise the core would have no chance to clear the
interrupt before being interrupted again.
I see two ways out of this to allow interrupt nesting:
- the IRQ input to the core is edge sensitive and either the
IRQ is not maskable or the core unmasks itself as soon as it gets
the interrupt; the external (to the core) priority encoder would
deliver another edge only if it is of higher priority than the
last one it has delivered which is not yet reset by the core.

The core could signal the acknowledgement of the request
and the NVIC release the request -- unless another interrupt
of higher priority immediately follows.

The core can similarly signal the NVIC when the ISR is complete
so the NVIC would know to allow LOWER priority requests through.

I just had a look at the interrupt controller on the older of the
power cores I have used, the MPC8240. Called EPIC, for embedded
programmable interrupt controller of course :).

It does all that as I assumed; however there is no IACK signal from
the core back to it, the processor must access a location for that.
The controller would then negate the interrupt request so the core
can reenable the interrupt line by the respective bit in its state
register. Like many things power this is also delegated wherever
this can be done to add flexibility, basically does the same thing
as the 3 bit mask on 68k (has 4 bits on that one though).
Apparently I have never needed *that* kind of low latency (tens
of ns) so I still live with the \"prioritize your interrupts as you
feel right, I\'ll take the next one when I am done with the current one\".
 
On a sunny day (Tue, 17 Jan 2023 07:44:44 -0800) it happened John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote in
<g1gdshpc584v9eioeq4b1jo8073vo5lsbc@4ax.com>:

On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin
jlarkin@highlandSNIPMEtechnology.com> wrote in
cenashpl5f7cdk37nq4dab7hcdlqknptqh@4ax.com>:


We wrote one Linux program that just toggled a test point as fast as
it could. That was interesting on a scope, namely the parts that
didn\'t toggle.

That way the task switch will interrupt, any multitasker does that.

It all depends look at
\'using raspberry Pi as FM transmitter\' (80 to 100 MHz or so):
https://linuxhint.com/turn-raspberry-pi-fm-transmitter/

That code gave me the following idea,
freq_pi:
http://panteltje.com/panteltje/newsflex/download.html#freq_pi

and that was for a very old Pi model,
somebody then ported it to a later model, no idea how fast you can go on a Pi4.

So, basically, you mentioned:
\"will give it (Pi4) to some programmer\"

Now let me tell you this!!!

STUDY THE HARDWARE
that Pi4 has some quite complex very powerful hardware on board.
Using that will beat any \'just code a loop in C or asm or whatever\' or interrupt stuff.

The Pi4 would just be the dev and debug system, so I don\'t care how
fast it is. Its cost is a few percent of a PC-based dev platform. The
products will use Pico, bare metal.

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

My Pi4 8 GB locked up on the daily.mail.co.uk website just now. using Chromium browser...
That is the first time, power sequence off / on and its running again, strange.
Nothing is perfect...

I\'m always impressed by how little most realtime programmers know
about, well, real time.

They usually have no clue about execution times, or how to measure
same. I buy them oscilloscopes. They are usually reluctant to use the
CPUs hard, typically by about a factor of twenty.

Maybe to do with history, when I started with logic there were no microprocessors
and you had to do simple hardware design, gates, multiplexers, buffers, what not.
You mentioned state machines a while back..

Insight for me was when I realized all that logic could only work because gates etc had a delay.
Color TV was all nano second stuff that had to be in phase for the right color over
long distances between sources (like cameras and even cameras in remote locations) and
video tape recorders so all control loops to keep in ns lock.
All without computers in sixties..
So nano nano has become a bit of a second nature to me.
Maybe why I got pissed with gee-mail this morning
\'sorry we are having a problem try again later\'
and then \'you have one email\' but nowhere to be found...

Anyways, how are things there, flooding stopped?
Rain has stopped here (for now, was sunny and about to go biking when hail started
and within seconds everything was covered by small white balls:
http://panteltje.com/pub/sudden_hail_IXIMG_0915.JPG
Looked up rain radar and concluded it was just a few clouds, the white stuff melted a few minutes
later.. Bought lots of cookies and some Belgian potato chips...
Now frost is predicted.....
Chips and coffee with cream and chocolate and .. I am ready for it!
 
On Tue, 17 Jan 2023 17:52:08 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Tue, 17 Jan 2023 07:44:44 -0800) it happened John Larkin
jlarkin@highlandSNIPMEtechnology.com> wrote in
g1gdshpc584v9eioeq4b1jo8073vo5lsbc@4ax.com>:

On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin
jlarkin@highlandSNIPMEtechnology.com> wrote in
cenashpl5f7cdk37nq4dab7hcdlqknptqh@4ax.com>:


We wrote one Linux program that just toggled a test point as fast as
it could. That was interesting on a scope, namely the parts that
didn\'t toggle.

That way the task switch will interrupt, any multitasker does that.

It all depends look at
\'using raspberry Pi as FM transmitter\' (80 to 100 MHz or so):
https://linuxhint.com/turn-raspberry-pi-fm-transmitter/

That code gave me the following idea,
freq_pi:
http://panteltje.com/panteltje/newsflex/download.html#freq_pi

and that was for a very old Pi model,
somebody then ported it to a later model, no idea how fast you can go on a Pi4.

So, basically, you mentioned:
\"will give it (Pi4) to some programmer\"

Now let me tell you this!!!

STUDY THE HARDWARE
that Pi4 has some quite complex very powerful hardware on board.
Using that will beat any \'just code a loop in C or asm or whatever\' or interrupt stuff.

The Pi4 would just be the dev and debug system, so I don\'t care how
fast it is. Its cost is a few percent of a PC-based dev platform. The
products will use Pico, bare metal.

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

My Pi4 8 GB locked up on the daily.mail.co.uk website just now. using Chromium browser...
That is the first time, power sequence off / on and its running again, strange.
Nothing is perfect...

I\'m always impressed by how little most realtime programmers know
about, well, real time.

They usually have no clue about execution times, or how to measure
same. I buy them oscilloscopes. They are usually reluctant to use the
CPUs hard, typically by about a factor of twenty.

Maybe to do with history, when I started with logic there were no microprocessors
and you had to do simple hardware design, gates, multiplexers, buffers, what not.
You mentioned state machines a while back..

Insight for me was when I realized all that logic could only work because gates etc had a delay.

The flops in LT Spice don\'t make a reliable shift register unless you
specifically add prop delay.

Real shift registers, like a string of 8-wides, can mess up too, if
the clocks aren\'t distributed right. A few parts are really safe,
input on rising edge but output on falling edge. Sometimes I add a
resistor between chips, Qout to Din, to allow for clock skew.


Color TV was all nano second stuff that had to be in phase for the right color over
long distances between sources (like cameras and even cameras in remote locations) and
video tape recorders so all control loops to keep in ns lock.
All without computers in sixties..
So nano nano has become a bit of a second nature to me.
Maybe why I got pissed with gee-mail this morning
\'sorry we are having a problem try again later\'
and then \'you have one email\' but nowhere to be found...

Anyways, how are things there, flooding stopped?

It\'s cool, sunny, and beautiful. I hope the storm season is just
pausing for a while. We need more rain and snow.


Rain has stopped here (for now, was sunny and about to go biking when hail started
and within seconds everything was covered by small white balls:
http://panteltje.com/pub/sudden_hail_IXIMG_0915.JPG

Yikes, but doesn\'t look lethal.

Looked up rain radar and concluded it was just a few clouds, the white stuff melted a few minutes
later.. Bought lots of cookies and some Belgian potato chips...

We may have shrimp sliders and tater tots for dinner. Or maybe the
leftover dumplings.

https://www.uniteddumplings.com/

The wontons in red oil are fabulous. And the string beans.


Now frost is predicted.....
Chips and coffee with cream and chocolate and .. I am ready for it!
 
tirsdag den 17. januar 2023 kl. 21.10.33 UTC+1 skrev John Larkin:
On Tue, 17 Jan 2023 17:52:08 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

On a sunny day (Tue, 17 Jan 2023 07:44:44 -0800) it happened John Larkin
jla...@highlandSNIPMEtechnology.com> wrote in
g1gdshpc584v9eioe...@4ax.com>:

On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin
jla...@highlandSNIPMEtechnology.com> wrote in
cenashpl5f7cdk37n...@4ax.com>:


We wrote one Linux program that just toggled a test point as fast as
it could. That was interesting on a scope, namely the parts that
didn\'t toggle.

That way the task switch will interrupt, any multitasker does that.

It all depends look at
\'using raspberry Pi as FM transmitter\' (80 to 100 MHz or so):
https://linuxhint.com/turn-raspberry-pi-fm-transmitter/

That code gave me the following idea,
freq_pi:
http://panteltje.com/panteltje/newsflex/download.html#freq_pi

and that was for a very old Pi model,
somebody then ported it to a later model, no idea how fast you can go on a Pi4.

So, basically, you mentioned:
\"will give it (Pi4) to some programmer\"

Now let me tell you this!!!

STUDY THE HARDWARE
that Pi4 has some quite complex very powerful hardware on board.
Using that will beat any \'just code a loop in C or asm or whatever\' or interrupt stuff.

The Pi4 would just be the dev and debug system, so I don\'t care how
fast it is. Its cost is a few percent of a PC-based dev platform. The
products will use Pico, bare metal.

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

My Pi4 8 GB locked up on the daily.mail.co.uk website just now. using Chromium browser...
That is the first time, power sequence off / on and its running again, strange.
Nothing is perfect...

I\'m always impressed by how little most realtime programmers know
about, well, real time.

They usually have no clue about execution times, or how to measure
same. I buy them oscilloscopes. They are usually reluctant to use the
CPUs hard, typically by about a factor of twenty.

Maybe to do with history, when I started with logic there were no microprocessors
and you had to do simple hardware design, gates, multiplexers, buffers, what not.
You mentioned state machines a while back..

Insight for me was when I realized all that logic could only work because gates etc had a delay.
The flops in LT Spice don\'t make a reliable shift register unless you
specifically add prop delay.

Real shift registers, like a string of 8-wides, can mess up too, if
the clocks aren\'t distributed right. A few parts are really safe,
input on rising edge but output on falling edge. Sometimes I add a
resistor between chips, Qout to Din, to allow for clock skew.

many shift registers like 74HC595 are guaranteed zero-hold
so a safe way is to first route the clock to the last in the chain and
then to rest the opposite direction of the data

same trick works for paralleling things, wire the two terminals in the
opposite direction so the wire resistance is the same for all of them
 
Buy Vape Cartridges Online
Variegated Plants For Sale Near Me
Bruce Banner #3 Strain
Buy Edibles Online
Buy Dank Gummies 500mg
Brass Knuckles For Sale
White Monstera For Sale
Buy AK-47 Weed Online
Buy One Up Mushroom Bar 3.5G
Tales Of Arabian Nights
Buy Green Crack Online
Ghost Train Haze For Sale
Buy Alaskan Thunder Fuck Online
Buy Budheads Edibles Chewy Cubes 600 mg
Buy Rhaphidophora tetrasperma
Buy Acapulco Gold strain online
Batman 66 Pinball For Sale
Monstera Albo For Sale Florida
Buy Gas Heads Edibles 600mg
Buy Bhang Cartridges Online
Philodendron fibraecataphyllum
Buy Iron Man Pinball Online
Buy Sour Diesel Online
Caudex (Beaucarnea)
Twilight Zone Pinball For Sale
Buy Nova Vape Carts Online
Maranta Lemon Lime For Sale
Philodendron Caramel Marble Variegated
Blueberry Strain For Sale
Pinball Machine Star Wars
Philodendron Florida Beauty Variegata
Buy Kali Mist Online
Jurassic Park Pinball
Buy Chocolope Online
Buy Durban Poison Online
Buy Spliffin Vape Cartridges Online
Buy Skywalker OG Online
Buy Push Vape Cartridges Online
Buy Wonders 1000mg THC Canna Lean Online
Buy Grapefruit Online
Friendly Farms Carts For Sale
Buy Lemon Haze Strain
Buy Weed Online
Variegated Plant Shop
Pinball Machine For Sale Near Me
eBAY PinBall Machine
Buy Grease Monkey Exotic Carts
710 Kingpen Catridges For Sale
Buy Moonrock clear carts online
Rare Variegated Plants For Sale
Variegated Plants For Sale UK
Variegated Plants For Sale NZ
Philodendron Florida Beauty Variegated For Sale
Rove Carts For Sale


https://megaweedmarketltd.com/
https://qualitypinballcompany.com/
https://qualityvariegatedplants.com/

https://megaweedmarketltd.com/product/bruce_banner_strain/
https://megaweedmarketltd.com/product/dank_gummies/
https://megaweedmarketltd.com/product/brass_knuckles_for_sale/
https://qualityvariegatedplants.com/product/white-monstera-for-sale/
https://megaweedmarketltd.com/product/ak_47_strain/
https://megaweedmarketltd.com/product/one_up_bar/
https://qualitypinballcompany.com/product/tales_of_arabian_nights/
https://megaweedmarketltd.com/product/green_crack_strain/
https://megaweedmarketltd.com/product/ghost-train-haze/
https://megaweedmarketltd.com/product/buy-alaskan-thunder-fuck-online/
https://megaweedmarketltd.com/product/budheads/
https://qualityvariegatedplants.com/product/buy-rhaphidophora-tetrasperma/
https://megaweedmarketltd.com/product/buy-acapulco-gold-strain-online/
https://qualitypinballcompany.com/product/batman_66_pinball_for_sale/
https://qualityvariegatedplants.com/product/monstera-albo-for-sale-florida/
https://megaweedmarketltd.com/product/gas_heads/
https://megaweedmarketltd.com/product/buy_bhang_cartridges_online/
https://qualityvariegatedplants.com/product/philodendron-fibraecataphyllum/
https://qualitypinballcompany.com/product/buy_iron_man_pinball_online/
https://megaweedmarketltd.com/product/sour-diesel/
https://qualityvariegatedplants.com/product/caudex-beaucarnea/
https://qualitypinballcompany.com/product/twilight_zone_pinball_for_sale/
https://megaweedmarketltd.com/product/buy_nova_vape_carts_online/
https://qualityvariegatedplants.com/product/maranta-lemon-lime-for-sale/
https://qualityvariegatedplants.com/product/philodendron-caramel-marble/
https://megaweedmarketltd.com/product/blueberry_strain/
https://qualitypinballcompany.com/product/pinball_machine_star_wars/
https://qualityvariegatedplants.com/product/philodendron-florida-beauty-2/
https://megaweedmarketltd.com/product/kali-mist/
https://qualitypinballcompany.com/product/jurassic_park_pinball/
https://megaweedmarketltd.com/product/chocolope/
https://megaweedmarketltd.com/product/buy-durban-poison-online/
https://megaweedmarketltd.com/product/spliffin_cartridges/
https://megaweedmarketltd.com/product/skywalker_strain/
https://megaweedmarketltd.com/product/buy_push_vape_cartridges_online/
https://megaweedmarketltd.com/product/thc_lean/
https://megaweedmarketltd.com/product/grapefruit/
https://megaweedmarketltd.com/product/friendly_farms/
https://megaweedmarketltd.com/product/lemon_haze/
https://megaweedmarketltd.com/product/buy_grease_monkey_exotic_carts/
https://megaweedmarketltd.com/product/710_kingpen_cartridges_for_sale/
https://megaweedmarketltd.com/product/buy_moonrock_clear_carts_online/
https://qualityvariegatedplants.com/product/philodendron-florida-beauty-variegated-for-sale/
https://qualityvariegatedplants.com/product/philodendron-florida-beauty-for-sale-near-me/
https://megaweedmarketltd.com/product/rove_carts/
 
On 1/17/2023 10:10 AM, Dimiter_Popoff wrote:

But it has only *one* IRQ wire to the core to signal an interrupt.
Normal processors take the interrupt and enter the interrupt
handling routine - selected by whatever vector - with the interrupt
*masked*, otherwise the core would have no chance to clear the
interrupt before being interrupted again.
I see two ways out of this to allow interrupt nesting:
- the IRQ input to the core is edge sensitive and either the
IRQ is not maskable or the core unmasks itself as soon as it gets
the interrupt; the external (to the core) priority encoder would
deliver another edge only if it is of higher priority than the
last one it has delivered which is not yet reset by the core.

The core could signal the acknowledgement of the request
and the NVIC release the request -- unless another interrupt
of higher priority immediately follows.

The core can similarly signal the NVIC when the ISR is complete
so the NVIC would know to allow LOWER priority requests through.

I just had a look at the interrupt controller on the older of the
power cores I have used, the MPC8240. Called EPIC, for embedded
programmable interrupt controller of course :).

It does all that as I assumed; however there is no IACK signal from
the core back to it, the processor must access a location for that.

Or, the controller could implicitly jam a vector onto the bus, etc.
It depends on what the controller can \"see\" about the inner workings
of the core. E.g., the 8x300\'s approach was to let the designer
watch the CPU\'s operation and \"trick\" it into \"interrupting\" it\'s
execution sequence (the external logic had to capture the return address
and reapply it -- no stack! -- when it saw the RET being executed)

The controller would then negate the interrupt request so the core
can reenable the interrupt line by the respective bit in its state
register. Like many things power this is also delegated wherever
this can be done to add flexibility, basically does the same thing
as the 3 bit mask on 68k (has 4 bits on that one though).
Apparently I have never needed *that* kind of low latency (tens
of ns) so I still live with the \"prioritize your interrupts as you
feel right, I\'ll take the next one when I am done with the current one\".

I am really loath to rely on interrupts for much. Too often, people
treat jobs as having \"hard\" real-time components when, in fact, they
don\'t need to be. So, they design \"more brittle\" (brittler?) solutions
and declare that \"This MUST happen\"... which, of course, gives them
an excuse to not think about the consequences if it doesn\'t!

[E.g., what happens if you miss a character in a serial stream?
Do you know *where* you missed it? Do you know how *many* you
missed? Will the sender be able to learn of this problem and
recover? Do you impose sequence numbers on messages? etc.]

[[Serial port drivers are delightful to watch people screw up.
Too much \"three-dimensional\" thinking involved... plus a belief
that \"it\'s simple, right?\"]]
 
On a sunny day (Tue, 17 Jan 2023 12:10:21 -0800) it happened John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote in
<jgvdsh5f09j13nrkh6hco5uc5st0i0bu2b@4ax.com>:

We may have shrimp sliders and tater tots for dinner. Or maybe the
leftover dumplings.

https://www.uniteddumplings.com/

Yummy , looks nice!


>The wontons in red oil are fabulous. And the string beans.
 
On a sunny day (Tue, 17 Jan 2023 12:10:21 -0800) it happened John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote in
<jgvdsh5f09j13nrkh6hco5uc5st0i0bu2b@4ax.com>:

On Tue, 17 Jan 2023 17:52:08 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:

Rain has stopped here (for now, was sunny and about to go biking when hail started
and within seconds everything was covered by small white balls:
http://panteltje.com/pub/sudden_hail_IXIMG_0915.JPG

Yikes, but doesn\'t look lethal.

2 accidents happened, there was warning about it in the news.
That stuff acts like ball bearings
you drive - into a field like that - and steering and breaking has no effect,
you will keep moving in a straight line!
 
On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

OK I did read all 636 pages of the datasheet just now.
What I do not like for starters is the 12 bit ADC uses the 3.3 V supply as referene it seems,
see page 566 specifically.

My PIC ADC has a programmable internal reference (1, 2, or 4 times 1,24 V)

Also my PIC has 2 hardware comparators, one can reset the PMW for cycle by cycle current limit.

Am I imagining this or is this hardware bloat design by them?
Not even on on-board EEPROM like my PICs have...

Its not my chip!
 
On Wed, 18 Jan 2023 13:37:37 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

OK I did read all 636 pages of the datasheet just now.
What I do not like for starters is the 12 bit ADC uses the 3.3 V supply as referene it seems,
see page 566 specifically.

They are clear that one can add a bandgap to pin 35 of the Pico, or
force an external reference.

My PIC ADC has a programmable internal reference (1, 2, or 4 times 1,24 V)

Also my PIC has 2 hardware comparators, one can reset the PMW for cycle by cycle current limit.

Am I imagining this or is this hardware bloat design by them?
Not even on on-board EEPROM like my PICs have...

2 Mbyte serial flash on the Pico. That should be plenty for a
reasonable product.


Its not my chip!

Digikey has 200K of the 2040 chips in stock for $1, and 19K of the Pi
Pico board for $4. What\'s interesting is that the pricing is for any
quantity. The Pi foundation probably requires that.

They are mostly back-ordered or EOL on the other ARMs that we have
used, and are price gouging at that.
 
On a sunny day (Wed, 18 Jan 2023 08:18:21 -0800) it happened John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote in
<626gshlmh4f38bp5b04ujafcs9hb0qg4pk@4ax.com>:

On Wed, 18 Jan 2023 13:37:37 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:

On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

OK I did read all 636 pages of the datasheet just now.
What I do not like for starters is the 12 bit ADC uses the 3.3 V supply as referene it seems,
see page 566 specifically.

They are clear that one can add a bandgap to pin 35 of the Pico, or
force an external reference.

Must have missed that.



My PIC ADC has a programmable internal reference (1, 2, or 4 times 1,24 V)

Also my PIC has 2 hardware comparators, one can reset the PMW for cycle by cycle current limit.

Am I imagining this or is this hardware bloat design by them?
Not even on on-board EEPROM like my PICs have...

2 Mbyte serial flash on the Pico. That should be plenty for a
reasonable product.

The nice point of EEPROM is for example keep settings after power down, calibration of things.


Digikey has 200K of the 2040 chips in stock for $1, and 19K of the Pi
Pico board for $4. What\'s interesting is that the pricing is for any
quantity. The Pi foundation probably requires that.

They are mostly back-ordered or EOL on the other ARMs that we have
used, and are price gouging at that.

18F14K22 has 16k FLASH, 256 bytes EEPROM
you could store your FPGA code in the FLASH for example (dunno how many bytes you need)
sleep mode 34 nA for the PIC 18LF1XK22
Hobby shop in UK has 30 in stock
Aliexpres has 100 for about 200$ it says.
Many analog inputs, DAC output, PWM generator, serial, but no USB
But I have cheap serial to USB modules from ebay for my projects.
I program the PICs is ASM, so far no problems, even controls my drone,
radiation meters (PMT based too), clock, bench power supply, camera motion control,
FM transmitter, fluxgate compass, thermocouple tester, step motor control, many thing
http://panteltje.com/panteltje/pic/index.html
none of those ever gave a problem!

Anyways, let us know how that module pans out!

gm2pic has been on 24/7 now since 2011, the OLED display did suffer burn in,
replaced that by a new one,..
12 years is pretty good data retention for its FLASH.

No, if I needed more computer power and/or C programming then I would get the Raspberry Pi 4
It seems halfway this year they will pop up again? By the zillions?
Anyways you have one now, so have fun!
Do not give it away to your \'programmer\' :)
 
On Wed, 18 Jan 2023 17:43:12 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Wed, 18 Jan 2023 08:18:21 -0800) it happened John Larkin
jlarkin@highlandSNIPMEtechnology.com> wrote in
626gshlmh4f38bp5b04ujafcs9hb0qg4pk@4ax.com>:

On Wed, 18 Jan 2023 13:37:37 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:

On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

OK I did read all 636 pages of the datasheet just now.
What I do not like for starters is the 12 bit ADC uses the 3.3 V supply as referene it seems,
see page 566 specifically.

They are clear that one can add a bandgap to pin 35 of the Pico, or
force an external reference.

Must have missed that.



My PIC ADC has a programmable internal reference (1, 2, or 4 times 1,24 V)

Also my PIC has 2 hardware comparators, one can reset the PMW for cycle by cycle current limit.

Am I imagining this or is this hardware bloat design by them?
Not even on on-board EEPROM like my PICs have...

2 Mbyte serial flash on the Pico. That should be plenty for a
reasonable product.

The nice point of EEPROM is for example keep settings after power down, calibration of things.

We\'d need in the 2M flash, per unit, the runtime code, the calibration
table, sometimes an FPGA bit stream, and a release notes text file.
Some of the runtime code, the fast ISR for one of the ARM cores, would
be relocated into SRAM at powerup time. That might be another file in
the flash. I\'ve got to figure that out.




Digikey has 200K of the 2040 chips in stock for $1, and 19K of the Pi
Pico board for $4. What\'s interesting is that the pricing is for any
quantity. The Pi foundation probably requires that.

They are mostly back-ordered or EOL on the other ARMs that we have
used, and are price gouging at that.

18F14K22 has 16k FLASH, 256 bytes EEPROM
you could store your FPGA code in the FLASH for example (dunno how many bytes you need)
sleep mode 34 nA for the PIC 18LF1XK22
Hobby shop in UK has 30 in stock
Aliexpres has 100 for about 200$ it says.
Many analog inputs, DAC output, PWM generator, serial, but no USB
But I have cheap serial to USB modules from ebay for my projects.
I program the PICs is ASM, so far no problems, even controls my drone,
radiation meters (PMT based too), clock, bench power supply, camera motion control,
FM transmitter, fluxgate compass, thermocouple tester, step motor control, many thing
http://panteltje.com/panteltje/pic/index.html
none of those ever gave a problem!

Anyways, let us know how that module pans out!

gm2pic has been on 24/7 now since 2011, the OLED display did suffer burn in,
replaced that by a new one,..
12 years is pretty good data retention for its FLASH.

No, if I needed more computer power and/or C programming then I would get the Raspberry Pi 4
It seems halfway this year they will pop up again? By the zillions?
Anyways you have one now, so have fun!
Do not give it away to your \'programmer\' :)

I\'d just buy 10 more from Amazon and make sure that are all set up the
same.
 
onsdag den 18. januar 2023 kl. 19.48.54 UTC+1 skrev John Larkin:
On Wed, 18 Jan 2023 17:43:12 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

On a sunny day (Wed, 18 Jan 2023 08:18:21 -0800) it happened John Larkin
jla...@highlandSNIPMEtechnology.com> wrote in
626gshlmh4f38bp5b...@4ax.com>:

On Wed, 18 Jan 2023 13:37:37 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

OK I did read all 636 pages of the datasheet just now.
What I do not like for starters is the 12 bit ADC uses the 3.3 V supply as referene it seems,
see page 566 specifically.

They are clear that one can add a bandgap to pin 35 of the Pico, or
force an external reference.

Must have missed that.



My PIC ADC has a programmable internal reference (1, 2, or 4 times 1,24 V)

Also my PIC has 2 hardware comparators, one can reset the PMW for cycle by cycle current limit.

Am I imagining this or is this hardware bloat design by them?
Not even on on-board EEPROM like my PICs have...

2 Mbyte serial flash on the Pico. That should be plenty for a
reasonable product.

The nice point of EEPROM is for example keep settings after power down, calibration of things.
We\'d need in the 2M flash, per unit, the runtime code, the calibration
table, sometimes an FPGA bit stream, and a release notes text file.
Some of the runtime code, the fast ISR for one of the ARM cores, would
be relocated into SRAM at powerup time. That might be another file in
the flash. I\'ve got to figure that out.

I\'ve not tried it yet, but as far I can tell you just decorate the function with __not_in_flash_func
in the code then the linker and bootloader figures it all out for you
 
On Wed, 18 Jan 2023 16:14:20 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

onsdag den 18. januar 2023 kl. 19.48.54 UTC+1 skrev John Larkin:
On Wed, 18 Jan 2023 17:43:12 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

On a sunny day (Wed, 18 Jan 2023 08:18:21 -0800) it happened John Larkin
jla...@highlandSNIPMEtechnology.com> wrote in
626gshlmh4f38bp5b...@4ax.com>:

On Wed, 18 Jan 2023 13:37:37 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

OK I did read all 636 pages of the datasheet just now.
What I do not like for starters is the 12 bit ADC uses the 3.3 V supply as referene it seems,
see page 566 specifically.

They are clear that one can add a bandgap to pin 35 of the Pico, or
force an external reference.

Must have missed that.



My PIC ADC has a programmable internal reference (1, 2, or 4 times 1,24 V)

Also my PIC has 2 hardware comparators, one can reset the PMW for cycle by cycle current limit.

Am I imagining this or is this hardware bloat design by them?
Not even on on-board EEPROM like my PICs have...

2 Mbyte serial flash on the Pico. That should be plenty for a
reasonable product.

The nice point of EEPROM is for example keep settings after power down, calibration of things.
We\'d need in the 2M flash, per unit, the runtime code, the calibration
table, sometimes an FPGA bit stream, and a release notes text file.
Some of the runtime code, the fast ISR for one of the ARM cores, would
be relocated into SRAM at powerup time. That might be another file in
the flash. I\'ve got to figure that out.

I\'ve not tried it yet, but as far I can tell you just decorate the function with __not_in_flash_func
in the code then the linker and bootloader figures it all out for you

It sounds like the Pi people have done everything right. I need a
maker-space refugee kid who has time to work out the details. I just
want to design circuits.

I am thinking that there are lots of cases where a dedicated 133 MHz
ARM core can replace an FPGA.
 
On Thursday, January 19, 2023 at 11:06:58 PM UTC+11, John Larkin wrote:
On Wed, 18 Jan 2023 16:14:20 -0800 (PST), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
onsdag den 18. januar 2023 kl. 19.48.54 UTC+1 skrev John Larkin:
On Wed, 18 Jan 2023 17:43:12 GMT, Jan Panteltje <pNaonSt...@yahoo.com> wrote:
On a sunny day (Wed, 18 Jan 2023 08:18:21 -0800) it happened John Larkin <jla...@highlandSNIPMEtechnology.com> wrote in <626gshlmh4f38bp5b...@4ax.com>:
On Wed, 18 Jan 2023 13:37:37 GMT, Jan Panteltje <pNaonSt...@yahoo.com> wrote:
On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje <pNaonSt...@yahoo.com> wrote:

<snip>

> It sounds like the Pi people have done everything right. I need a maker-space refugee kid who has time to work out the details. I just want to design circuits.

Sadly., John Laarkin doesn\'t seem to know what designing circuits entails. Working out the details is part of the process.

> I am thinking that there are lots of cases where a dedicated 133 MHz ARM core can replace an FPGA.

An ARM core is a single-threaded processor. With an FPGA you can set up genuinely parallel processes and have them operating simultaneously, and only communicating when they need to. It\'s a pretty basic distinction.

If you are essentially using the FPGA to realise a standard processor (and you can program them to include an ARM core) you could replace that FPGA with the right off-the-shelf processor, but it would be a pretty bizarre design assignment that lead you to do that - you\'d have to need lots of odd peripherals in a single package to make it worth doing.

--
Bill Sloman, Sydney
 
On a sunny day (Thu, 19 Jan 2023 04:06:47 -0800) it happened John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote in
<mbcish92mj940l3cilbbt83lmj83hjjl1u@4ax.com>:

I am thinking that there are lots of cases where a dedicated 133 MHz
ARM core can replace an FPGA.

I wonder, procesor in FPGA is common,
many have gone that way:
https://opencores.org

Many processors to chose from:
https://opencores.org/projects?expanded=Processor

ARM core in FPGA:
https://opencores.org/projects/amber


Have not tried it myself...
 
torsdag den 19. januar 2023 kl. 13.06.58 UTC+1 skrev John Larkin:
On Wed, 18 Jan 2023 16:14:20 -0800 (PST), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

onsdag den 18. januar 2023 kl. 19.48.54 UTC+1 skrev John Larkin:
On Wed, 18 Jan 2023 17:43:12 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

On a sunny day (Wed, 18 Jan 2023 08:18:21 -0800) it happened John Larkin
jla...@highlandSNIPMEtechnology.com> wrote in
626gshlmh4f38bp5b...@4ax.com>:

On Wed, 18 Jan 2023 13:37:37 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje
pNaonSt...@yahoo.com> wrote:

Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry
and a lot of others using the chip:
https://en.wikipedia.org/wiki/RP2040.

I also downloaded the datasheet, the pdf has 636 pages.. later!
clock is not that fast, via PLL 125 MHz, (page 187).
My 18F14K22 PICs run at 64 MHz via internal PLL

OK I did read all 636 pages of the datasheet just now.
What I do not like for starters is the 12 bit ADC uses the 3.3 V supply as referene it seems,
see page 566 specifically.

They are clear that one can add a bandgap to pin 35 of the Pico, or
force an external reference.

Must have missed that.



My PIC ADC has a programmable internal reference (1, 2, or 4 times 1,24 V)

Also my PIC has 2 hardware comparators, one can reset the PMW for cycle by cycle current limit.

Am I imagining this or is this hardware bloat design by them?
Not even on on-board EEPROM like my PICs have...

2 Mbyte serial flash on the Pico. That should be plenty for a
reasonable product.

The nice point of EEPROM is for example keep settings after power down, calibration of things.
We\'d need in the 2M flash, per unit, the runtime code, the calibration
table, sometimes an FPGA bit stream, and a release notes text file.
Some of the runtime code, the fast ISR for one of the ARM cores, would
be relocated into SRAM at powerup time. That might be another file in
the flash. I\'ve got to figure that out.

I\'ve not tried it yet, but as far I can tell you just decorate the function with __not_in_flash_func
in the code then the linker and bootloader figures it all out for you



It sounds like the Pi people have done everything right.

they are basically doing the same as Espressif have been doing for years with:
https://en.wikipedia.org/wiki/ESP8266
https://en.wikipedia.org/wiki/ESP32
 

Welcome to EDABoard.com

Sponsor

Back
Top