According to JH7110 Upstream Status | RVspace , CAN is stroken out with text “No hardware interface on the VF2 board”. I was hoping for it, because JH7110 product brief https://doc-en.rvspace.org/JH7110/PDF/JH7110_Product_Brief.pdf lists it as “Support 2 × Ethernet MAC 1000 Mbps, 2 × CAN2.0B”. It will be very hard to expose it, right?
I think you can expose it via GPIO, you would need to make an appropriate HAT/interface. But I think it can be done, electrically.
Drivers might be another matter, I also saw that entry. I think that seems fair enough in the plan for the VF2 board, I just hope it’s still on StarFive’s or another board developers radar for the future.
Edit: I always think of CAN uses in terms of industrial automation, but It’s almost ubiquitous in automotive applications too, and that’s a market the JH7* series is targeting. So assume we will get drivers
Yeah, will be waiting for it, or in case of great need, maybe restart my old kernel hacker experience to write my own.
There’s a board by Renesas with CANBus, but it’s like a C906 with one 1Ghz core or something small-ish - and expensive, by comparison, but it’s targeting CanBs out of the box as automotive is a primary market for them. (I think it’s something in the RZ/Five category, but this probably isn’t the appropriate forum for that anyway…)
I don’t know teh electronics of CanBus, but as with most parts of this class, there’s a giant I/O pin mux on the “front” of this and decide which physical pins are connected to which logical peripherals inside the chip. If there’s not a crazy phy required and you can swap it around like a SPI, Iw2, other logical bank, it’s probably there.
Time to go dig in the CPU data sheet to be sure the part can swap them to pins that are connected and then to whtever you can find that’s current to see if you can finish the thookup.
If you want to run linux on renesas rz/five, forget about this. It’s TCM ram isn’t controlled by MMU and this completely breaks specifiation.
I already got two Longan Nano’s to test CANBus on, just thought I could experiment with them also by using VF2. But not now, sigh.
I don’t do Canbus, but I do Nano. I don’t remember there being any particularly magical hardware interfacing on those or pins that were canbus only or whatever, were there? (It’s been a while…)Isn’t CAN more of a protocol than an electrical protocol?
Even if CAN isn’t a target market for V5R2, what’s to stop you from just wiring up the interface (Wikipedia makes it sound like AT WORST you need a couple of resistors - Nano certainly didn’t have anything exotic like dedicated PHYs or whatever)
The TRM at https://doc-en.rvspace.org/JH7110/PDF/JH7110_TRM_StarFive_Preliminary.pdf certanily makes it look like there are two CAN interfaces that are plumbed into the giant IO MUX that fronts this part and that they’re like I2C, SPI, and such that can be virtually pinned to any of many I/O pins.
Even if it’s out of scope for a general purpose SDK/Developer board like this, if you’re building something with Canbus, it’s probably worth a conversation with your FAE before you scrap your design. It sure looks like you can reconnect that bit engine to the GPIO pins just by remapping the front end. So while it may be out of scope for what they support on this board, it sure looks like it may be POSSIBLE with this board - or at least this chip. I’d definitely wait until someone with more authoritative info steps in before giving up.
And while I haven’t seen the RZ/Five, and I’m certainly no fan of C906, they’re offering counterexamples to RZ/Five running Linux (RZ/Five Verified Linux Package [5.10-CIP] | Renesas) multiple documents referrign to their support of Linux (RZ/Five - General-purpose Microprocessors with RISC-V CPU Core (Andes AX45MP Single) (1.0 GHz) with 2ch Gigabit Ethernet | Renesas, etc.) and such. It sure looks like they’ll run Linux, specifications be damned. (And don’t get me wrong - C906 DOES play loose with specs for my taste.)
I though that it used a AX45MP, is that a C906 under the hood ?
The AX45MP, is currently not going to be supported by FreeBSD, because of violating the RISC-V Sv39 specification.
You’re right. It’s an Andes core and my reply was a mess. I tried to draw an parallel with spec-violating chips and OS support, but deleted key parts of that before posting it. The result was ugly. Sorry.
IMO, the RZ/Five is a bit of a niche MCU more than an application processor so general purpose/server oriented OSes aren’t giving up much by not supporting it. That’s a pretty horrifying misfeature and while it may make sense for Renesas to maintain their own Linux fork, FreeBSD just doesn’t need that grief. A single core, one ghz part just isn’t a great fit for FeeeBSDs market anyway.
Until ND27V ships, it seems that Andes just won’t have an entry in the TH-1520/JH-7110 application processor space.
Noo, nah I’m just learning and CANBus can be soon-to-turn on curve in my career. so I have to smash my head before my manager will do it.
the JH7110 fully multiplexes GPOI0-63 pins to any signals
see JH7110 datasheet from p54 GPOI functions, p66 has CAN signals
there are 18 unallocated gpio pins on the 40 pin header
TJA1050 based high speed transceiver - cheap
adendum: TJA1050 is 5v supply and signal, others more suited for 3v3 signals
Can over the SPI bus might be an early starter using an MCP2515 interface - cheap
and compiling the associated modules.
I suspect this was just a number mistake, because you must have meant MCP2551 and not MCP2515.
No, that was my mistake, you didn’t mean the transceiver, but specifically the controller. And the cheap modules with this controller work with both 3.3V and 5V.
Try MCU, more clear way to access GPIO.
I’m not sure if a JH7110 can module is yet available for Linux,
so until then a module for 2515 is available.
Yep, the SPI interface can controller with transceiver.
3v3 and 5v available on the 40 pin header, 3v3 signals into the JH7110 ?
or power from the StarVision2 PWR-IN ?
Start writing code and testing, ready for the JH7110 can controller.