Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #28176 > unrolled thread
| Started by | Clifford Heath <no.spam@please.net> |
|---|---|
| First post | 2018-10-10 12:05 +1100 |
| Last post | 2018-10-15 07:30 -0700 |
| Articles | 20 on this page of 104 — 19 participants |
Back to article view | Back to comp.arch.embedded
$0.03 microcontroller Clifford Heath <no.spam@please.net> - 2018-10-10 12:05 +1100
Re: $0.03 microcontroller lasselangwadtchristensen@gmail.com - 2018-10-10 16:12 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-10 17:51 -0700
Re: $0.03 microcontroller lasselangwadtchristensen@gmail.com - 2018-10-10 18:56 -0700
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-10 19:29 -0700
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-11 11:39 +0300
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-11 16:08 -0700
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-12 08:50 +0200
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-12 09:44 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-12 21:30 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-12 22:06 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-12 23:45 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-13 21:47 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-14 11:58 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 08:14 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-11 09:27 +0100
Re: $0.03 microcontroller Klaus Kragelund <klauskvik@hotmail.com> - 2018-12-26 02:23 -0800
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 10:44 +0200
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-15 07:29 -0700
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-16 09:19 +0200
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-16 13:48 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-15 21:34 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-16 09:29 +0200
Re: $0.03 microcontroller Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-10-15 21:22 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-16 10:00 +0200
Re: $0.03 microcontroller Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-10-16 22:52 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-16 14:01 -0700
Re: $0.03 microcontroller Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-10-17 00:03 +0200
Re: $0.03 microcontroller Clifford Heath <no.spam@please.net> - 2018-10-17 09:22 +1100
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-16 15:29 -0700
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-17 00:46 +0200
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-17 09:35 +0300
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-17 09:31 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-17 07:08 -0700
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-17 18:37 +0300
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-17 10:04 -0700
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-17 23:07 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-17 08:23 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-17 19:43 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-17 20:24 +0200
Re: $0.03 microcontroller George Neuner <gneuner2@comcast.net> - 2018-10-17 11:31 -0400
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-05 12:41 +0100
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-12 09:11 -0700
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-13 12:46 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-13 05:06 -0700
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-13 18:00 +0300
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-13 18:27 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-13 20:50 +0300
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-14 14:26 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-13 18:20 -0700
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-14 08:53 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-14 08:55 +0200
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-14 14:32 +0200
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-13 18:21 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-13 18:32 -0700
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-13 19:02 -0700
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-14 14:37 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-14 14:59 +0200
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-13 11:06 -0700
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 18:31 +0300
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 19:46 +0300
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 19:59 +0300
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-13 21:31 +0300
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 22:19 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-13 21:24 +0200
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 22:50 +0300
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-14 14:39 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-15 05:11 -0700
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-13 21:03 +0300
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-13 18:25 -0700
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 14:20 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-21 16:27 +0300
Re: $0.03 microcontroller jim.brakefield@ieee.org - 2018-10-21 07:47 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-21 08:08 -0700
Re: $0.03 microcontroller jim.brakefield@ieee.org - 2018-10-21 09:31 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-21 10:51 -0700
Re: $0.03 microcontroller jim.brakefield@ieee.org - 2018-10-21 12:44 -0700
Re: $0.03 microcontroller Brett <ggtgp@yahoo.com> - 2018-10-22 00:28 +0000
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-21 21:43 +0200
Re: $0.03 microcontroller Phil Martel <pomartel@comcast.net> - 2018-10-21 11:03 -0400
Re: $0.03 microcontroller George Neuner <gneuner2@comcast.net> - 2018-10-21 20:59 -0400
Re: $0.03 microcontroller Michael Kellett <mk@mkesc.co.uk> - 2018-10-11 14:04 +0100
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-11 15:56 +0200
Re: $0.03 microcontroller Michael Kellett <mk@mkesc.co.uk> - 2018-10-13 09:35 +0100
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-13 13:06 -0700
Re: $0.03 microcontroller Michael Kellett <mk@mkesc.co.uk> - 2018-10-14 11:30 +0100
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-12 10:18 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-12 21:39 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-08 13:53 +0100
Re: $0.03 microcontroller Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-11-08 15:08 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-08 14:34 +0100
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-11-08 21:52 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-08 21:56 +0100
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-11-09 00:35 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-09 09:00 +0100
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 14:19 +0200
Re: $0.03 microcontroller Tim <cpldcpu+usenet@gmail.com> - 2018-10-14 01:46 +0200
Re: $0.03 microcontroller Theo <theom+news@chiark.greenend.org.uk> - 2018-10-14 10:55 +0100
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-24 15:57 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 14:35 +0200
Re: $0.03 microcontroller raimond.dragomir@gmail.com - 2018-10-15 06:05 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-15 07:19 -0700
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-15 07:26 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-15 07:30 -0700
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2018-10-21 20:59 -0400 |
| Message-ID | <7b2qsd1jbpqcjc7dfn3jt65o05lq6bupi6@4ax.com> |
| In reply to | #28264 |
On Sun, 21 Oct 2018 16:27:31 +0300, upsidedown@downunder.com wrote: >Slightly OT, but I have often wonder how primitive a computer >architecture can be and still do some useful work. In the >tube/discrete/SSI times, there were quite a lot 1 bit processors. >There were at least two types, the PLC (programmable Logic Controller) >type replacing relay logic. These had typically at least AND, OR, NOT, >(XOR) instructions.The other group was used as truly serial computers >with the same instructions as the PLC but also at least a 1 bit SUB >(and ADD) instructions to implement all mathematical functions. > >However, in the LSI era, there down't seem to be many implement ions. > >One that immediately comes in mind is the MC14500B PLC building block, >from the 1970's, which requires quite lot of support chips (code >memory, PC, /O chips) to do some useful work. > >After much searching, I found the (NI) National Instruments SBA >(Serial Boolean Analyser) >http://www.wass.net/othermanuals/GI%20SBA.pdf >from the same era, with 1024 word instructions (8 bit) ROM and four >banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. >For the re-entrance enthusiasts, it contains stack pointer relative >addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 >Darlington buffers may be needed to drive loads typically found in PLC >environment. > >Anyone seen more modern 1 bit chips either for relay replacement or >for truly serial computers ? Circa 1985-1993, Thinking Machines Connection Machine. Circa 1987-1996, MasPar MP series. The CM-1, 2, 2a, and 200 all were SIMD parallel using 1-bit serial integer-only CPUs. Sizes ranged from 8K CPUs at the low end to 64K CPUs at the high end. Each CPU had 4K *bits* of private RAM, and the CPUs were connected in a multidimensional hypercube network. The CM-2, 2a, and 200 were augmented with 32-bit FPUs (1 per 32 CPUs), and the 200 featured a higher clock speed. The MP-1 was SIMD parallel using 4-bit serial integer-only CPUs in sizes from 1K to 16K CPUs. It also had 32-bit FPUs, but I don't remember how many / what ratio. I remember that it had an accumulator register rather than going memory->memory like the CM. [I can't find much information now about the MP-1 ... unfortunately MasPar didn't last very long in the marketplace. The Wikipedia article has some information about the MP-2, but the MP-2 was a later full 32-bit design, very different from the MP-1.] My college had both an 8K CM-2 and a 1K MP-1, accessible to those who took various parallel processing electives. I never got to use the MP-1 much - it was new at the end of my time and I only ever played with it a bit. But I spent 2 semesters working with the CM-2. Even though the CM's clock speed was only ~8MHz, the performance was amazing IF the problem was a good fit to the architecture. E.g., at that time, I owned a 66MHz (dx2) i486. Converted for the CM-2 architecture, O(n^4) array processing on the i486 became O(n) on the CM-2. I had a physics simulation that took over 3 hours on my i486 that ran in ~10 minutes on the CM. George
[toc] | [prev] | [next] | [standalone]
| From | Michael Kellett <mk@mkesc.co.uk> |
|---|---|
| Date | 2018-10-11 14:04 +0100 |
| Message-ID | <VeGdnc-Lo7T01yLGnZ2dnUU78QfNnZ2d@giganews.com> |
| In reply to | #28176 |
On 10/10/2018 02:05, Clifford Heath wrote: > <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > > OTP, no SPI, UART or I²C, but still... > > Clifford Heath Has anyone actually used them - or worked out where to get the ICE and how much it costs ? MK
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-11 15:56 +0200 |
| Message-ID | <ppnkr5$6ai$1@dont-email.me> |
| In reply to | #28182 |
On 11/10/18 15:04, Michael Kellett wrote: > On 10/10/2018 02:05, Clifford Heath wrote: >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >> >> >> OTP, no SPI, UART or I²C, but still... >> >> Clifford Heath > > Has anyone actually used them - or worked out where to get the ICE and > how much it costs ? > > MK The cost of the ICE is not going to be significant for most people - you usually use a chip like this when you want huge quantities (even though it is available in small numbers). What turns me off here is the programming procedure for the OTP devices. There is no information on it - just a simple one-at-a-time programmer device. That is useless for production - you need an automated system, or support from existing automated programmers, or at the very least the programming information so that you can build your own specialist programmer. There is no point in buying a microcontroller for $0.03 if the time taken to manually take a device out a tube, manually program it, and manually put it back in another tube for the pick-and-place costs you $1 production time.
[toc] | [prev] | [next] | [standalone]
| From | Michael Kellett <mk@mkesc.co.uk> |
|---|---|
| Date | 2018-10-13 09:35 +0100 |
| Message-ID | <Tb-dnf7IALPFM1zGnZ2dnUU78fXNnZ2d@giganews.com> |
| In reply to | #28183 |
On 11/10/2018 14:56, David Brown wrote: > On 11/10/18 15:04, Michael Kellett wrote: >> On 10/10/2018 02:05, Clifford Heath wrote: >>> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >>> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >>> >>> >>> OTP, no SPI, UART or I²C, but still... >>> >>> Clifford Heath >> >> Has anyone actually used them - or worked out where to get the ICE and >> how much it costs ? >> >> MK > > The cost of the ICE is not going to be significant for most people - you > usually use a chip like this when you want huge quantities (even though > it is available in small numbers). > > What turns me off here is the programming procedure for the OTP devices. > There is no information on it - just a simple one-at-a-time programmer > device. That is useless for production - you need an automated system, > or support from existing automated programmers, or at the very least the > programming information so that you can build your own specialist > programmer. There is no point in buying a microcontroller for $0.03 if > the time taken to manually take a device out a tube, manually program > it, and manually put it back in another tube for the pick-and-place > costs you $1 production time. > My major interest in this part was for fun - hence caring about the cost of the ICE. From a business point of view it makes no sense - by the time you reach numbers big enough to care about the cost of the micro the risk of using a part like this is too great. Different if you are next door to the manufacturer. If you want a hardware minimal processor the Maxim 32660 looks like fun 3mm square, 24 pin Cortex M4, 96MHz, 256k flash, 96k RAM, £1.16 (10 off). My guess is that you need to be using at least 5k of them before the cheaper Padauk part offsets the cost of using one. MK
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2018-10-13 13:06 -0700 |
| Message-ID | <87k1mlmx1t.fsf@nightsong.com> |
| In reply to | #28194 |
Michael Kellett <mk@mkesc.co.uk> writes: > If you want a hardware minimal processor the Maxim 32660 looks like fun > 3mm square, 24 pin Cortex M4, 96MHz, 256k flash, 96k RAM, £1.16 (10 off). That's not minimal ;). More practically, the 3mm square package sounds like a WLCSP which I think requires specialized ($$$) board fab facilities (it can't be hand soldered or done with normal reflow processes). Part of the Padauk part's attraction is the 6-pin SOT23 package. Here's a complete STM8 board for 0.77 USD shipped: https://www.aliexpress.com/item//32527571163.html It has 8k of program flash and 1k of ram and can run a resident Forth interpreter. I think they also make a SOIC-8 version of the cpu. I bought a few of those boards for around 0.50 each last year so I guess they have gotten a bit more expensive since then.
[toc] | [prev] | [next] | [standalone]
| From | Michael Kellett <mk@mkesc.co.uk> |
|---|---|
| Date | 2018-10-14 11:30 +0100 |
| Message-ID | <TZKdnXG807Urh17GnZ2dnUU78bfNnZ2d@giganews.com> |
| In reply to | #28211 |
On 13/10/2018 21:06, Paul Rubin wrote: > Michael Kellett <mk@mkesc.co.uk> writes: >> If you want a hardware minimal processor the Maxim 32660 looks like fun >> 3mm square, 24 pin Cortex M4, 96MHz, 256k flash, 96k RAM, £1.16 (10 off). > > That's not minimal ;). More practically, the 3mm square package sounds > like a WLCSP which I think requires specialized ($$$) board fab > facilities (it can't be hand soldered or done with normal reflow > processes). Part of the Padauk part's attraction is the 6-pin SOT23 > package. > > Here's a complete STM8 board for 0.77 USD shipped: > > https://www.aliexpress.com/item//32527571163.html > > It has 8k of program flash and 1k of ram and can run a resident Forth > interpreter. I think they also make a SOIC-8 version of the cpu. I > bought a few of those boards for around 0.50 each last year so I guess > they have gotten a bit more expensive since then. > No - the BGA part is 1.6mm square (0.3mm pitch) - the 3mm is for 0.4mm pitch QFN and there is a 0.5mm pitch QFN part at 4mm square. The QFNs are reasonably prototype-able - needing only 0.15mm track and gap design rules and no filled vias in pads or other horrors. The point about the 32660 is that it is HARDWARE minimal but not constrained in software. At low volumes cost of the parts is nothing - a day of effort is $500 or more, in that context the difference between a free processor and a $2 processor is invisible. MK
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-12 10:18 +0200 |
| Message-ID | <pppldh$thf$1@solani.org> |
| In reply to | #28176 |
Am 10.10.2018 um 03:05 schrieb Clifford Heath: > <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > > OTP, no SPI, UART or I²C, but still... > > Clifford Heath They even make dual-core variants (the part where the first digit in the part number is '2'). It seems program counter, stack pointer, flag register and accumulator are per-core, while the rest, including the ALU is shared. In particular, the I/O registers are also shared, which means some multiplier registers would also be - but currently all variants with integrated multiplier are single-core. Use of the ALU is shared byt he two cores, alternating by clock cycle. Philipp
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-12 21:39 +0300 |
| Message-ID | <66q1sd9b3vvic0jfc14ei1g1ua97iqpksj@4ax.com> |
| In reply to | #28188 |
On Fri, 12 Oct 2018 10:18:56 +0200, Philipp Klaus Krause <pkk@spth.de> wrote: >Am 10.10.2018 um 03:05 schrieb Clifford Heath: >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >> >> >> OTP, no SPI, UART or I²C, but still... >> >> Clifford Heath > >They even make dual-core variants (the part where the first digit in the >part number is '2'). It seems program counter, stack pointer, flag >register and accumulator are per-core, while the rest, including the ALU >is shared. In particular, the I/O registers are also shared, which means >some multiplier registers would also be - but currently all variants >with integrated multiplier are single-core. >Use of the ALU is shared byt he two cores, alternating by clock cycle. > >Philipp Interesting, that would make it easy to run a multitasking RTOS (foreground/background) monitor, which might justify the use of some reentrant library routines :-). But in reality, the available memory (ROM/RAM) is so small so that you could easily manage this with static memory allocations.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-11-08 13:53 +0100 |
| Message-ID | <ps1bks$eaj$1@solani.org> |
| In reply to | #28191 |
Am 12.10.18 um 20:39 schrieb upsidedown@downunder.com: > On Fri, 12 Oct 2018 10:18:56 +0200, Philipp Klaus Krause <pkk@spth.de> > wrote: > >> Am 10.10.2018 um 03:05 schrieb Clifford Heath: >>> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >>> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >>> >>> >>> OTP, no SPI, UART or I²C, but still... >>> >>> Clifford Heath >> >> They even make dual-core variants (the part where the first digit in the >> part number is '2'). It seems program counter, stack pointer, flag >> register and accumulator are per-core, while the rest, including the ALU >> is shared. In particular, the I/O registers are also shared, which means >> some multiplier registers would also be - but currently all variants >> with integrated multiplier are single-core. >> Use of the ALU is shared byt he two cores, alternating by clock cycle. >> >> Philipp > > > Interesting, that would make it easy to run a multitasking RTOS > (foreground/background) monitor, which might justify the use of some > reentrant library routines :-). But in reality, the available memory > (ROM/RAM) is so small so that you could easily manage this with static > memory allocations. > > But static memory allocation would require one copy of each function per thread. And the linker would have to analyze the call graph to always call the correct function for each thread. Function pointers get complicated. Unfortunately, reentrancy becomes even harder with hardware-multithreading: TO access the stack, one has to construct a pointer to the stack location in a memory location. That memory location (as any pseudo-registers) is then shared among all running instances of the function. So it needs to be protected (e.g. with a spinlock), making access even more inefficient. And that spinlock will cause issues with interrupts (a solution might be to heavily restrict interrupt routines, essentially allowing not much more than setting some global variables). The there is the trade-off of using one such memory location per function vs. per program (the latter reducing memroy usage, but resulting in less paralellism). The pseudo-registers one would want to use are not so much a problem for interrupt routines (they would just need saving and thus increase interrupt overhead a bit), but for hardware parallelism. Essentially all access to them would again have to be protected by a spinlock. All these problems could have relatively easily been avoided by providing an efficient stack-pointer-relative addressing mode. Having a few general-purpose or index registers would have somewhat helped as well. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2018-11-08 15:08 +0200 |
| Message-ID | <ps1cg8$u6v$1@dont-email.me> |
| In reply to | #28325 |
On 8.11.18 14:53, Philipp Klaus Krause wrote: > Am 12.10.18 um 20:39 schrieb upsidedown@downunder.com: >> On Fri, 12 Oct 2018 10:18:56 +0200, Philipp Klaus Krause <pkk@spth.de> >> wrote: >> >>> Am 10.10.2018 um 03:05 schrieb Clifford Heath: >>>> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >>>> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >>>> >>>> >>>> OTP, no SPI, UART or I²C, but still... >>>> >>>> Clifford Heath >>> >>> They even make dual-core variants (the part where the first digit in the >>> part number is '2'). It seems program counter, stack pointer, flag >>> register and accumulator are per-core, while the rest, including the ALU >>> is shared. In particular, the I/O registers are also shared, which means >>> some multiplier registers would also be - but currently all variants >>> with integrated multiplier are single-core. >>> Use of the ALU is shared byt he two cores, alternating by clock cycle. >>> >>> Philipp >> >> >> Interesting, that would make it easy to run a multitasking RTOS >> (foreground/background) monitor, which might justify the use of some >> reentrant library routines :-). But in reality, the available memory >> (ROM/RAM) is so small so that you could easily manage this with static >> memory allocations. >> >> > > But static memory allocation would require one copy of each function per > thread. And the linker would have to analyze the call graph to always > call the correct function for each thread. Function pointers get > complicated. > > Unfortunately, reentrancy becomes even harder with > hardware-multithreading: TO access the stack, one has to construct a > pointer to the stack location in a memory location. That memory location > (as any pseudo-registers) is then shared among all running instances of > the function. So it needs to be protected (e.g. with a spinlock), making > access even more inefficient. And that spinlock will cause issues with > interrupts (a solution might be to heavily restrict interrupt routines, > essentially allowing not much more than setting some global variables). > > The there is the trade-off of using one such memory location per > function vs. per program (the latter reducing memroy usage, but > resulting in less paralellism). > > The pseudo-registers one would want to use are not so much a problem for > interrupt routines (they would just need saving and thus increase > interrupt overhead a bit), but for hardware parallelism. Essentially all > access to them would again have to be protected by a spinlock. > > All these problems could have relatively easily been avoided by > providing an efficient stack-pointer-relative addressing mode. Having a > few general-purpose or index registers would have somewhat helped as well. > > Philipp And you'll end up with a low-end Cortex ... -- -TV
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-11-08 14:34 +0100 |
| Message-ID | <ps1e1k$fo9$1@solani.org> |
| In reply to | #28326 |
Am 08.11.18 um 14:08 schrieb Tauno Voipio: > > > And you'll end up with a low-end Cortex ... > A low-end Cortex would still be far heavier than a Padauk variant with an sp-relative adressing mode or a few registers added. I think a more multithreading-friendly variant of the Padauk would even still be simpler than an STM8. But one could surely create a nice STM8-like (with a few STM8 weaknesses fixed) processor with hardware multihreading. Philipp
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-11-08 21:52 +0200 |
| Message-ID | <gr29udt5koa6bu0t5vu9bu8qntsktah8ns@4ax.com> |
| In reply to | #28325 |
On Thu, 8 Nov 2018 13:53:48 +0100, Philipp Klaus Krause <pkk@spth.de> wrote: >Am 12.10.18 um 20:39 schrieb upsidedown@downunder.com: >> On Fri, 12 Oct 2018 10:18:56 +0200, Philipp Klaus Krause <pkk@spth.de> >> wrote: >> >>> Am 10.10.2018 um 03:05 schrieb Clifford Heath: >>>> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >>>> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >>>> >>>> >>>> OTP, no SPI, UART or I²C, but still... >>>> >>>> Clifford Heath >>> >>> They even make dual-core variants (the part where the first digit in the >>> part number is '2'). It seems program counter, stack pointer, flag >>> register and accumulator are per-core, while the rest, including the ALU >>> is shared. In particular, the I/O registers are also shared, which means >>> some multiplier registers would also be - but currently all variants >>> with integrated multiplier are single-core. >>> Use of the ALU is shared byt he two cores, alternating by clock cycle. >>> >>> Philipp >> >> >> Interesting, that would make it easy to run a multitasking RTOS >> (foreground/background) monitor, which might justify the use of some >> reentrant library routines :-). But in reality, the available memory >> (ROM/RAM) is so small so that you could easily manage this with static >> memory allocations. >> >> > >But static memory allocation would require one copy of each function per >thread. For a foreground/background monitor, the worst case would be two copies of static data, if both threads use the same rubroutine. >And the linker would have to analyze the call graph to always >call the correct function for each thread. Linker for such small target ? With such small processor, just track any dependencies manually. >Function pointers get complicated. Do you really insist of using function pointer with such small targets? > >Unfortunately, reentrancy becomes even harder with >hardware-multithreading: With two hardware threads, you would need at most two copies of static data. >TO access the stack, one has to construct a >pointer to the stack location in a memory location. Why would you want to access the stack ? The stack is usable for handling return addresses, but I guess that a hardware thread must have its own return address stack pointer. In fact many minicomputers from the 1960's did not even have a stack at all. The calling program just stored the return address in the first word of the subroutine and the at the end o the subroutine, performed an indirect jump through the first word of the subroutine to return to the calling program. Of course, this is not re-entrant and in those days one did not have to worry about multiple CPUs accessing the same routines:-). BTW, who needs a program counter (PC), many microprograms run without a PC, with the next instruction address stored at the end of the long instruction word :-) >That memory location >(as any pseudo-registers) is then shared among all running instances of >the function. So it needs to be protected (e.g. with a spinlock), making >access even more inefficient. And that spinlock will cause issues with >interrupts (a solution might be to heavily restrict interrupt routines, >essentially allowing not much more than setting some global variables). Disabling all interrupts for the duration of some critical operations is often enough, but of course, the number of instructions executed during interrupt disabled should be minimized. In MACRO-11 assembler, the standard practice was to start the comment field with a semicolon, when task switching was disabled with two semicolons and when interrupt disabled with three semicolons, it was visually easy to detect when interrupts were disabled and not mess too much with such code sections. > >The there is the trade-off of using one such memory location per >function vs. per program (the latter reducing memroy usage, but >resulting in less paralellism). > >The pseudo-registers one would want to use are not so much a problem for >interrupt routines (they would just need saving and thus increase >interrupt overhead a bit), but for hardware parallelism. Essentially all >access to them would again have to be protected by a spinlock. > >All these problems could have relatively easily been avoided by >providing an efficient stack-pointer-relative addressing mode. Having a >few general-purpose or index registers would have somewhat helped as well. > >Philipp
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-11-08 21:56 +0100 |
| Message-ID | <ps27tg$2t6$1@solani.org> |
| In reply to | #28328 |
Am 08.11.18 um 20:52 schrieb upsidedown@downunder.com: >> >> But static memory allocation would require one copy of each function per >> thread. > > For a foreground/background monitor, the worst case would be two > copies of static data, if both threads use the same rubroutine. > >> And the linker would have to analyze the call graph to always >> call the correct function for each thread. > > Linker for such small target ? Of course. The support routines the compiler uses reside in some library, the linker links them in if necessary. Also, the larger variants are not that small, with up to 256 B of RAM and 8 KB of ROM. One might want to e.g. have one .c file for handling I²", one for the soft UART, etc. > > With such small processor, just track any dependencies manually. See above. > >> Function pointers get complicated. > > Do you really insist of using function pointer with such small > targets? > I want to have C, function pointers are part of it. >> >> Unfortunately, reentrancy becomes even harder with >> hardware-multithreading: > > With two hardware threads, you would need at most two copies of static > data. Padauk still makes one chip with 8 hardware threads (and it looks to me as if there were more in the past, though they are not currently listed on their website, one can find them e.g. in their IDE). > >> TO access the stack, one has to construct a >> pointer to the stack location in a memory location. > > Why would you want to access the stack ? For reentrency, so I can use one function implementation for all threads. It would also be useful to dynamically assign threads to hardware threads (so no thread is tied to specific hardware, and some OS schedules them). > > The stack is usable for handling return addresses, but I guess that a > hardware thread must have its own return address stack pointer. Each hardware thread has its flag register (4 bits) accumulator (8 bits), pc (12 bits) and stack pointer (8 bits). > >> That memory location >> (as any pseudo-registers) is then shared among all running instances of >> the function. So it needs to be protected (e.g. with a spinlock), making >> access even more inefficient. And that spinlock will cause issues with >> interrupts (a solution might be to heavily restrict interrupt routines, >> essentially allowing not much more than setting some global variables). > > Disabling all interrupts for the duration of some critical operations > is often enough, but of course, the number of instructions executed > during interrupt disabled should be minimized. Disabling interrupts any time a spinlock is held or a thread is wating for one might be too much, especially if there are many threads, so the spinlock is held often. Philipp
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-11-09 00:35 +0200 |
| Message-ID | <6fd9ud17d205sjmjiaipot98khra7jak7m@4ax.com> |
| In reply to | #28329 |
On Thu, 8 Nov 2018 21:56:16 +0100, Philipp Klaus Krause <pkk@spth.de> wrote: >Am 08.11.18 um 20:52 schrieb upsidedown@downunder.com: >>> >>> But static memory allocation would require one copy of each function per >>> thread. >> >> For a foreground/background monitor, the worst case would be two >> copies of static data, if both threads use the same rubroutine. >> >>> And the linker would have to analyze the call graph to always >>> call the correct function for each thread. >> >> Linker for such small target ? > >Of course. The support routines the compiler uses reside in some >library, the linker links them in if necessary. Also, the larger >variants are not that small, with up to 256 B of RAM and 8 KB of ROM. >One might want to e.g. have one .c file for handling I²", one for the >soft UART, etc. A linker is required, if the libraries are (for copyright reasons) delivered as binary object code only. However, if the library are delivered as source files and the compiler/assembler has even a rudimentary #include mechanism, just include those library files you need. With a include or macro processor with parameter passing, just invoke same include file or macro twice with different parameters for different static variable instances. Of course, linkers are also needed, if very primitive compilation machines are used, such as floppy based Intellecs or Exorcisers. It could take a day to compile a large program all the way from sources, with multiple floppy changes to get the final absolute file to a single floppy, ready to be burnt into EPROMS for an additional hour or two. In such environment compiling, linking and burning only the source file changed would speed up program development a lot. When using a modern PC for compilation, there are no such issues.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-11-09 09:00 +0100 |
| Message-ID | <ps3er9$p81$1@solani.org> |
| In reply to | #28330 |
Am 08.11.18 um 23:35 schrieb upsidedown@downunder.com: >>>> And the linker would have to analyze the call graph to always >>>> call the correct function for each thread. >>> >>> Linker for such small target ? >> >> Of course. The support routines the compiler uses reside in some >> library, the linker links them in if necessary. Also, the larger >> variants are not that small, with up to 256 B of RAM and 8 KB of ROM. >> One might want to e.g. have one .c file for handling I²", one for the >> soft UART, etc. > > A linker is required, if the libraries are (for copyright reasons) > delivered as binary object code only. > > However, if the library are delivered as source files and the > compiler/assembler has even a rudimentary #include mechanism, just > include those library files you need. With a include or macro > processor with parameter passing, just invoke same include file or > macro twice with different parameters for different static variable > instances. > > Of course, linkers are also needed, if very primitive compilation > machines are used, such as floppy based Intellecs or Exorcisers. It > could take a day to compile a large program all the way from sources, > with multiple floppy changes to get the final absolute file to a > single floppy, ready to be burnt into EPROMS for an additional hour or > two. In such environment compiling, linking and burning only the > source file changed would speed up program development a lot. > > When using a modern PC for compilation, there are no such issues. > Separate compilation and then linking is the normal thing to, and a common workflow for small devices. This is e.g. how most people use SDCC, a mainstream free compiler targeting various 8-bit architectures. That doesn't mean it is the only way (and since SDCC does not have link-time optimization it might not be the optimal way either). But it is something people use and expect to work reasonably well. So for anyone designing an architecture it would be wise to not put too many obstacles into that workflow. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-15 14:19 +0200 |
| Message-ID | <pq20k7$hmp$1@solani.org> |
| In reply to | #28188 |
Am 12.10.2018 um 10:18 schrieb Philipp Klaus Krause: > > They even make dual-core variants […] And there is the MCS11, with 8 cores. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Tim <cpldcpu+usenet@gmail.com> |
|---|---|
| Date | 2018-10-14 01:46 +0200 |
| Message-ID | <ppu04t$kp3$1@dont-email.me> |
| In reply to | #28176 |
On 10/10/2018 03:05 AM, Clifford Heath wrote: > <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > This is quite curious. I wonder - Has anyone actually received the devices they ordered? The cheaper variants seem to be sold out. - Any success in setting up a programmer?
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2018-10-14 10:55 +0100 |
| Message-ID | <mPc*Dsm8w@news.chiark.greenend.org.uk> |
| In reply to | #28212 |
Tim <cpldcpu+usenet@gmail.com> wrote: > This is quite curious. I wonder > > - Has anyone actually received the devices they ordered? The cheaper > variants seem to be sold out. I think they've sold out since they went viral. EEVblog did a video showing 550 in stock - that's only $16 worth of parts, not hard to imagine they've been bought up. The other option is they're some kind of EOL part and 3c is the 'reduced to clear' price - which they have done, very successfully. Theo
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-24 15:57 +0200 |
| Message-ID | <pqptp4$g0s$1@solani.org> |
| In reply to | #28220 |
Am 14.10.2018 um 11:55 schrieb Theo: > Tim <cpldcpu+usenet@gmail.com> wrote: >> This is quite curious. I wonder >> >> - Has anyone actually received the devices they ordered? The cheaper >> variants seem to be sold out. > > I think they've sold out since they went viral. EEVblog did a video showing > 550 in stock - that's only $16 worth of parts, not hard to imagine they've > been bought up. > > The other option is they're some kind of EOL part and 3c is the 'reduced to > clear' price - which they have done, very successfully. > > Theo > They're back in stock, though the price rose by 21% to 0.046$. Also, LCSC seems to now be stocking more Padauk parts, including more dual-core devices. Unfortunately, the programmer seems to be out of stock, and they have neither the flash nor the DIP variants. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-15 14:35 +0200 |
| Message-ID | <pq21i6$ibl$1@solani.org> |
| In reply to | #28176 |
Am 10.10.2018 um 03:05 schrieb Clifford Heath: > <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > > OTP, no SPI, UART or I²C, but still... > > Clifford Heath If you are willing to pay 0.04$, you can get twice the RAM and program memory (not OTP for this one): https://detail.1688.com/offer/562502806054.html Philipp
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web