Mark Borgerson <mborgerson@comcast.net> writes: [...]> > That brings back terrible memories of the first programs I wrote in C > for a 2KB Flash 8051 variant. I still shudder when I think of all the > different pointer types!Try the 8048 in assembler - IIRC the program counter wrapped around at 256 byte page boundaries. Or something. So you had to manually shuffle all the subroutines around, with some judicious NOPS to space things how you wanted them. -- John Devereux
Really tiny microcontrollers
Started by ●February 25, 2013
Reply by ●February 27, 20132013-02-27
Reply by ●February 27, 20132013-02-27
In article <87lia9agls.fsf@devereux.me.uk>, john@devereux.me.uk says...> > Mark Borgerson <mborgerson@comcast.net> writes: > > [...] > > > > > That brings back terrible memories of the first programs I wrote in C > > for a 2KB Flash 8051 variant. I still shudder when I think of all the > > different pointer types! > > Try the 8048 in assembler - IIRC the program counter wrapped around at > 256 byte page boundaries. Or something. So you had to manually shuffle > all the subroutines around, with some judicious NOPS to space things how > you wanted them.Probably just as bad as the RCA CDP1802. IIRC, no stack and no subroutine call instruction. Mark Borgerson
Reply by ●February 27, 20132013-02-27
Ben Bradley <ben_u_bradley@etcmail.com> wrote: >>http://www.smtinspection.com/Mantis-Microscope/ > You can see under a BGA with that??? No, but I can see how a BGA is moving when I weld it. That is enought for a prototype. And it is possible to view the solderballs at the outer side of the BGA. Olaf
Reply by ●February 27, 20132013-02-27
On Wed, 27 Feb 2013 10:23:51 +0100, "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> wrote:>Op Tue, 26 Feb 2013 18:41:02 +0100 schreef Jon Kirwan ><jonk@infinitefactors.org>: >> On Tue, 26 Feb 2013 14:57:32 +0100, "Boudewijn Dijkstra" >> <sp4mtr4p.boudewijn@indes.com> wrote: >>> Op Tue, 26 Feb 2013 12:46:30 +0100 schreef Arlet Ottens >>> <usenet+5@c-scape.nl>: >>>> On 02/26/2013 11:49 AM, Boudewijn Dijkstra wrote: >>>> [...] >> >>> If you have 4K RAM, then a linked list is not a natural solution. ;) >>> <snip> >> >> [My] method does NOT use memory pointers as data >> elements but instead uses 1 byte ram as an index into the >> "array" to achieve this. > >I am familiar with this technique but I didn't know that people would call >this "linked list" as there no conceptual linking going on. I would call >this something like indirect indexing.There is no good reason NOT to call it a linked list. In every important semantic way it is a linked list. It's just an implementation detail how that is handled. I would intentionally NOT give it a different name, unless it were important in communcating the distinct nature of the implementation to an audience. Then I'd probably add an adjective to it to clarify.>> [...] It allows either singly or doubly linked lists, >> so you can shave off a byte for each thread and the head/tail >> of each queue. > >I may be misunderstanding something here, but I would think that you >always have a doubly linked list because you can traverse the array of >indices in two directions.There is a need for saving ram, in ram-starved systems. Every byte counts then. I use a #if to modify code so that it works either way. I use a #define to indicate which type of list is used. The semantics are identical, either way. But more code space (and time) is required when using singly-linked lists. But if the ram limitations are perverse (as they are in 128 and 256 byte ram chips, for example), then the price is worth it. The O/S is designed to operate either way. It's a compile time option which way it goes. Traversing the lists in both directions isn't needed in the O/S. It helps, of course. But it's not necessary. Inserting a process at the end, for example, would require walking the entire list in a singly-linked system, without ad-hoc mods to address that detail. That's time. But that's not impossible. Jon
Reply by ●February 27, 20132013-02-27
On Tue, 26 Feb 2013 07:39:08 +0100, Arlet Ottens wrote:> On 02/25/2013 09:37 PM, Tim Wescott wrote: > >> The problem with that package is that the board technology required to >> use it, much less soldering the thing down, is well outside of what I'm >> used to. I can handle 0.5mm-pitch leaded parts, but that thing is a >> bit much (or perhaps a bit not-much, since it's so teeny). >> >> Someone please chime in here, but it looks like that package pretty >> much requires a multi-layer board with microvias -- yes? Can anyone >> point to an applications note on how to actually make a board for that >> part and stick it down? >> >> > If your application doesn't need access to the 4 balls in the center, > you don't need any vias at all. There are 12 balls on the outside that > are easy to reach (0.5 mm pitch) > > In addition you can choose between the LPC1102 and the LPC1104. They are > much alike, but have different pinouts, so if you need an external > crystal, you should take the LPC1104 because the crystal pin is on the > outside. If you plan to use the internal oscillator you can use the > LPC1102, which has the crystal input on the inner ring, and leave it > unconnected. > > If you really need all 16 I/Os, you need micro vias, but a double sided > board should work fine. Of course, if you really care about making > really small designs, I doubt you'll find much better alternatives.The vendor that I use for board fab doesn't support microvias on double- sided boards -- I think they don't want to try drilling teeny holes in such thick material. I am still curious about how one would get the signal out. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●February 27, 20132013-02-27
On 2/27/2013 10:47 AM, Mark Borgerson wrote:> In article <87lia9agls.fsf@devereux.me.uk>, john@devereux.me.uk says... >> >> Mark Borgerson <mborgerson@comcast.net> writes: >> >>> >>> That brings back terrible memories of the first programs I wrote in C >>> for a 2KB Flash 8051 variant. I still shudder when I think of all the >>> different pointer types! >> >> Try the 8048 in assembler - IIRC the program counter wrapped around at >> 256 byte page boundaries. Or something. So you had to manually shuffle >> all the subroutines around, with some judicious NOPS to space things how >> you wanted them. > > Probably just as bad as the RCA CDP1802. IIRC, no stack and no > subroutine call instruction.No problem :) The subroutine just has to know all return locations. As there are not many states in the program, most of it could be hardcoded. It is going to be very safe and reliable. BTW, I had to write programs for i8080A without any RAM at all. Vladimir Vassilevsky DSP and Mixed Signal Designs www.abvolt.com
Reply by ●February 27, 20132013-02-27
Mark Borgerson wrote:> In article <87lia9agls.fsf@devereux.me.uk>, john@devereux.me.uk says... >> >> Mark Borgerson <mborgerson@comcast.net> writes: >> >> [...] >> >>> >>> That brings back terrible memories of the first programs I wrote in C >>> for a 2KB Flash 8051 variant. I still shudder when I think of all the >>> different pointer types! >> >> Try the 8048 in assembler - IIRC the program counter wrapped around at >> 256 byte page boundaries. Or something. So you had to manually shuffle >> all the subroutines around, with some judicious NOPS to space things how >> you wanted them. > > Probably just as bad as the RCA CDP1802. IIRC, no stack and no > subroutine call instruction. > > Mark Borgerson > >That's not *bad*, it just more or less forces you to use state machines and keep exhaustive comments. -- Les Cargill
Reply by ●February 27, 20132013-02-27
On Wed, 27 Feb 2013 08:47:25 -0800, Mark Borgerson wrote:> In article <87lia9agls.fsf@devereux.me.uk>, john@devereux.me.uk says... >> >> Mark Borgerson <mborgerson@comcast.net> writes: >> >> [...] >> >> >> > That brings back terrible memories of the first programs I wrote in C >> > for a 2KB Flash 8051 variant. I still shudder when I think of all >> > the different pointer types! >> >> Try the 8048 in assembler - IIRC the program counter wrapped around at >> 256 byte page boundaries. Or something. So you had to manually shuffle >> all the subroutines around, with some judicious NOPS to space things >> how you wanted them. > > Probably just as bad as the RCA CDP1802. IIRC, no stack and no > subroutine call instruction.The CDP1802 had all the bits and pieces to implement a stack and both call and return functions -- it just didn't give it to you in one spot (kinda like a RISC machine, except that the CDP1802 never had an instruction set). The manual included recommended assembly macros for call and return. IIRC you ended up using one GP register for a stack pointer, one for the regular program counter, and one for the program counter during the call and return. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●February 28, 20132013-02-28
Op Wed, 27 Feb 2013 19:10:34 +0100 schreef Jon Kirwan <jonk@infinitefactors.org>:> On Wed, 27 Feb 2013 10:23:51 +0100, "Boudewijn Dijkstra" > <sp4mtr4p.boudewijn@indes.com> wrote: >> Op Tue, 26 Feb 2013 18:41:02 +0100 schreef Jon Kirwan >> <jonk@infinitefactors.org>: >>> On Tue, 26 Feb 2013 14:57:32 +0100, "Boudewijn Dijkstra" >>> <sp4mtr4p.boudewijn@indes.com> wrote: >>>> Op Tue, 26 Feb 2013 12:46:30 +0100 schreef Arlet Ottens >>>> <usenet+5@c-scape.nl>: >>>>> On 02/26/2013 11:49 AM, Boudewijn Dijkstra wrote: >>>>> [...] >>> >>>> If you have 4K RAM, then a linked list is not a natural solution. ;) >>>> <snip> >>> >>> [My] method does NOT use memory pointers as data >>> elements but instead uses 1 byte ram as an index into the >>> "array" to achieve this. >> >> I am familiar with this technique but I didn't know that people would >> call this "linked list" as there no conceptual linking going on. I >> would call this something like indirect indexing. > > There is no good reason NOT to call it a linked list. In > every important semantic way it is a linked list. It's just > an implementation detail how that is handled. I would > intentionally NOT give it a different name, unless it were > important in communcating the distinct nature of the > implementation to an audience. Then I'd probably add an > adjective to it to clarify.My apologies, I misread "your method" to be distinct from true linked lists by having a separate array of indices that describes the element order. In hindsight I don't know how I could have misread it as it is described clear as can be... -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
Reply by ●February 28, 20132013-02-28
On Thu, 28 Feb 2013 10:27:22 +0100, "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> wrote:>Op Wed, 27 Feb 2013 19:10:34 +0100 schreef Jon Kirwan ><jonk@infinitefactors.org>: >> On Wed, 27 Feb 2013 10:23:51 +0100, "Boudewijn Dijkstra" >> <sp4mtr4p.boudewijn@indes.com> wrote: >>> Op Tue, 26 Feb 2013 18:41:02 +0100 schreef Jon Kirwan >>> <jonk@infinitefactors.org>: >>>> On Tue, 26 Feb 2013 14:57:32 +0100, "Boudewijn Dijkstra" >>>> <sp4mtr4p.boudewijn@indes.com> wrote: >>>>> Op Tue, 26 Feb 2013 12:46:30 +0100 schreef Arlet Ottens >>>>> <usenet+5@c-scape.nl>: >>>>>> On 02/26/2013 11:49 AM, Boudewijn Dijkstra wrote: >>>>>> [...] >>>> >>>>> If you have 4K RAM, then a linked list is not a natural solution. ;) >>>>> <snip> >>>> >>>> [My] method does NOT use memory pointers as data >>>> elements but instead uses 1 byte ram as an index into the >>>> "array" to achieve this. >>> >>> I am familiar with this technique but I didn't know that people would >>> call this "linked list" as there no conceptual linking going on. I >>> would call this something like indirect indexing. >> >> There is no good reason NOT to call it a linked list. In >> every important semantic way it is a linked list. It's just >> an implementation detail how that is handled. I would >> intentionally NOT give it a different name, unless it were >> important in communcating the distinct nature of the >> implementation to an audience. Then I'd probably add an >> adjective to it to clarify. > >My apologies, I misread "your method" to be distinct from true linked >lists by having a separate array of indices that describes the element >order. In hindsight I don't know how I could have misread it as it is >described clear as can be...Just to be clear, one possible incarnation would look like this: qn qp qk Description ---- ---- ---- ---------------------------- | | | | | p[0] : | | | | | p[1] : | | | | | p[2] : ~ ~ ~ ~ ~ p[...] processes ~ ~ ~ ~ ~ p[...] : | | | | | p[PLIMIT-2] : | | | | | p[PLIMIT-1] : .... .... .... ---------------------------- | | | | | ready tail : | | | | na | ready head : .... .... .... -------------------- : | | | | | sleep tail : | | | ---- sleep head : .... .... -------------------- : | | | s[0] tail : | | | s[0] head : | | | s[1] tail queues | | | s[1] head : | | | s[2] tail : | | | s[2] head : ~ ~ ~ s[...] : ~ ~ ~ s[...] : | | | s[SLIMIT-2] tail : | | | s[SLIMIT-2] head : | | | s[SLIMIT-1] tail : | | | s[SLIMIT-1] head : ---- ---- ---------------------------- Where qn[] is a byte array of next indices, qp[] is a byte array of prev indices, qk is a key used for priorities or for the sleep queue delta time values (union.) (The semaphore queues don't require this.) Jon
