A standard for shrinking MCU applications and offloading them to either the N76E003 or the EFM8UB3

13»

Comments

  • The problem I found with trying to do any kind of "universal" solution is that it is all very good and well if it were a chip available in DIP as well as SMD, preprogrammed, and available from most suppliers very cheap. Internally with my own designs I don't have any problems with designing my special peripheral micros onto a board and having programming pads/vias/headers to Flash them with etc.

    However I was very confused with your post because I think you are confused about this area of technology. I didn't know where to start to reply since the actual statements are incorrect or too open-ended.

    I agree that a cheap dip is needed. As this software comes to fruition I will try to have something simple produced as cheaply as possible.
    There's no doubt that I've made mistakes. No worries, I'm sure they'll come to light as I try to make these and inevitably fail here and there.
    jmg wrote: »
    I bought 10 of these to play around with. Part of my pile of tiny christmas presents that I bought for myself this year.

    Interesting little break-out board. Even has a 3v3 regulator, not mandatory on N76E003 as it runs just fine on USB-5V, but useful for Rasp-Pi or P1 testing where you want 3v3.

    Yup, ought to save me a bunch of time and allow me to keep projects assembled.
    I was also thinking of trying to emulate some of the 40xx logic ic. This is probably more of an academic curiosity but I think it will be informative. Would a 40xx that could change function be useful anywhere? (I know that last one's really open ended)

    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • jmg wrote: »
    I bought 10 of these to play around with. Part of my pile of tiny christmas presents that I bought for myself this year.

    Interesting little break-out board. Even has a 3v3 regulator, not mandatory on N76E003 as it runs just fine on USB-5V, but useful for Rasp-Pi or P1 testing where you want 3v3.


    I offered them $2.70 each for an order of 10, very reasonable.

    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • ... Would a 40xx that could change function be useful anywhere? (I know that last one's really open ended)

    This is already done, look at
    https://www.nexperia.com/products/logic/gates/configurable-gates/

    and further up the scale...

    http://www.silego.com/products/greenpak.html

    An 8051 can emulate almost any AND/OR/XOR combination, using the Boolean opcodes, but the speed of operation is a key metric when trying that.
    Software is always slower than hardware...

    That said, one MSI-Logic area where cheap MCUs can push into, is the 4060 Oscillator+Counter type devices.
    That 4060 is cheap, but has limited taps - no /2,/4,/8 and max of 2^14.
    The N76E003 lacks a Crystal Osc, but the N76E885 does have that.



  • jmg wrote: »
    ... Would a 40xx that could change function be useful anywhere? (I know that last one's really open ended)

    This is already done, look at
    https://www.nexperia.com/products/logic/gates/configurable-gates/

    and further up the scale...

    http://www.silego.com/products/greenpak.html

    An 8051 can emulate almost any AND/OR/XOR combination, using the Boolean opcodes, but the speed of operation is a key metric when trying that.
    Software is always slower than hardware...

    That said, one MSI-Logic area where cheap MCUs can push into, is the 4060 Oscillator+Counter type devices.
    That 4060 is cheap, but has limited taps - no /2,/4,/8 and max of 2^14.
    The N76E003 lacks a Crystal Osc, but the N76E885 does have that.

    That's looks like a neat project, too. The N76E885AT28 emulating a 4060+ could allow for a bigger counter, 2^22 if you allow for 4 control pins?
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • jmgjmg Posts: 10,760
    edited December 2017 Vote Up0Vote Down
    That's looks like a neat project, too. The N76E885AT28 emulating a 4060+ could allow for a bigger counter, 2^22 if you allow for 4 control pins?
    If you want more than one output counting pin, the 8051 does allow SFR INC, including Ports,
    so you could run a 2 line interrupt loop, from IDLE of
    TimerINT:
      INC P0
      RETI
    

    that would work for anything < ~500kHz fastest pin period, and give 8 binary toggling pins, & scope just like a counter.
    For outputs between 500kHz and fOsc, there is CLOEN & CKDIV, that puts fOsc / (2 * CKDIV) onto a pin. (/1,/2,/4,/6,../510)

    For single outputs, Timer0 and Timer1 can toggle pins T0,T1 on overflow, so could go as low as /(2^16*12*510)
    The N76E003 PWM has a Binary prescaler, and a 16b reload, and a Timer1 feed option, so I make that a hardware-divider limit of 12*510*2^16*2^16
    = quite large, over 2^44 and around 19 days period from 16MHz !

    For general sounder/beeper use, you could divide 16MHz CKDIV=10, for a > 522Hz independent T0,T1 toggle, set with 8 bit precision, or 16M with PWM 16b precision to 244Hz ~ 30ppm granularity
  • @jmg

    Looks like I'm getting great results with the CY62256N connected directly to the flip.
    200,000 random byte writes per second
    238,095 random byte reads per second
    1,159,420 sequential byte reads per second
    and that's without a controller for the address.
    What do you think of using a W78E052DFG as a controller?

    I followed the comments through the asm and as best as I can tell the timing results are correct. (Code attached)
    I'd like to know If I've made a mistake, would you mind taking a peek, please?

    The CY62256N RAM is capable of running a lot faster.
    Any feedback would be appreciated
    asm
    34K
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • jmgjmg Posts: 10,760
    What do you think of using a W78E052DFG as a controller?
    The w78e052d is reasonable, if a little long in the tooth, and not very fast. Better might be N76E616, if you can use TQFP48 package ?
    The N78 series have the slower core, than the N76, and no calibrated on-chip Osc.

    If you need many simple IO pins in one package, the N76E616 is a better choice.

    Nuvoton do have Bootloaders (they call ISP, found in Nuvoton 8051 ISP-ICP Programmer v7.15.zip), & PC-side EXE's, but the ISP code is factory pre-loaded only on some older parts.
    N76E616, N76E885 code is in the ZIP file, but I think not factory pre-loaded.

  • The N76E616AL48 definitely fits the bill. I just ordered a few and I already have a bunch of adapters on the way for various chips.
    Trickier, but maybe possible, would be N76E003+SPI_Flash, where code for i2c.24C256 emulation actually reads SPI flash, for much larger code support...
    is this a possibility to explore with the N76E616AL48? 1 or more 32MB SPI Flash and 4MB of 16-bit SRAM.
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • Made some tweaks to the code after reading a lot of old forums posts and I kicked up the speed a good bit on the lower end and a tiny bit on the top end:
    294,117 random byte writes per second, up 47%
    312,500 random byte reads per second, up 31%
    1,194,029 sequential byte reads per second, up 3%

    @jmg I found this old thread in which you were a significant contributor. It helped me refine this code :smile:
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • jmgjmg Posts: 10,760
    edited January 3 Vote Up0Vote Down
    The N76E616AL48 definitely fits the bill. I just ordered a few and I already have a bunch of adapters on the way for various chips.
    Trickier, but maybe possible, would be N76E003+SPI_Flash, where code for i2c.24C256 emulation actually reads SPI flash, for much larger code support...
    is this a possibility to explore with the N76E616AL48? 1 or more 32MB SPI Flash and 4MB of 16-bit SRAM.

    Yes, if you wanted to - however if this is just for experimenting, do not dismiss simply using a second P1 as the RAM controller.
    It has less IO than N76E616 (32 vs 46 max) but P1 has a 20MHz opcode rate, (per COG) and can move 8/16/32b at that speed.

    If you really want highest slave-memory speed, I'd use verilog and a Lattice FPGA (ICE40UP5K-SG48). (their QFN48 is the same lead pitch as the TQFP48 of N76E616)
    It would be interesting to see what that pairing can do...
  • jmg wrote: »
    If you really want highest slave-memory speed, I'd use verilog and a Lattice FPGA (ICE40UP5K-SG48). (their QFN48 is the same lead pitch as the TQFP48 of N76E616)
    It would be interesting to see what that pairing can do...

    I can't locate it in a QFN package. I'm not set up for BGA. I did find a development board for $66, not sure if it has enough I/O.
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • I also have some STM32F105RBT6 on hand that I could use as well.
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • jmgjmg Posts: 10,760
    jmg wrote: »
    ... and a Lattice FPGA (ICE40UP5K-SG48).

    I can't locate it in a QFN package...

    ? The SG48 is the QFN
    Digikey Stock

    Mouser show ICE40UP5K-SG48ITR 1,944 On Order, Estimated Ship Date 1,944 22-Jan-18
  • jmg wrote: »
    ? The SG48 is the QFN
    Digikey Stock

    Mouser show ICE40UP5K-SG48ITR 1,944 On Order, Estimated Ship Date 1,944 22-Jan-18

    Not sure how I messed up that search, but thanks :smile: I'll pick up a few this week.
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • mikeologistmikeologist Posts: 229
    edited January 4 Vote Up0Vote Down
    @jmg

    Is there a faster way to blink a pin once, arbitrarily?
     121:RAM_Test.c    ****   OUTA &= ~(1 << 8 );          // Lower WE to begin write sequence
     132              		.loc 1 121 0
     133 0100 0000BCA0 		mov	r7, OUTA
     134 0104 0001FC64 		andn	r7, #0x100
     135              	.LVL32
     136 0108 0000BCA0 		mov	OUTA, r7
     137              	.LVL33
     122:RAM_Test.c    ****   OUTA |= (1 << 8 );           // Raise WE to end write sequence
     138              		.loc 1 122 0
     139 010c 0000BCA0 		mov	r7, OUTA
     140 0110 0001FC68 		or	r7, #256
     141              	.LVL34
     142 0114 0000BCA0 		mov	OUTA, r7
     143              	.LVL35
    

    In some cases it will be off then right back on and in other cases there will be instructions in between the state changes.
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • Peter JakackiPeter Jakacki Posts: 6,776
    edited January 4 Vote Up0Vote Down
    OUTA is a register you know. No need to read a register into a register. You can XOR directly etc.
    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • jmgjmg Posts: 10,760
    Is there a faster way to blink a pin once, arbitrarily?
    In some cases it will be off then right back on and in other cases there will be instructions in between the state changes.

    If that is the highest level of compiler optimize, and it still generates 3 lines, you may need to go to in line ASM.

    See some comments & examples of in line asm here
    http://forums.parallax.com/discussion/162132/using-propgcc-and-asm

    You can use ANDN and OR, or simply XOR twice, as Peter alludes - just one line of assembler is needed to change the pin.
  • jmg wrote: »
    Is there a faster way to blink a pin once, arbitrarily?
    In some cases it will be off then right back on and in other cases there will be instructions in between the state changes.

    If that is the highest level of compiler optimize, and it still generates 3 lines, you may need to go to in line ASM.

    See some comments & examples of in line asm here
    http://forums.parallax.com/discussion/162132/using-propgcc-and-asm

    You can use ANDN and OR, or simply XOR twice, as Peter alludes - just one line of assembler is needed to change the pin.

    I figured there would be a single command. Thank you for the reading that will be very helpful.
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
  • jmg wrote: »
    If that is the highest level of compiler optimize, and it still generates 3 lines, you may need to go to in line ASM.

    See some comments & examples of in line asm here
    http://forums.parallax.com/discussion/162132/using-propgcc-and-asm

    You can use ANDN and OR, or simply XOR twice, as Peter alludes - just one line of assembler is needed to change the pin.
      __asm__ ( "xor	OUTA, #256\n\t"
                "xor	OUTA, #256\n\t"); // Lower and raise WE to commit
    
    What I failed to consider is that I'm in complete control of the pins. Coming down from higher level programming this something to which I'm adjusting.
    My old code made no assumption about the state of the pin and performed unnecessary steps. I will need to add a semaphore pin to ensure this continuity when I have multiple cogs accessing RAM.
    I've made the same mistake a few other times in my code as well. I will find them.
    Any com port in a storm.
    Floating point numbers will be our downfall; count on it.
    Imagine a world without hypothetical situations.
Sign In or Register to comment.