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 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2018-10-10 12:05 +1100 |
| Subject | $0.03 microcontroller |
| Message-ID | <nfcvD.142609$MN2.62078@fx02.iad> |
<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
[toc] | [next] | [standalone]
| From | lasselangwadtchristensen@gmail.com |
|---|---|
| Date | 2018-10-10 16:12 -0700 |
| Message-ID | <c896738a-0095-4c6f-a06c-3cf64d93cbbc@googlegroups.com> |
| In reply to | #28176 |
onsdag den 10. oktober 2018 kl. 03.05.27 UTC+2 skrev 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 https://youtu.be/VYhAGnsnO7w
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-10 17:51 -0700 |
| Message-ID | <9efeecbc-f434-4b1e-b477-9c28a00003eb@googlegroups.com> |
| In reply to | #28176 |
On Tuesday, October 9, 2018 at 9:05:27 PM UTC-4, 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 Interesting. They have some very off-brand FPGA type devices as well at very low prices, but they still don't do me any favors with the packages. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | lasselangwadtchristensen@gmail.com |
|---|---|
| Date | 2018-10-10 18:56 -0700 |
| Message-ID | <69764c19-5417-4d5d-97cb-01c780749833@googlegroups.com> |
| In reply to | #28178 |
torsdag den 11. oktober 2018 kl. 02.51.17 UTC+2 skrev gnuarm.del...@gmail.com: > On Tuesday, October 9, 2018 at 9:05:27 PM UTC-4, 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 > > Interesting. They have some very off-brand FPGA type devices as well at very low prices, but they still don't do me any favors with the packages. > they also do PCBs jlcpcb.com and I've heard they also have a dirt cheap assembly service as long as you only use their list of components, though it seems it is so far only available in China
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2018-10-10 19:29 -0700 |
| Message-ID | <874ldtp66e.fsf@nightsong.com> |
| In reply to | #28176 |
Clifford Heath <no.spam@please.net> writes: > <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... That is impressive! Seems to be an 8-bit RISC with no registers, just an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, enough for plenty of MCU things. Didn't check if it has an ADC or PWM. I like that it's in a 6-pin SOT23 package since there aren't many other MCUs that small.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-11 11:39 +0300 |
| Message-ID | <tl1urdtvs2rr7pqkab7o0rgdk7kecok7fs@4ax.com> |
| In reply to | #28180 |
On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >Clifford Heath <no.spam@please.net> writes: >> <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... > >That is impressive! Seems to be an 8-bit RISC with no registers, just >an accumulator, a cute concept. There is a lot of operations that will update memory locations, so why would you need a lot of CPU registers. >1K of program OTP and 64 bytes of ram, 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented assembly program listing. >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. At least the 8 pin version has both a PWM as well as a comparator, so making an ADC wouldn't be too hard. >I like that it's in a 6-pin SOT23 package since there aren't many other >MCUs that small.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2018-10-11 16:08 -0700 |
| Message-ID | <87in28nktr.fsf@nightsong.com> |
| In reply to | #28181 |
upsidedown@downunder.com writes: > There is a lot of operations that will update memory locations, so why > would you need a lot of CPU registers. Being able to (say) add register to register saves traffic through the accumulator and therefore instructions. > 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented > assembly program listing. It would be nice to have a C compiler, and registers help with that. > At least the 8 pin version has both a PWM as well as a comparator, so > making an ADC wouldn't be too hard. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-12 08:50 +0200 |
| Message-ID | <pppg8a$q0u$1@solani.org> |
| In reply to | #28184 |
Am 12.10.2018 um 01:08 schrieb Paul Rubin: > upsidedown@downunder.com writes: >> There is a lot of operations that will update memory locations, so why >> would you need a lot of CPU registers. > > Being able to (say) add register to register saves traffic through the > accumulator and therefore instructions. > >> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented >> assembly program listing. > > It would be nice to have a C compiler, and registers help with that. > Looking at the instruction set, it should be possible to make a backend for this in SDCC; the architecture looks more C-friendly than the existing pic14 and pic16 backends. But it surely isn't as nice as stm8 or z80. reentrant functions will be inefficent: No registers, and no sp-relative adressing mode. On would want to reserve a few memory locations as pseudo-registers to help with that, but that only goes so far. Philipp
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-12 09:44 +0200 |
| Message-ID | <pppjcf$k13$1@dont-email.me> |
| In reply to | #28186 |
On 12/10/18 08:50, Philipp Klaus Krause wrote: > Am 12.10.2018 um 01:08 schrieb Paul Rubin: >> upsidedown@downunder.com writes: >>> There is a lot of operations that will update memory locations, so why >>> would you need a lot of CPU registers. >> >> Being able to (say) add register to register saves traffic through the >> accumulator and therefore instructions. >> >>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented >>> assembly program listing. >> >> It would be nice to have a C compiler, and registers help with that. >> > > Looking at the instruction set, it should be possible to make a backend > for this in SDCC; the architecture looks more C-friendly than the > existing pic14 and pic16 backends. But it surely isn't as nice as stm8 > or z80. > reentrant functions will be inefficent: No registers, and no sp-relative > adressing mode. On would want to reserve a few memory locations as > pseudo-registers to help with that, but that only goes so far. > It looks like the lowest 16 memory addresses could be considered pseudo-registers - they are the ones that can be used for direct memory access rather than needing indirect access. And I don't think inefficient reentrant functions would be much of a worry on a device with so little code space! Some of the examples in the datasheet were given in C - that implies that there already is a C compiler for the device. Has anyone tried the IDE?
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-12 21:30 +0300 |
| Message-ID | <kro1sdh5sm1kaq11l38bqpdv0v959ac248@4ax.com> |
| In reply to | #28187 |
On Fri, 12 Oct 2018 09:44:15 +0200, David Brown <david.brown@hesbynett.no> wrote: >On 12/10/18 08:50, Philipp Klaus Krause wrote: >> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>> upsidedown@downunder.com writes: >>>> There is a lot of operations that will update memory locations, so why >>>> would you need a lot of CPU registers. >>> >>> Being able to (say) add register to register saves traffic through the >>> accumulator and therefore instructions. >>> >>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented >>>> assembly program listing. >>> >>> It would be nice to have a C compiler, and registers help with that. >>> >> >> Looking at the instruction set, it should be possible to make a backend >> for this in SDCC; the architecture looks more C-friendly than the >> existing pic14 and pic16 backends. But it surely isn't as nice as stm8 >> or z80. >> reentrant functions will be inefficent: No registers, and no sp-relative >> adressing mode. On would want to reserve a few memory locations as >> pseudo-registers to help with that, but that only goes so far. >> > >It looks like the lowest 16 memory addresses could be considered >pseudo-registers - they are the ones that can be used for direct memory >access rather than needing indirect access. > >And I don't think inefficient reentrant functions would be much of a >worry on a device with so little code space! The real issue would be the small RAM size. With such small ROM/RAM sizes, who needs reentrant functions ? Possibly only if you think that every problem must be solved by recursion :-). Reentrancy is nice, when writing run time library (RTL) routines that might be called from different contexts, but who in their right mind would call RTL routines from the ISR ? OK, some might put an RTOS into that processor, but even in that case, the RTOS might consist only of a simple foreground/background monitor, so unlikely need reentran routines. If you insist of using "C", just declare all variables as static uint8_t (and a few static uint16_t) so no reentrant code is generated. However, you could as well use some old 8 bitter languages such as PL/M-80. > >Some of the examples in the datasheet were given in C - that implies >that there already is a C compiler for the device. Has anyone tried the >IDE? >
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-12 22:06 +0200 |
| Message-ID | <ppqura$qgk$1@solani.org> |
| In reply to | #28190 |
Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: > > The real issue would be the small RAM size. Devices with this architecture go up to 256 B of RAM (but they then cost a few cent more). Philipp
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-12 23:45 +0300 |
| Message-ID | <2g12sdt0r0qqss1dcuk5cju1e41cka8bsn@4ax.com> |
| In reply to | #28192 |
On Fri, 12 Oct 2018 22:06:02 +0200, Philipp Klaus Krause <pkk@spth.de> wrote: >Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >> >> The real issue would be the small RAM size. > >Devices with this architecture go up to 256 B of RAM (but they then cost >a few cent more). > >Philipp Did you find the binary encoding of various instruction formats, i.e how many bits allocated to the operation code and how many for the address field ? My initial guess was that the instruction word is simple 8 bit opcode + 8 bit address, but the bit and word address limits for the smaller models would suggest that for some op-codes, the op-code field might be wider than 8 bits and address fields narrower than 8 bits (e.g. bit and word addressing).
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-13 21:47 +0200 |
| Message-ID | <ppti56$j0p$1@solani.org> |
| In reply to | #28193 |
Am 12.10.2018 um 22:45 schrieb upsidedown@downunder.com: > On Fri, 12 Oct 2018 22:06:02 +0200, Philipp Klaus Krause <pkk@spth.de> > wrote: > >> Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >>> >>> The real issue would be the small RAM size. >> >> Devices with this architecture go up to 256 B of RAM (but they then cost >> a few cent more). >> >> Philipp > > Did you find the binary encoding of various instruction formats, i.e > how many bits allocated to the operation code and how many for the > address field ? > > My initial guess was that the instruction word is simple 8 bit opcode > + 8 bit address, but the bit and word address limits for the smaller > models would suggest that for some op-codes, the op-code field might > be wider than 8 bits and address fields narrower than 8 bits (e.g. bit > and word addressing). > People have tried before (https://www.mikrocontroller.net/topic/449689, https://stackoverflow.com/questions/49842256/reverse-engineer-assembler-which-probably-encrypts-code). Apparently, even with access to the tools it is not obvious. However, a Chinese manual contains these examples: 5E0A MOV A BB1 1B21 COMP A #0x21 2040 T0SN CF 5C0B MOV BB2 A C028 GOTO 0x28 0030 WDRESET 1F00 MOV A #0x0 0082 MOV SP A Philipp
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-14 11:58 +0300 |
| Message-ID | <68u5sdlpd7bf01pog5ov8nvmvvi02s811b@4ax.com> |
| In reply to | #28209 |
On Sat, 13 Oct 2018 21:47:48 +0200, Philipp Klaus Krause <pkk@spth.de>
wrote:
>Am 12.10.2018 um 22:45 schrieb upsidedown@downunder.com:
>> On Fri, 12 Oct 2018 22:06:02 +0200, Philipp Klaus Krause <pkk@spth.de>
>> wrote:
>>
>>> Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com:
>>>>
>>>> The real issue would be the small RAM size.
>>>
>>> Devices with this architecture go up to 256 B of RAM (but they then cost
>>> a few cent more).
>>>
>>> Philipp
>>
>> Did you find the binary encoding of various instruction formats, i.e
>> how many bits allocated to the operation code and how many for the
>> address field ?
>>
>> My initial guess was that the instruction word is simple 8 bit opcode
>> + 8 bit address, but the bit and word address limits for the smaller
>> models would suggest that for some op-codes, the op-code field might
>> be wider than 8 bits and address fields narrower than 8 bits (e.g. bit
>> and word addressing).
>>
>
>People have tried before (https://www.mikrocontroller.net/topic/449689,
>https://stackoverflow.com/questions/49842256/reverse-engineer-assembler-which-probably-encrypts-code).
>Apparently, even with access to the tools it is not obvious.
>
>However, a Chinese manual contains these examples:
>
>5E0A MOV A BB1
>1B21 COMP A #0x21
>2040 T0SN CF
>5C0B MOV BB2 A
>C028 GOTO 0x28
>0030 WDRESET
>1F00 MOV A #0x0
>0082 MOV SP A
>
>Philipp
Interesting, this at least confirms that the instruction word is 16
bits. In a Harvard architecture, the word length could have been
13-17 bits, with some dirty encodings in 113 bit case., but a cleaner
encoding with 14-17 bit instruction words.
Assuming one would like to make an encoding for exactly 1024 code
words and 64 byte data memory, a tighter encoding would be possible.
Of course a manufacturer with small and larger processors, would make
sense to use the same encoding for all processors, which is slightly
inefficient for smaller models.
Anyway 1 kW/64 byes case, the following code points would be required:
2048 = 2 x 1024 call, goto
1792 = 7 x 256 Immediate data (8 bit)
2304 = 36 x 64 M-referense (6 bit)
1024 = 8 x 128 Bit ref (M and IO 3+4 bits
others
This might barely fit into 13 bits, with some nasty encoding.
Limiting M-refeence to 4 bits (0-15), but you still can't fit into 12
bit instruction length.
So with 16 bit word length, I do not understand why word reference is
limited to 4-5 bits.The bit address limit makes more sense, so that it
would not consume 4096 code points.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-15 08:14 +0200 |
| Message-ID | <pq1b7v$335$1@solani.org> |
| In reply to | #28219 |
Am 14.10.2018 um 10:58 schrieb upsidedown@downunder.com: > > Interesting, this at least confirms that the instruction word is 16 > bits. In a Harvard architecture, the word length could have been > 13-17 bits, with some dirty encodings in 113 bit case., but a cleaner > encoding with 14-17 bit instruction words. > > Assuming one would like to make an encoding for exactly 1024 code > words and 64 byte data memory, a tighter encoding would be possible. > Of course a manufacturer with small and larger processors, would make > sense to use the same encoding for all processors, which is slightly > inefficient for smaller models. Indeed Padauk makes variants with up to 256 B of RAM. > > Anyway 1 kW/64 byes case, the following code points would be required: > > 2048 = 2 x 1024 call, goto > 1792 = 7 x 256 Immediate data (8 bit) > 2304 = 36 x 64 M-referense (6 bit) > 1024 = 8 x 128 Bit ref (M and IO 3+4 bits > others > > This might barely fit into 13 bits, with some nasty encoding. > > Limiting M-refeence to 4 bits (0-15), but you still can't fit into 12 > bit instruction length. > > So with 16 bit word length, I do not understand why word reference is > limited to 4-5 bits.The bit address limit makes more sense, so that it > would not consume 4096 code points. > Maybe the M-reference limit only applies to the bit manipulation instructions? The line in the manual explains M.n, there is no seprate line for M; maybe they only documented the restrictions, with M then referring to the full 8-bit range outside of bit manipulation instructions? Philipp
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-11-11 09:27 +0100 |
| Message-ID | <ps8p59$crl$1@solani.org> |
| In reply to | #28193 |
Am 12.10.18 um 22:45 schrieb upsidedown@downunder.com: > On Fri, 12 Oct 2018 22:06:02 +0200, Philipp Klaus Krause <pkk@spth.de> > wrote: > >> Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >>> >>> The real issue would be the small RAM size. >> >> Devices with this architecture go up to 256 B of RAM (but they then cost >> a few cent more). >> >> Philipp > > Did you find the binary encoding of various instruction formats, i.e > how many bits allocated to the operation code and how many for the > address field ? > > My initial guess was that the instruction word is simple 8 bit opcode > + 8 bit address, but the bit and word address limits for the smaller > models would suggest that for some op-codes, the op-code field might > be wider than 8 bits and address fields narrower than 8 bits (e.g. bit > and word addressing). > It is more complicated. Apparently the encoding changed from a 16-bit instruction word used by older types (https://www.mikrocontroller.net/topic/461002#5616813) to a 14-bit instruction word used by newer types (https://www.mikrocontroller.net/topic/461002#5616603). Padauk also dropped and added various instructions at some points (e.g. ldtabh, ldtabl, mul, pushw, popw). Philipp
[toc] | [prev] | [next] | [standalone]
| From | Klaus Kragelund <klauskvik@hotmail.com> |
|---|---|
| Date | 2018-12-26 02:23 -0800 |
| Message-ID | <ae38dbfd-3dfe-4555-8fd1-f05f0b551d56@googlegroups.com> |
| In reply to | #28332 |
A STM8 or other 8 bit device can be had for about 15 cents in volume, 8 kB flash Dev of a 1 bit device with NRE and low volume since you will be the only customer will be much more Cheers Klaus
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-15 10:44 +0200 |
| Message-ID | <pq1k0o$8qn$1@solani.org> |
| In reply to | #28190 |
Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: > > With such small ROM/RAM sizes, who needs reentrant functions ? Everyone. With an efficent stack-pointer-relative addresing mode, you put all local varibles on the stack and only need as much RAM as the local variables along the longest path in the call tree. If your local variables are all static, the local variables of two functions that never get called at the same time still both takespace in RAM at the same time. Compilers can sometimes overly local variables on non-reentrant functions as an optimization, but that will only work for some cases; often it would require link-timeoptimization, which is not that common in compilers for small µCs. Example: main() calls f() and g(); both f() and g() call h(). All four functions are in different translation units, f() and g() both use a lot of local variables, while main() and h() use little. Without link-time optimization, the compiler will use about as much RAM as f() and g() together, when the local variables are static. When they are put on the stack, it will only need as much RAM as either f() or g(). Philipp
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2018-10-15 07:29 -0700 |
| Message-ID | <87y3azl1w0.fsf@nightsong.com> |
| In reply to | #28228 |
Philipp Klaus Krause <pkk@spth.de> writes: > Compilers can sometimes overly local variables on non-reentrant > functions as an optimization, but that will only work for some cases; > often it would require link-timeoptimization, which is not that common > in compilers for small µCs. Normally you'd use whole-program optimization, I thought. I don't know if SDCC supports that, but GCC does, as do the more serious commercial embedded compilers.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-16 09:19 +0200 |
| Message-ID | <pq43eh$te8$1@solani.org> |
| In reply to | #28236 |
Am 15.10.2018 um 16:29 schrieb Paul Rubin: > Philipp Klaus Krause <pkk@spth.de> writes: >> Compilers can sometimes overly local variables on non-reentrant >> functions as an optimization, but that will only work for some cases; >> often it would require link-timeoptimization, which is not that common >> in compilers for small µCs. > > Normally you'd use whole-program optimization, I thought. I don't know > if SDCC supports that, but GCC does, as do the more serious commercial > embedded compilers. > Does GCC support any of these very simple µC architectures? I thought anyhting supported by GCC tends to have rather powerful insturction sets and plenty of registers aynway, so functions could be made reentrant by default without any problems resulting. While some link-time optimizations are commonly requested features for SDCC, currently none are supported. In SDCC, even inter-procedural optimizations within the same translation unit are not as powerful as they should be. Well, there always is a lot of work to do on SDCC, and there are only a few volunteers with time to work on it. So SDCC developers priorize (usually by personal preferences). Still, when looking at the big picture, SDCC is doing quite well compared to other compilers for the same architectures (see e.g. http://www.colecovision.eu/stm8/compilers.shtml - comparison from early 2018, around the time of the SDCC 3.7.0 release - current SDCC is 3.8.0). Philipp
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web