Shop OBEX P1 Docs P2 Docs Learn Events
A standard for shrinking MCU applications and offloading them to either the N76E003 or the EFM8UB3 — Parallax Forums

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

mikeologistmikeologist Posts: 337
edited 2017-12-13 01:50 in General Discussion
First, my thanks to @jmg for the suggestion of using the N76E003 MCU for a keypad controller.

This lead me to research the possibility which lead me to this video on youtube.
From there I found this page on the updated process in detail.

I love this concept and I was wondering if a paradigm like this exists for propeller?
Comments please, links, anything :smile: I'll do the reading.

Ideally it would be nice to stick to all parallax products, but the cheapest version of the stamp that I could find is just too expensive compared to the N76E003 MCU.

If this does not exist I will make the best first version of it that I'm capable of.

I propose that it is designed to work with SimpleIDE (C only) and that the two target technologies include the basic stamp, the SX28AC, the N76E003 MCU, and one more MCU in the 50 to 75 cent range that is faster than the N76E003 MCU. A simple programmer board compatible with all of the above should not be that complex, at least I don't think.
With this we could program 5 MCU with the same C code and libraries.

I believe a program like this might being some new interest in the propeller as it will allow for a C standard for designing and integrating peripherals yet unknown.
What do you all think?
Anyone interested in the final product, or in helping?

@kwinn @macca @heater I'd really value your opinions on this.
«13

