While in Rocklin, we met with Treehouse (layout), OnSemi, and pjv.
Pjv has been very interested in making a Prop1.5. After a lot of discussion, we all realized that what would be way better and simpler to make would be a Prop2-minus, with reduced cogs, RAM, and smart pins. It could sell for about 40% less. We actually figured out that we could make a whole family of Prop2 chips. I'll explain more about that later.
The meeting with Treehouse and OnSemi was also very positive. We feel very confident now about not just finishing Prop2, but making a whole family of four devices with two unique footprints, so you can upgrade or downgrade within ranges, without redesigning your PCB. Imagine being able to choose among Prop2's in a 1x to 3x price range.
While in Rocklin, we met with Treehouse (layout), OnSemi, and pjv.
Pjv has been very interested in making a Prop1.5. After a lot of discussion, we all realized that what would be way better and simpler to make would be a Prop2-minus, with reduced cogs, RAM, and smart pins. It could sell for about 40% less. We actually figured out that we could make a whole family of Prop2 chips. I'll explain more about that later.
The meeting with Treehouse and OnSemi was also very positive. We feel very confident now about not just finishing Prop2, but making a whole family of four devices with two unique footprints, so you can upgrade or downgrade within ranges, without redesigning your PCB. Imagine being able to choose among Prop2's in a 1x to 3x price range.
Who ever doubted it?! The big question on a Prop2 shrink is, how low power will it be able to go to?
That reminds me. OnSemi said that they now have some ultra-low leakage transistors available in the ONC18 process that we are using. For us to use them would just involve switching to that logic and RAM library for synthesis. Our full-custom portion is just fine, as is. It's the core that could save a lot.
Just did some quick full speed USB mouse testing...
Good news and bad news. Can get mouse to respond, but only about 50% of the time.
Looks like interpacket delay is too big (again).
Looks like waiting for EOP flag now puts about 8 or so bit cycles between packets.
This is just a hair too much.
That may need some adjusting by Chip, if possible.
Just did some quick full speed USB mouse testing...
Good news and bad news. Can get mouse to respond, but only about 50% of the time.
Looks like interpacket delay is too big (again).
..
Do you have other simple devices you can try ?
I'm unsure what effect the NCO generated 12M will have on devices.
I think most parts lock using the 1ms frame information.
Interesting to see if waitx works ?
Never mind, I'm just too tired to be doing this...
Still, this sentence in the docs has me confused right now:
These DP/DM electrical designations can actually be switched by swapping low-speed and full-speed modes, due to USB’s mirrored line signalling. <-- typo here (one l in signaling)?
I don't think swapping between low and high speed changes DP/DM designations.
Think only J and K definitions change...
But, like I said, I'm tired right now...
Guess there are less than 4 instructions between FS USB cycles, think that's my issue now...
Might need two cogs at 80 MHz clock...
I think I've decided that FS USB works, but my code is way too slow...
...
If it works 50% of the time, how does that deliver ?
Is it exactly every second one fails, or is there some more random pattern, - do two adjacent messages ever work ?
If the code does work 50% of the time, that sounds rather closer than 'way too slow' ?
The NCO is / (6+2/3) to get 12MHz from 80, so will do /7/7/6, which has some jitter that could just be enough ?
Actually, it now works every time, when starting from the beginning.
Before, I was just repeating a setup request over and over, which probably got it confused because I wasn't asking for data afterwards...
Actually, it now works every time, when starting from the beginning.
Before, I was just repeating a setup request over and over, which probably got it confused because I wasn't asking for data afterwards...
Sounds great. It was sounding close...
So that code flow differs LS to FS ?
If you port back the fixed FS flow to LS, does LS work too (ie any common ground ?)
Wish there were an easier way to switch code from port A to port B...
Is there a way to just say DIR # and have the compiler decide if it's A or B?
We had port address redirecting in Prop2-Hot. We also had pin-level commands that affected OUT and DIR bits simultaneously. The tough thing about those is that the data forwarding becomes double since OUT and DIR were both affected.
Wish there were an easier way to switch code from port A to port B...
Is there a way to just say DIR # and have the compiler decide if it's A or B?
We had port address redirecting in Prop2-Hot. We also had pin-level commands that affected OUT and DIR bits simultaneously. The tough thing about those is that the data forwarding becomes double since OUT and DIR were both affected.
Comments
I just added some flops, but I won't be here to see the compile results.
So, I don't think any changes are necessary.
Is that tested at FS, or just LS USB ?
Are the traces between A9 and headers the same length?
I'll have to try my wireless mouse again and see if it works at full speed...
Yes, that would be a good test. At 12MHz there's no concern for trace length, of course.
Pjv has been very interested in making a Prop1.5. After a lot of discussion, we all realized that what would be way better and simpler to make would be a Prop2-minus, with reduced cogs, RAM, and smart pins. It could sell for about 40% less. We actually figured out that we could make a whole family of Prop2 chips. I'll explain more about that later.
The meeting with Treehouse and OnSemi was also very positive. We feel very confident now about not just finishing Prop2, but making a whole family of four devices with two unique footprints, so you can upgrade or downgrade within ranges, without redesigning your PCB. Imagine being able to choose among Prop2's in a 1x to 3x price range.
Wow, that's quite an advance on a Road Map there
Drool!
Can't wait.....
That reminds me. OnSemi said that they now have some ultra-low leakage transistors available in the ONC18 process that we are using. For us to use them would just involve switching to that logic and RAM library for synthesis. Our full-custom portion is just fine, as is. It's the core that could save a lot.
Good news and bad news. Can get mouse to respond, but only about 50% of the time.
Looks like interpacket delay is too big (again).
Looks like waiting for EOP flag now puts about 8 or so bit cycles between packets.
This is just a hair too much.
That may need some adjusting by Chip, if possible.
Have to try using waitx instead...
I'm unsure what effect the NCO generated 12M will have on devices.
I think most parts lock using the 1ms frame information.
Interesting to see if waitx works ?
Have to figure out how many usb cycles per P2 instruction...
Waitx didn't seem to help although did reduce spacing. Still get ack on 50% of time...
Guess it doesn't like being told the same thing over and over again...
Did you check it does not do the same on a PC USB link ?
Still, this sentence in the docs has me confused right now:
These DP/DM electrical designations can actually be switched by swapping low-speed and full-speed modes, due to USB’s mirrored line signalling. <-- typo here (one l in signaling)?
I don't think swapping between low and high speed changes DP/DM designations.
Think only J and K definitions change...
But, like I said, I'm tired right now...
Guess there are less than 4 instructions between FS USB cycles, think that's my issue now...
Might need two cogs at 80 MHz clock...
Main issue is turn around time between my request for data and the mouse's reply.
I spent a lot of time rolling the code into subroutines.
Would have to unroll the code to make it work full speed...
Might have to come back to this later...
If it works 50% of the time, how does that deliver ?
Is it exactly every second one fails, or is there some more random pattern, - do two adjacent messages ever work ?
If the code does work 50% of the time, that sounds rather closer than 'way too slow' ?
The NCO is / (6+2/3) to get 12MHz from 80, so will do /7/7/6, which has some jitter that could just be enough ?
Before, I was just repeating a setup request over and over, which probably got it confused because I wasn't asking for data afterwards...
So that code flow differs LS to FS ?
If you port back the fixed FS flow to LS, does LS work too (ie any common ground ?)
This important FS USB milestone, probably should go into the USB testing thread too ?
Is there a way to just say DIR # and have the compiler decide if it's A or B?
We had port address redirecting in Prop2-Hot. We also had pin-level commands that affected OUT and DIR bits simultaneously. The tough thing about those is that the data forwarding becomes double since OUT and DIR were both affected.
We had port address redirecting in Prop2-Hot. We also had pin-level commands that affected OUT and DIR bits simultaneously. The tough thing about those is that the data forwarding becomes double since OUT and DIR were both affected.