Hi John

Interesting we used Pic for a CAN to USB Bridge for a doctors laptop to get 
Data and and out of doctors tablet for an implantable heart pump.
TI 28335 DSP was master, TI DSP Piccolo ran the implant motor and we had a PIC 
doing some system house keeping. All 3 processors were connected on CAN bus 
sharing data.
Can stack wrote in house As was a simple scheduler on Master.
Redundant battery packs wore by grandpa on belt so Grandpa could go hunting 
with his failed heart.
CCS JTAG on two TI and PIC had JTAG I believe we added a Blue tooth module on 
PIC.
Fast reliable and Life critical imagine Grandpa waiting 18 seconds after a 
reboot for his left ventricle to pump🙈.

the long run this probably won't matter because it seems like the Beagle itself 
is on its death bed.

 Hunch. Edecuated guess? I feel a lack of mojo myself.




What is next the Dog 🐶 pound board on OpenRisc is my guess? 

On the positive side all TI IP work the same pretty much on DSP or Soc so at 
least low level knowledge isn't wasted it's transferable to all TI DSP and 
other Socs if the AM335x chip isn't marketed as much which I doubt.

I'm a big investor in NVDA and can't wonder how many Chip designer's are 
nervous about the ARM acquisition.

My interest are at low level SW  not Linux so I won't be migrating to any non 
ARM Soc no matter how much drum beating occurs. Hopefully they add JTAG.

Love TI chips started as a Motorola guy, transitioned to ARM not an Intel Fan.

IMX by NXP is interesting. Did one MIPS processor project. 

I remember working with a consultant on his first day at our stand up he 
bragged he was on his 50th job and he never met a microprocessor he didn't like 
LOL.

I told him wow nice story I wouldn't share that later.

Project was ESP32 he was fired after 90 days I didn't have a chance ask him if 
he still liked ESP32.

Nice cheap chip. the support in the beginning of that chips life was horrible .

Mostly open source Free RTOS community support. I own one somewhere.

Mark














Sent from Yahoo Mail on Android 
 
  On Mon, May 17, 2021 at 3:49 PM, John Dammeyer<[email protected]> wrote: 
  <!--#yiv6924789174 _filtered {} _filtered {}#yiv6924789174 #yiv6924789174 
p.yiv6924789174MsoNormal, #yiv6924789174 li.yiv6924789174MsoNormal, 
#yiv6924789174 div.yiv6924789174MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New 
Roman", "serif";}#yiv6924789174 a:link, #yiv6924789174 
span.yiv6924789174MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv6924789174 a:visited, #yiv6924789174 
span.yiv6924789174MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv6924789174 p 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:"Times New 
Roman", "serif";}#yiv6924789174 p.yiv6924789174MsoNoSpacing, #yiv6924789174 
li.yiv6924789174MsoNoSpacing, #yiv6924789174 div.yiv6924789174MsoNoSpacing 
{margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", 
"sans-serif";}#yiv6924789174 p.yiv6924789174Code, #yiv6924789174 
li.yiv6924789174Code, #yiv6924789174 div.yiv6924789174Code 
{margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;font-family:"Courier 
New";}#yiv6924789174 span.yiv6924789174EmailStyle19 {font-family:"Times New 
Roman", "serif";color:#1F497D;}#yiv6924789174 span.yiv6924789174SpellE 
{}#yiv6924789174 .yiv6924789174MsoChpDefault {font-size:10.0pt;} _filtered 
{}#yiv6924789174 div.yiv6924789174WordSection1 {}-->
A few years ago I did a project that needed high speed CAN message acquisition 
from power up.  The Raspberry PiZeroW took about 18 seconds to boot in its 
fastest incantation which meant 18 seconds of vehicle start up and running 
messages would be lost.

  

Eventually I used a PIC32 to do the power up data logging and dumped the data 
up to the PiZero acting as an SPI master while the PIC32 was the slave.  Since 
I needed a number of features that weren't on the PIC32 I used an Automotive 
Networking Board (ANB) which had a number of Click expansion sockets.  One was 
the mcp2542 CAN bus driver terminating in a DB-9 with standard CANopen CAN bus 
format.

  

https://www.mikroe.com/mcp2542-click

  

Since I was buying Click boards I picked up a cape for the BBB.

  

https://www.mikroe.com/beaglebone-mikrobus-cape

  

That was a few years ago.  Now I thought I'd use the cape and the mcp2542-click 
for testing CAN1 communications with the Beagle.  But there's a problem.  
Although the Click board worked properly on the ANB something wasn’t right with 
the Beagle installation.  A bit of tracking with the scope and the schematics 
has shown there's an error on the click board.  Or on the cape.  Although the 
board worked on the ANB jumpers directed the signals so I'm going to suggest 
the problem is with the Click board.

  

So:  What is the problem?  It derives from the ease of creating the TI 
processor silicon and putting the CAN1_TX signal on the same pin as the 
UART1_RX (GPIO14).  That makes a carrier board like the cape difficult to deal 
with because it's marked Tx on a pin that is Tx for UART but Rx for CAN.  The 
trouble is the mcp2542-click board also thinks that the Tx for Uart is the same 
as the Tx for CAN1.  It's not.

  

The MCP2542-Click also has the two HDR1 pins marking CAN_H and CAN_L reversed.  
The signals are correct on the DB-9.  Because the ANB motherboard (attached 
photo) has jumpers that can allocate what pins get what signal the best 
solution is to change the MCP2542-Click with some trace cuts and jumper wires.  

  

I've passed on this information to www.mikroe.com but just be aware this Click 
board will not work on the BBB cape.

  

The Logic Supply CBB-Serial Cape does not have problems and I've been able to 
use the socketCAN utilities with it on the 2018 OS.

https://www.onlogic.com/cbb-serial/

It's been discontinued along with the Logic Supply name as the above link shows.

  

In the long run this probably won't matter because it seems like the Beagle 
itself is on its death bed.

  

John Dammeyer

  

  

  

  
 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/007d01d74b5a%2441406cc0%24c3c14640%24%40autoartisans.com.
  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/269596564.779091.1621287777140%40mail.yahoo.com.

Reply via email to