Comments

  • Opinions:

    Forget the Basic Stamp. The only compiler for that is for Basic and the interpretive code definitions are proprietary to Parallax and have never been released to the public.

    Forget the SX28AC. It's at "end of life" meaning that once current stocks are used up, there will be no more made.

    If you want to work on this, fine, but the Propeller does a good job of handling peripherals like a keypad controller using a single cog leaving 7 more to do other work. Some projects might have I/O pin limitations or need all 8 cogs, but that's unusual. The pin limitations will effectively go away with the Prop 2 when that's available ... until someone comes up with a more complex project that uses them all. The Prop 2's signal handling abilities as well as its speed, power, and increased memory will bring new interest in both Propellers.

    The N76E003 is not special. There are all sorts of small, cheap microcontrollers with features suitable for something like a keypad controller.

    I don't think Parallax has any interest in supporting an effort that might draw business away from their products
  • jmgjmg Posts: 15,140
    ...
    I propose that it is designed to work with SimpleIDE (C only) and that the two target technologies include the basic stamp, the SX28AC, the N76E003 MCU, and one more MCU in the 50 to 75 cent range that is faster than the N76E003 MCU..

    One part I would nominate that comes just above that price range, at 88c/1k is the (new) Silabs EFM8UB3 - 40K Flash, 48MHz and USB included. This can displace the FT232R etc Bridge parts, with more smarts.

    www.silabs.com/documents/public/reference-manuals/efm8ub3-reference-manual.pdf

    Mike Green wrote: »
    The N76E003 is not special. There are all sorts of small, cheap microcontrollers with features suitable for something like a keypad controller.
    True, but not many have a generous 18k Flash and sub 30c.

    Mike Green wrote: »
    I don't think Parallax has any interest in supporting an effort that might draw business away from their products
    Also true, but these small MCU parts are more complementary, than competing.

    They are 8b vs 32b for the Prop, & low pin counts, and a part like the N76E003 competes more with glue-Logic (see other thread) and ADC's and simple peripherals.
    If you can craft code into a N76E003, that can make the Prop code go further. Prop1 has a hard 32k ceiling.

    A part like EFM8UB3 competes more with FT232R, and it could go into a product like FLiP, and add features (Free ADC?) and reduce price.

  • Mike Green wrote: »
    Opinions:

    Forget the Basic Stamp. The only compiler for that is for Basic and the interpretive code definitions are proprietary to Parallax and have never been released to the public.

    Forget the SX28AC. It's at "end of life" meaning that once current stocks are used up, there will be no more made.

    Done and done, makes complete sense.
    Mike Green wrote: »
    If you want to work on this, fine, but the Propeller does a good job of handling peripherals like a keypad controller using a single cog leaving 7 more to do other work. Some projects might have I/O pin limitations or need all 8 cogs, but that's unusual. The pin limitations will effectively go away with the Prop 2 when that's available ... until someone comes up with a more complex project that uses them all. The Prop 2's signal handling abilities as well as its speed, power, and increased memory will bring new interest in both Propellers.

    The N76E003 is not special. There are all sorts of small, cheap microcontrollers with features suitable for something like a keypad controller.

    I agree completely. That is a major part of the draw of the propeller. It's ability to allow for superior parallel operations all sharing the same pins and that's why I'm here. The suggestion of using a P2 instead is also a great one.
    I do have to say though that another major draw of the P1 is the price. I love that I can put one of these is a production product for less than $6. To that end this program would hopefully increase the abilities of the P1 while keeping the costs to practically nothing compared to a P2.
    As it happens I am making a non-FP, arbitrary precision math engine with a P1 that uses all 8 cogs:
    0) GUI, Hypervisor, peripherals
    1) Quad Parallel Math Core 0
    2) Application Flex Core 0
    3) Quad Parallel Math Core 1
    4) Video Stage 0 - preprocess and offloading to a secondary MPU
    5) Quad Parallel Math Core 2
    6) Application Flex Core 1
    7) Quad Parallel Math Core 3
    There is no room so far (I still have a lot of work) for excess functions and all but 5 pins used. This left me the option of engineering a keypad that uses 5 pins and provides a decoded read as quickly as possible. Here is the keypad thread.
    Making this happen with a single P1 is a major project goal.

    While the N76E003 is not unique, it is a good cheap solution. As this project passes through development I am certain many similar products will be reviewed for viability. That is an excellent point and I will add it to the growing list.
    Mike Green wrote: »
    I don't think Parallax has any interest in supporting an effort that might draw business away from their products

    I would love to keep it all parallax, but they don't make an MCU in this class. Which was a main reason I mentioned the SX28AC and the BASIC stamp. I hope the spirit of using a parallax tool (SimpleIDE) and the programmer being programmed for propeller compatibility, using Prop C and Prop libraries will gain the interest of Parallax.
    Parllax tools for making Parallax driven peripherals of use with Parallax MCUs.
    That's my hope anyway.

    Thanks for taking the time to hit all those points.
  • jmg wrote: »
    One part I would nominate that comes just above that price range, at 88c/1k is the (new) Silabs EFM8UB3 - 40K Flash, 48MHz and USB included. This can displace the FT232R etc Bridge parts, with more smarts.

    www.silabs.com/documents/public/reference-manuals/efm8ub3-reference-manual.pdf

    Wow, what a great part:
    "The EFM8 Universal Bee 3 or UB3 is a full speed USB 2.0 MCU with a large set of integrated peripherals. It reduces the BOM cost of USB system with integrated oscilator, dead battery support, low power modes, and more. The UB3 is an 8051 8-bit MCU with 40kB flash, 3kB of RAM, 12-bit ADC, 6 timers, configurable logic units, and many more peripherals." - From this page
    This is exactly what I was looking for. Super cheap and super capable. $1.11 retail means they are probably as cheap as $0.80 on a reel.
    That is right in line with the spirit of this idea :-D
    jmg wrote: »
    Mike Green wrote: »
    I don't think Parallax has any interest in supporting an effort that might draw business away from their products
    Also true, but these small MCU parts are more complementary, than competing.

    They are 8b vs 32b for the Prop, & low pin counts, and a part like the N76E003 competes more with glue-Logic (see other thread) and ADC's and simple peripherals.
    If you can craft code into a N76E003, that can make the Prop code go further. Prop1 has a hard 32k ceiling.

    A part like EFM8UB3 competes more with FT232R, and it could go into a product like FLiP, and add features (Free ADC?) and reduce price.

    I was hope that this project would come across that way.

    I appreciate your contributions, they will help.
  • kwinnkwinn Posts: 8,697
    I'm all in favor of a project like this with the N76E003 and EFM8UB3 as the target MCU’s. Was already considering the EFM8UB3 as a sensor concentrator/interface node for a Propeller project even though it was overkill for this project. Even the N76E003 has more than I need. Would be great to have one tool that handles the Propeller and these MCU’s.
  • kwinn wrote: »
    I'm all in favor of a project like this with the N76E003 and EFM8UB3 as the target MCU’s. Was already considering the EFM8UB3 as a sensor concentrator/interface node for a Propeller project even though it was overkill for this project. Even the N76E003 has more than I need. Would be great to have one tool that handles the Propeller and these MCU’s.

    Hypothetical: How fast could either of these MCUs be reprogrammed from a cog and restarted?
    Just imagining exceptionally dynamic and overly-complex peripherals as a way to push every possible capability of the new software.
    I was always the annoying student who pointed out all the edge cases. Ended up working out for me.
  • evanhevanh Posts: 15,126
    The Prop is an MCU. It may have 8 cores but that doesn't exclude it from the category.
  • mikeologistmikeologist Posts: 337
    edited 2017-12-13 02:13
    evanh wrote: »
    The Prop is an MCU. It may have 8 cores but that doesn't exclude it from the category.

    That is in fact the idea :smile:
    All three are MCUs that with some work can use common C programs and libraries.
    With the addition of some nice tools the user will be able to use the driver code that they currently have and make a programmable peripheral effectively freeing up valuable pins or even a cog in part or in whole.
    They can do all this without having to learn anything about the assembly required for either of the smaller MCUs. They can also do it all in C and in one tool.

    For right around $1
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-12-13 03:30
    A Propeller is eight 32-bit MCUs. At a single-piece price of $7.99, that comes out to less than a dollar per MCU. 'Pretty cheap, really, for an 80 MHz, 32-bit microcontroller.

    -Phil
  • A Propeller is eight 32-bit MCUs. At a single-piece price of $7.99, that comes out to less than a dollar per MCU. 'Pretty cheap, really, for an 80 MHz, 32-bit microcontroller.

    -Phil

    Quite true.
    2 counterpoints that I'd like to pose:
    What if a builder needs 9 cores on the cheap?
    Also the N76E003 is about $0.25 which blows the top off of the circuit that I've made for my keypad in price, ease of installation, and capabilities. I can't think of a cheaper way to run my keypad without making my interface cog do more work.

    I'm still going to make the decade counter based circuits though because I need more experience.

    I'm a long time programmer but newish to this level of hardware. If I've made a bad assumption please let me know; I'll listen.
  • jmgjmg Posts: 15,140
    Hypothetical: How fast could either of these MCUs be reprogrammed from a cog and restarted?
    Just imagining exceptionally dynamic and overly-complex peripherals as a way to push every possible capability of the new software.
    I was always the annoying student who pointed out all the edge cases. Ended up working out for me.

    That depends on what you program where.

    Assuming normal CODE in Flash, that does have a finite endurance to consider, of 100k typ on SiLabs and 100k min on N76E003

    I think Peter has mentioned he has a C2D programmer, for sending Prop -> Silabs firmware in Flash.

    Of course, both parts are large enough to run scripts/interpreters.

    There is a port of Basic52 to Silabs, here https://github.com/sittisaks/superbasic52 - that had a 8192 byte code footprint & user program sits in XRAM.

    Not sure how forth would run/fit ? :) - there is 768 bytes XRAM in N76E003 and 2048 bytes XRAM in EFM8UB3

    I've also looked at a SFR bridge approach, where you use the UART to access peripherals, allowing very flexible config, at moderate speeds.
    The firmware for this is very stable, as it just gives a conduit to the SFRs, the 'code' runs on the host.
    Well suited to ADC, PWM DACs, and general port IO
  • kwinnkwinn Posts: 8,697
    A Propeller is eight 32-bit MCUs. At a single-piece price of $7.99, that comes out to less than a dollar per MCU. 'Pretty cheap, really, for an 80 MHz, 32-bit microcontroller.

    -Phil

    Very true, but I can not place those individual cogs in different rooms or areas of a building like I can the $ub dollar mcu's, and they also include peripherals like adc's, comparators, uarts, etc. that reduce wiring costs by using a serial bus rather than point to point connections.
  • jmg wrote: »
    Hypothetical: How fast could either of these MCUs be reprogrammed from a cog and restarted?
    Just imagining exceptionally dynamic and overly-complex peripherals as a way to push every possible capability of the new software.
    I was always the annoying student who pointed out all the edge cases. Ended up working out for me.

    That depends on what you program where.

    Assuming normal CODE in Flash, that does have a finite endurance to consider, of 100k typ on SiLabs and 100k min on N76E003

    I think Peter has mentioned he has a C2D programmer, for sending Prop -> Silabs firmware in Flash.

    Of course, both parts are large enough to run scripts/interpreters.

    There is a port of Basic52 to Silabs, here https://github.com/sittisaks/superbasic52 - that had a 8192 byte code footprint & user program sits in XRAM.

    Not sure how forth would run/fit ? :) - there is 768 bytes XRAM in N76E003 and 2048 bytes XRAM in EFM8UB3

    I've also looked at a SFR bridge approach, where you use the UART to access peripherals, allowing very flexible config, at moderate speeds.
    The firmware for this is very stable, as it just gives a conduit to the SFRs, the 'code' runs on the host.
    Well suited to ADC, PWM DACs, and general port IO

    With a limited number of writes, the feature should probably be reserved for upgrades. I had not considered that.

    All I know of fourth is what I've read in the past few hours but as this takes off I really hope to work with Peter Jakacki to make sure that fourth benefits from this project and vice versa.
    For the beginning of the project I believe a pure C approach is the way to go.
    This will get it off the ground fastest, then we can use agile to adopt or adapt to the other standards such as fourth and possibly even spin.
  • jmgjmg Posts: 15,140
    jmg wrote: »
    Not sure how forth would run/fit ? :) - there is 768 bytes XRAM in N76E003 and 2048 bytes XRAM in EFM8UB3

    Google finds this
    https://github.com/jamesbowman/8051forth
    seems recent, 3 months ago updates.
    The original forth says 8K code and at least 1k XRAM - so OK for EFM8UB3, but maybe tight on N76E003 ?

  • jmg wrote: »
    jmg wrote: »
    Not sure how forth would run/fit ? :) - there is 768 bytes XRAM in N76E003 and 2048 bytes XRAM in EFM8UB3

    Google finds this
    https://github.com/jamesbowman/8051forth
    seems recent, 3 months ago updates.
    The original forth says 8K code and at least 1k XRAM - so OK for EFM8UB3, but maybe tight on N76E003 ?

    I wonder how much of camel fourth can be made modular. Would it be possible to break the kernel down a bit and let the user choose which options to install based on a parse of the fourth file on a PC? Thereby freeing up more program RAM and solidly enabling fourth on the N76E003.
  • Forth on an 8051 is a dog but the XMC1100 is a "cheap" 32-bit micro with 64k Flash and 16k RAM, 12-bit ADC, dual universal serial ports etc. There are other brands as well but the small package and decent memory make this part very attractive. I wouldn't worry at all about Flash endurance cycles, you will never ever wear them out by updating because even if you programmed it 10 times a day, day after day, month after month, it would be about 3 years before you hit that generous "minimum". In other words, never.

    With 16k RAM it is possible to download or work in RAM first and then if it checks out then you can program the Flash.
  • Forth on an 8051 is a dog but the XMC1100 is a "cheap" 32-bit micro with 64k Flash and 16k RAM, 12-bit ADC, dual universal serial ports etc. There are other brands as well but the small package and decent memory make this part very attractive.

    Dog meaning nonviable, don't bother? I can understand that. Fourth is a lot compare to these tiny MCUs.

    Perhaps we could add a library to make our tiny devices drivers in fourth?
    Prop fourth looks amazing. I'd like to be sure that my tiny project can create peripherals with which fourth users can easily interface.
  • "Dog" as in you can do it but why bother when you can have a full 32-bit CPU in a small package for around $1. The RAM is what makes it easier to develop with whereas the small 8-bit at a time CPUs usually have very small RAMs.

    Creating "drivers" in Forth is very easy and the "library" is just an extension of the Forth dictionary so that once I define PING I can then define DISTANCE which references PING and converts microseconds to millimeters.

    From the source code in Tachyon V4.7
    --- PING MODULE ---
    pub PING ( trig echo -- us )
    	--- setup WAITPxx mask
    	MASK 4 COG!
    	--- 10us trigger (dummy cycles)
    	DUP HIGH 10 us LOW
    	--- detect high period
    	WAITHI WAITLO
    	--- calculate high period
    	1 COG@ 2 COG@ -
    	--- convert cycles to us
    	CLKMHZ / /							
    	;
    
    --- return with the range in mm using trig pin and echo pin
    pub DISTANCE ( trig echo -- distance.mm )	PING 170145 1,000,000 */  ;
    

    So PING and DISTANCE are now words you can type into the terminal or build new words on. If I had the trigger on P4 and the echo on P1 I could type:
    4 1 DISTANCE PRINT
    
    and immediately have the distance printed on the terminal etc.

    BTW, Even though Tachyon is a version of "Forth" I tend to shy away from referring to it as "a Forth" due to the differences and also the fact that a lot of people have had exposure to a crippled Forth or one that was written as an programming exercise or a bloated and unworkable PC version. Tachyon is in its own class and it was designed to be specific enough for the Propeller and for actual industrial embedded applications rather than just playing.

  • Creating "drivers" in Forth is very easy and the "library" is just an extension of the Forth dictionary so that once I define PING I can then define DISTANCE which references PING and converts microseconds to millimeters.

    So PING and DISTANCE are now words you can type into the terminal or build new words on. If I had the trigger on P4 and the echo on P1 I could type:
    4 1 DISTANCE PRINT
    
    and immediately have the distance printed on the terminal etc.

    BTW, Even though Tachyon is a version of "Forth" I tend to shy away from referring to it as "a Forth" due to the differences and also the fact that a lot of people have had exposure to a crippled Forth or one that was written as an programming exercise or a bloated and unworkable PC version. Tachyon is in its own class and it was designed to be specific enough for the Propeller and for actual industrial embedded applications rather than just playing.

    That makes sense about not putting in the effort on that device at that price.
    It's good to know Tachyon users will be able to easily make drivers to use peripherals based on our tiny MCUs. I hope that promotes cross interest.

    I totally understand the distinction with Tachyon. I guess in this case a rose by any other name would not smell as sweet. May the Bard forgive me.
  • tonyp12tonyp12 Posts: 1,950
    edited 2017-12-13 17:23
    >A Propeller is eight 32-bit MCUs. At a single-piece price of $7.99, that comes out to less than a dollar per MCU. 'Pretty cheap, really, for an 80 MHz, 32-bit microcontroller.
    But needs 4 cycles per instruction, so that is 20MHz core, timer ticks is still 80MHz+ though.

    Prop/8 = 20MHz + 4K ram + 2K code "cache" , $1 Arm beats that and they come with 16K flash.
    But that the Prop have 8 of them in a single chip does have some value, if you can utilize it to your advantage.



  • tonyp12 wrote: »
    >A Propeller is eight 32-bit MCUs. At a single-piece price of $7.99, that comes out to less than a dollar per MCU. 'Pretty cheap, really, for an 80 MHz, 32-bit microcontroller.
    But needs 4 cycles per instruction, so that is 20MHz core, timer ticks is still 80MHz+ though.

    Prop/8 = 20MHz + 4K ram + 2K code "cache" , $1 Arm beats that and they come with 16K flash.
    But that the Prop have 8 of them in a single chip does have some value, if you can utilize it to your advantage.

    I agree, having them all in the same package can be a distinct advantage, if you're capable of utilizing it.
    The point of this project is to offload peripheral functions to allow users to fully use the Prop itself to focus solely on OS or program functions :-D

    I've got plans for every one of my 160 MIPS
  • @kwinn @macca @heater I'd really value your opinions on this.

    Wow, thank you for the consideration, I'm not sure how much of help I can be since my experience with other microcontrollers is very limited (mostly PICs for specific tasks).
    I agree, having them all in the same package can be a distinct advantage, if you're capable of utilizing it.
    The point of this project is to offload peripheral functions to allow users to fully use the Prop itself to focus solely on OS or program functions

    I'm not sure to understand what you are trying to do, off-loading to some other MCUs may or may not be of help because you still need to write the COG code to comunicate with that MCU so why don't integrate the funcion you need ? Of course you can have multiple additional parts connected to a bus like I2C to save COGs. Some clever coding may help to shrink code in a single COG, see for example the 4-port serial driver that uses 1 COG to drive 4 UARTs, maybe it is possible to combine SPI, I2C and UART in a single COG.

    Aside from that, if you want to maximize the code space available to users, the C compiler allows to store the COG driver code in the extended eeprom space (addresses from 0x8000 and up, above the space used by the Propeller) and with some tweaking of the linker scripts you can easily implement overlay code, stored in high-eeprom addresses and loaded into main hub memory as needed, this will virtually give you an unlimited code space (well, unlimited to the maximum number of 128k eeproms you can connect, a total of 512k if I'm not wrong). I wrote a post about that:
    http://forums.parallax.com/discussion/163970/overlay-code-with-gcc

    Hope this helps.
  • mikeologistmikeologist Posts: 337
    edited 2017-12-13 20:07
    macca wrote: »
    I'm not sure to understand what you are trying to do, off-loading to some other MCUs may or may not be of help because you still need to write the COG code to communicate with that MCU so why don't integrate the function you need ?

    An excellent point. In reply I will give you two uses where I see a gain:
    1) My keypad - I intend to make a keypad controller using the N76E003 that will allow for up to 64 keys. This controller will handle all the scanning. Only on a key-press event will the controller interrupt a cog and transmit a single byte on 4 wires in just a few cog clocks. The cog only needs to pay attention to the single interrupt pin normally. This should remove a great number of operations from the cog. More than an PIC this should do all the sentinel processing and decoding.

    2) A complex sensor grid - Imagine a sensor grid that charlieplexes a couple hundred sensors of many different types in many different locations. All this controlled by the EFM8UB3. When an event is perceived it involves computing several sensor values against each other before you have a program usable word. Upon calculating this word any of of a half dozen comms protocol can be used to send this tiny refined data to the cog by interrupt.

    This project is about offloading tasks so systems like Tachyon can use all 8 cogs.
    As @jmg also points out. This will work well for making glue logic with the same C code and tools that users are already used to.
    macca wrote: »
    Wow, thank you for the consideration, I'm not sure how much of help I can be since my experience with other microcontrollers is very limited (mostly PICs for specific tasks)

    I believe your grasp of bit flow between devices and your interest in Prop ASM will be invaluable to this project. I hope you'll follow this thread and contribute as you can :-D
  • jmgjmg Posts: 15,140
    ...
    1) My keypad - I intend to make a keypad controller using the N76E003 that will allow for up to 64 keys. This controller will handle all the scanning. Only on a key-press event will the controller interrupt a cog and transmit a single byte on 4 wires in just a few cog clocks. The cog only needs to pay attention to the single interrupt pin normally. This should remove a great number of operations from the cog. More than an PIC this should do all the sentinel processing and decoding.

    Yes, the key objective is to save code space, and time, and pins, in the Prop, allowing it to fit-more-in.

    Once you have a smarter logic, you do not need 4-wide read, and can probably read faster not on 4 wires.

    The ideal is least-code and least-time to read a keypad value, from the host side.

    Choices seem to be UART, or SPI (SPI being closest to Logic replacement )

    Looking more closely at the N76E003 data, it has a quite good SPI port, but I think in slave mode, it always consumes 4 pins.
    I'm guessing MOSI pin may be used as input, at any time, but /SS is also a chip-select, so cannot wiggle freely without disturbing SPI, so net cost is 3 pins.

    This makes SPI somewhat less attractive, so we look more at UART (1MBd possible, - 10℃ ~ +70℃ ± 1 %)

    The '003 does have this nifty feature on the UART

    UART0PX Serial port 0 pin exchange
    0 = Assign RXD to P0.7 and TXD to P0.6 by default.
    1 = Exchange RXD to P0.6 and TXD to P0.7

    That allows half-duplex interrogate-reply type ONE PIN Serial links to P1.
    It also has a Self Wake-up Timer (WKT), for very low power Check-then-sleep designs.

    An additional Data-Ready signal pin, would show if the '003 was waiting for keypress, or had data queued, and allows easy WKT use.

    If power is less an issue, then single pin poll can be used, and WKT skipped. Looks like 2.2mA IDLE (fast wake), vs 6uA WKT (30us wakeup)

    One byte send from Prop would trigger an echo, and the trigger pulse can be 1us low / 8us hi, thru to 8us low - easily generated by Prop.
    ie 8 simple pulse-width choices from P1, allows signal of 8 commands if needed, (LED, buzzer, PWM etc ?) if you want a smaller than UART-TX code block.
    Tachyon likely already has a half duplex TX-RX library, 1MBd capable.

    RX is simple poll-start-edge, then timed code, 80MHz P1 can easily poll 1us spacings. Would take 20us to poll-readback any valid key.


  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-13 23:05
    I think you've got the wrong idea as you are too focused on the way you have implemented your keyboard and now you want to interface it that way. There is absolutely no advantage in making it run fast and the keyboard can't "interrupt" the Prop either, there are no interrupts. In fact if you trying to make it as fast as possible for the sake of several key codes per second then you making matters worse and you are not taking a balanced view. You would have to tie a cog up simply to receive that data as soon as it was available. If you are going to tie up a cog then why bother with 5 wires?

    Now if you happen to transmit ASCII encoded keys serially on a single wire at a very slow baud rate of say 110 baud that would still give you 11 character per second with around 1/10 second response. Now since you are transmitting so slowly then you could easily sample that data at a very leisurely rate without tying up a whole cog.

    Alternatively the keyboard chip could transmit at a much higher baud rate but the Prop could hold the line low and when it is ready to poll the serial it could release the line with a pullup and so the keyboard chip can sense that or be interrupted and transmit a character or status byte at high speed. This is actually the best way of handling it in a general and flexible manner. So even Spin could interface to the keyboard and release the line, always receiving a byte of information, and Spin can do that reliably at 19.2k baud.

    btw, have you had a look at one of my videos where I communicate with a network of "sub-processors"?
  • I think you've got the wrong idea as you are too focused on the way you have implemented your keyboard and now you want to interface it that way. There is absolutely no advantage in making it run fast and the keyboard can't "interrupt" the Prop either, there are no interrupts. In fact if you trying to make it as fast as possible for the sake of several key codes per second then you making matters worse and you are not taking a balanced view. You would have to tie a cog up simply to receive that data as soon as it was available. If you are going to tie up a cog then why bother with 5 wires?

    You are absolutely correct.
    I have accepted the change from a 40xx, even though I'm going to finish that one to tie up the loose end. I will use the N76E003 but I will be using UART according to @jmg comment above. I agree I got stuck on the parallel 4 wire thing.
    I'm standing strong on the concept of this programming standard, I just need to be more flexible on using the existing comms protocols.
  • I did watch all the videos on your Tachyon page too.
    I am quite impressed with the speed.
  • jmgjmg Posts: 15,140
    ... There is absolutely no advantage in making it run fast....

    You are right wrt information passed, but there are cases where very fast read, gives better code.
    It means the time consumed by the software is much less, and multi-tasking design is needed less.
    ...Now if you happen to transmit ASCII encoded keys serially on a single wire at a very slow baud rate of say 110 baud that would still give you 11 character per second with around 1/10 second response. Now since you are transmitting so slowly then you could easily sample that data at a very leisurely rate without tying up a whole cog.

    Alternatively the keyboard chip could transmit at a much higher baud rate but the Prop could hold the line low and when it is ready to poll the serial it could release the line with a pullup and so the keyboard chip can sense that or be interrupted and transmit a character or status byte at high speed. This is actually the best way of handling it in a general and flexible manner. So even Spin could interface to the keyboard and release the line, always receiving a byte of information, and Spin can do that reliably at 19.2k baud.

    The UART0PX mentioned above, allows a smarter 'Prop-is-ready' polling scheme, on a single pin, at up to 1MBd.

    It is a good point about lower baud rates, as 1MBd is not needed (it just might be simpler to do / impact other code less).

    Checking the Baud range of the 2 uarts, finds this :

     Table 13-1. Serial Port 0 Mode Description
    10b Frame   Timer 1/Timer 3 overflow rate divided by 32 or 16
    11b frame   Timer 1/Timer 3 overflow rate divided by 32 or 16
    
     Table 13-2. Serial Port 1 Mode Description
    10b frame   Timer 3 overflow rate divided by 16
    11b frame   Timer 3 overflow rate divided by 16
    
    Timer1 : /1,/12 choice and 8b reload.
    Timer3 : Prescaler 2^T3PS[2..0] /1../128  16b reload.
    
    Highest Baud : 16M/16 = 1Mbd for T1,T3
    Slowest Baud : Timer 1 16M/12/256/16  = 325.52
    Slowest Baud : Timer 3 16M/128/65536/16 = 0.1192 
    Low practical example : 16M/9090/16  = 110.011Baud
    

    Fastest is 1MBd, for a 20us ENQ-Reply read-overhead, but they can also reach your 19200 and even that 110 baud, if a user wanted to.
    WAIT in Prop, allows almost any baud a user might want...

    The single in ENQ-Reply is also PC compatible, but very low baud rates are a little less PC compatible.
    eg I see my notes say the N76E003 Eval Board can go as low as 184 Baud, and CP2102N data says 300 baud is lowest.


  • I'm skim-reading this on a phone so following the nuances of the discussion is tricky but I am working on a range of intelligent peripherals that are based on a single model of a sub £1 chip. The inter - chip comms is going to be I2C.

    So I will have things like a keypad scanner, an lcd controller, a serial port controller.....
  • Oh, and if basic is your thing.... Micromite.
Sign In or Register to comment.